Re: [Qemu-devel] [PATCH] spapr: add "compat" machine option

[Paul Mackerras]

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.