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

[Alexander Graf]

On 06.11.2013, at 06:48, Paul Mackerras <address@hidden> wrote:

> 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.

So how does this work on pHyp? I thought the guest always comes up in full 
native compat mode and downgrades itself then?

> 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.

Ok, this should work if we just don't touch PCR across reset.


Alex