Re: [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support

[Alexander Graf]

On 15.08.2013, at 18:22, Andreas Färber wrote:

> Am 15.08.2013 17:58, schrieb Alexander Graf:
>> 
>> On 15.08.2013, at 17:48, Andreas Färber wrote:
>> 
>>> Am 15.08.2013 17:30, schrieb Alexander Graf:
>>>> 
>>>> On 15.08.2013, at 17:11, Andreas Färber wrote:
>>>> 
>>>>> Am 15.08.2013 15:12, schrieb Anthony Liguori:
>>>>>> Everyone is talking past each other and no one is addressing the real
>>>>>> problem.  There are two distinct issues here:
>>>>>> 
>>>>>> 1) We have two ABIs that cannot be changed unless there's a very good
>>>>>> reason to.  Alexey's original patch breaks both.  The guest ABI
>>>>>> cannot change given a fixed command line.
>>>>>> 
>>>>>> IOW, the exposed PVR value for -cpu POWER7 cannot change across
>>>>>> versions of QEMU or when running on different hardware.  This breaks
>>>>>> live migration and save/resume.
>>>>>> 
>>>>>> We also cannot break the command line interface.  If the last version
>>>>>> of QEMU supported -cpu POWER7_v2.1, then we must continue to support
>>>>>> that.
>>>>> 
>>>>> 1a) How should -cpu 0xDEADBEEF or -cpu DEADBEEF behave.
>>>>> 
>>>>>  I expect it to error out as before
>>>>>  rather than applying the same fuzz/mask that -cpu host might.
>>>> 
>>>> I actually think it'd make sense to apply the same fuzz/mask, don't you 
>>>> think?
>>> 
>>> I think "-cpu host" has the semantics of give-me-what-the-host-has. But
>>> -cpu 0xDEADBEEF is asking for PVR DEADBEEF and having it silently return
>>> a guest-visible DEADBEBE is going to be undesired.
>> 
>> -cpu host on 0xDEADBEEF should give us a 0xDEADBEEF cpu. -cpu 0xDEADBEEF 
>> should give us a 0xDEADBEEF cpu :).
> 
> Then we mustn't tweak translate_init.c:cpu_class_by_pvr() to return
> deviating results! Which is what the change to
> ppc_cpu_compare_class_pvr() is essentially resulting in if I am not
> completely off track. And therefore my calling to handle this at a

Did anyone ever say the patch is correct?

> higher level (KVM init), where the user's intentions are clear, rather
> than to blur our internal API. Otherwise the _by_pvr() function would

Yes.

> need to create a new class or modify an existing one when the function
> can't know what the function call was actually intended for.

Yes :).


Alex