qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH] spapr: add "compat" machine option
Date: Tue, 05 Nov 2013 21:45:18 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 11/05/2013 08:52 PM, Paolo Bonzini wrote:
> Il 05/11/2013 10:16, Alexander Graf ha scritto:
>>
>> On 05.11.2013, at 10:06, Paolo Bonzini <address@hidden> wrote:
>>
>>> Il 30/09/2013 14:57, Alexey Kardashevskiy ha scritto:
>>>>>> Why is the option under -machine instead of -cpu?
>>>> Because it is still the same CPU and the guest will still read the real
>>>> PVR from the hardware (which it may not support but this is why we need
>>>> compatibility mode).
>>>
>>> How do you support migration from a newer to an older CPU then?  I think
>>> the guest should never see anything about the hardware CPU model.
>>
>> POWER can't model that. It always leaks the host CPU information into the 
>> guest. It's the guest kernel's responsibility to not expose that change to 
>> user space.
>>
>> Yes, it's broken :). I'm not even sure there is any sensible way to do live 
>> migration between different CPU types.
> 
> Still in my opinion it should be "-cpu", not "-machine".  Even if it's
> just a "virtual" CPU model.

The compat option itself does not make much sense (yes we could just add
yet another CPU class and that's it) but with the
ibm,client-architecture-support we will have to implement this
compatibility mode anyway. Since the guest can ask for a compatibility mode
change, we either have to support compat option or hot-unplug all (all) CPU
objects in QEMU and hotplug CPUs of the requested model. Or always reset
the guest if it asked for a compatibility mode and recreate CPUs in QEMU
during reset. As for me, the compat option seems simpler.


-- 
Alexey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]