mbox series

[PATCH+RFC,0/6] target/arm: Define cortex-a{73, 75, 76}

Message ID 20190223023957.18865-1-richard.henderson@linaro.org
Headers show
Series target/arm: Define cortex-a{73, 75, 76} | expand

Message

Richard Henderson Feb. 23, 2019, 2:39 a.m. UTC 
There have been several announcements since the a72.

The a75 and a76 entries are RFC because, while they boot with a 3.15
kernel, they do not boot with a 5.0-rc7 kernel.  I'm really not sure
where things have gone off the rails.  It'll take some more serious
tracing to figure out what went wrong.

I post this now mostly to get feedback on patch 5.  Should we do
more to elide *all* of the aa32 system registers for that case?


r~


Richard Henderson (6):
  target/arm: Implement ID_PFR2
  target/arm: Define cortex-a73
  target/arm: Implement ID_AA64MMFR2
  target/arm: Define cortex-a75
  target/arm: Conditionalize DBGDIDR vs ID_AA64DFR0_EL1 assert
  target/arm: Define cortex-a76

 target/arm/cpu.h    |  18 +++++
 hw/arm/virt.c       |   3 +
 target/arm/cpu64.c  | 179 +++++++++++++++++++++++++++++++++++++++++++-
 target/arm/helper.c |  66 ++++++++++------
 target/arm/kvm64.c  |   2 +
 5 files changed, 240 insertions(+), 28 deletions(-)

-- 
2.17.2

Comments

Peter Maydell April 30, 2019, 12:57 p.m. UTC | #1 
On Sat, 23 Feb 2019 at 02:40, Richard Henderson
<richard.henderson@linaro.org> wrote:
>

> There have been several announcements since the a72.

>

> The a75 and a76 entries are RFC because, while they boot with a 3.15

> kernel, they do not boot with a 5.0-rc7 kernel.  I'm really not sure

> where things have gone off the rails.  It'll take some more serious

> tracing to figure out what went wrong.

>

> I post this now mostly to get feedback on patch 5.  Should we do

> more to elide *all* of the aa32 system registers for that case?


We should make sure we don't expose non-existent sysregs to
EL0, but it's harmless to define aa32 PL1_RW sysregs in
an AArch64-only-for-EL1-and-up CPU -- the guest is just never
able to access them. (This is the inverse of the way we define
a lot of AArch64 sysregs for AArch32 CPUs).

The thing to watch out for here is that where we have AArch32 and
AArch64 aliases of each other, we tend to define one as the
"real thing" and the other as the alias, which matters for
migration. If we've used the AArch32 version as the "real thing"
then we can't just skip the definition or we'll drop the register
state from the migration stream entirely.

thanks
-- PMM