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
