qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v3] powerpc: add PVR mask support


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [RFC PATCH v3] powerpc: add PVR mask support
Date: Fri, 16 Aug 2013 10:20:17 +1000

On Thu, 2013-08-15 at 16:47 +0200, Andreas Färber wrote:
> When we instantiate a -cpu POWER9 then having one POWER9_vX.Y around to
> back it doesn't really hurt. Unlike ARM's MIDR there doesn't seem to be
> an encoding of IBM vendor or POWER family in the PVR. The macros and
> their new implementation are not the way they are because I consider
> them the nicest thing in the world but because the name+pvr+svr+family
> combination made them work for the whole zoo of models we carry around
> and started to give us some inheritance through QOM. Making the POWER7
> family non-abstract would require the same kind of macro "overloading"
> for POWERPC_FAMILY that I'm trying to contain for POWERPC_DEF ATM. So
> what I am still thinking about is how to handle there being multiple
> matches for a PVR - I am considering putting them into a list and
> comparing values for closest match. So that if you have a v2.4 and QEMU
> knows v2.1 and v2.3 we take v2.3 and fill in the v2.4 PVR.

Another thing to keep in mind is that we will want eventually to support
POWER7 compatibility more on POWER8 with HV KVM. I am not certain what
the "right" way to do it via qemu command line is, whether we would
have a -cpu entry (-cpu POWER7_COMPAT ?) or such...

Additionally, the trick here is that qemu must be able to change its model
at runtime (a reset is permitted). This is how PAPR defines the reconfiguration
reboot (for that and other things).

IE. The guest kernel will call FW early on, while still operating under
OFW (from prom_init) indicating what it supports, and if that doesn't include
P8, we need to reconfigure the CPU model to be P7 compat (we are allowed to
reboot and reload the same kernel, which is generally what pHyp does, but
we'd like to try avoiding it as much as possible).

Cheers,
Ben.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]