[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option
From: |
Alexander Graf |
Subject: |
Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option |
Date: |
Wed, 6 Nov 2013 13:07:15 +0100 |
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
- Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option, (continued)
- Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option, Andreas Färber, 2013/11/07
- [Qemu-ppc] [PATCH v2 0/2] spapr: add "compat" machine option, Alexey Kardashevskiy, 2013/11/08
- [Qemu-ppc] [PATCH v2 1/2] cpu: add suboptions support, Alexey Kardashevskiy, 2013/11/08
- [Qemu-ppc] [PATCH v2 2/2] target-ppc: add "compat" CPU option, Alexey Kardashevskiy, 2013/11/08
- Re: [Qemu-ppc] [PATCH v2 0/2] spapr: add "compat" machine option, Andreas Färber, 2013/11/08
Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option, Paul Mackerras, 2013/11/05
Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option, Paul Mackerras, 2013/11/06
- Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option,
Alexander Graf <=