On Mon, Sep 30, 2013 at 01:25:32PM +0200, Alexander Graf wrote: > > On 27.09.2013, at 10:06, Alexey Kardashevskiy wrote: > > > To be able to boot on newer hardware that the software support, > > PowerISA defines a logical PVR, one per every PowerISA specification > > version from 2.04. [snip] > > + case 205: > > + spapr->arch_compat = CPU_POWERPC_LOGICAL_2_05; > > + break; > > + case 206: > > + spapr->arch_compat = CPU_POWERPC_LOGICAL_2_06; > > Does it make sense to declare compat mode a number or would a string be > easier for users? I can imagine that "-machine compat=power6" is easier to > understand for a user than "-machine compat=205".
That's probably true. I don't mind either way. > Also, we need to handle failure. If the kernel can not set the CPU to 2.05 > mode for example (IIRC POWER8 doesn't allow you to) we should bail out here. POWER8 does have 2.05 (POWER6) and 2.06 (POWER7) compatibility modes. > > + /* Architecture compatibility mode */ > > + uint32_t arch_compat; > > Do we really need to carry this in the vcpu struct? Or can we just > fire-and-forget about it? If we want to preserve anything, it should be the > PCR register. There are two relevant values here; the compatibility mode (if any) that the user has requested via the command line, and the mode that has been negotiated with the ibm,client-architecture-support (CAS) call. CAS should select the latest mode supported by the guest that is not later than the mode requested on the command line, and is supported by QEMU, and is not later than the architecture of the host. Both values should be sent across to the destination VM on migration AFAICS. On reset/reboot, the compatibility mode should not change. The device tree that is supplied to the new SLOF instance should reflect the current compatibility mode. Regards, Paul.
