[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support
From: |
Alexander Graf |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support |
Date: |
Thu, 15 Aug 2013 19:01:13 +0200 |
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
- Re: [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support, (continued)
- Re: [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support, Alexander Graf, 2013/08/15
- Re: [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support, Benjamin Herrenschmidt, 2013/08/15
- Re: [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support, Alexander Graf, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Anthony Liguori, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Alexander Graf, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Andreas Färber, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Alexander Graf, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Andreas Färber, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Alexander Graf, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Andreas Färber, 2013/08/15
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support,
Alexander Graf <=
- Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support, Anthony Liguori, 2013/08/15
Re: [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support, Benjamin Herrenschmidt, 2013/08/15
Re: [Qemu-ppc] [RFC PATCH] powerpc: add PVR mask support, Alexander Graf, 2013/08/15