On Thu, 2013-08-15 at 19:28 -0500, Anthony Liguori wrote: > On Thu, Aug 15, 2013 at 7:20 PM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > On Thu, 2013-08-15 at 16:47 +0200, Andreas Färber wrote: > >> 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... > > But this doesn't change the hardware PVR value right, just the virtual > PVR that's in the device tree?
Right. > Maybe you need to change some state of the virtual VCPU but from a QEMU > point of view, it's still a POWER8 VCPU (it's just in power7 compat mode). Sure, as long as TCG does the right thing (some instructions must be forbidden etc...). That's more what I had in mind... > > 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). > > I don't think the model changes. It's just a flag in the power8 vcpu state. > > No different IMHO between jumping from real mode to protected mode to > long mode on x86. Ok. Cheers, Ben. > Regards, > > Anthony Liguori > > > 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. > > > > > >
