Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support

[Anthony Liguori]

On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf <address@hidden> wrote:
>
>>
>>> So IMHO this whole thing should be orthogonal to -cpu.
>>
>> Well, since we cannot change CPU class on the fly, yes, it should be a
>> "compatibility" flags/properties/methods/whatever of the default CPU for
>> the specific family.
>
> Since it's machine global, it could just as well be a machine option, no? Or 
> can you have multiple CPUs with different compat modes in a single system?

AFAIK, this has nothing to do with CPUs.

>>> Why? Just because you're on POWER7 as default doesn't mean you can't bump 
>>> to a newer compat later on, no?
>>
>> Bump when exactly? And it won't be a new compat, it will be a native CPU. I
>
> If you configure your guest to boot in POWER7-compat mode on your POWER8 box 
> and it then tells you through ibm,client-architecture-support that it can do 
> POWER8, we can just remove all the compat bits and be happy, no?

POWER8 is compatible with POWER7, right?  There's no magic bits that
need to be disabled AFAIK.

The effective version if exposed through device tree.  The reason a
reboot is needed is because the device tree needs to be updated (which
can't be done without a reboot).

The problem to solve is delaying device tree generation in order to
avoid the reboots, no?

(Maybe it's time to start thinking of non-PAPR interfaces that Linux
KVM guests can use to avoid a lot of this silliness...)

>> thought you are totally against reboots and you want libvirt (for example)
>> to detect that this was ibm,client-architecture-support and reboot the
>> guest with new CPU type (or machine option).
>
> I'm not sure which way the best one forward is, but at first we need to get 
> something working that feels natural for people coming from x86 as well as 
> pHyp.
>
> So I think we should enable both use cases. We should do the on-the-fly 
> transitioning in QEMU with the chance of libvirt intercepting it. I don't 
> think the intercepting part is a hard requirement today, but we should keep 
> it in mind to know the full picture.
>
> That way a client-architecture-support rtas call can either reboot the system 
> and automatically do "the right thing" and/or it can tell libvirt via QMP 
> that we changed the client-architecture-support which means libvirt now has 
> the chance to reconfigure the default setting next time it spawns a VM.
>
> Which gets us to the third bit. You need to be able to tell QEMU what the 
> "default" client-architecture-support level is when you boot a VM to make 
> sure that a POWER7 guest on a POWER8 system doesn't always reboot to 
> reconfigure itself first thing when it boots up. As Ben mentioned, migration 
> is obviously a strong point for this one too.
>
> So what do we need?
>
>   - machine flag to indicate compat level
>   - machine reset evaluates compat level, adjusts VM accordingly
>   - rtas call merely modifies machine flag and triggers a reset
>   - optional: QMP notifier when the rtas call changed the machine flag

Regards,

Anthony Liguori

>
>
> Alex
>
>