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

[Alexander Graf]

On 15.08.2013, at 15:12, Anthony Liguori wrote:

> Benjamin Herrenschmidt <address@hidden> writes:
> 
>> On Thu, 2013-08-15 at 08:03 +0200, Alexander Graf wrote:
>> 
>>>>> How does the user select that he wants a v2.3 p7 cpu with this
>>> patch?
>>>> 
>>>> Why would he want that? The behaviour would not change because of
>>> the
>>>> version - all definitions use the same POWERPC_FAMILY(POWER7) and
>>> PVR is
>>>> not virtualized anyway.
>>> 
>>> Quite frankly I don't know what to say here. Are you trying to play
>>> dumb or are you just one of those totally sloppy people who don't care
>>> about anything outside of their own scope of work?
>> 
>> Can you stop the bloody personal attacks on Alexey ? It's becoming
>> tiresome.
> 
> 
> First, everyone needs to tone it down a couple levels.  This isn't LKML
> and Jonathan Corbet doesn't read qemu-devel so pithy remarks aren't
> going to get you a quote of the week.
> 
> 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.
> 
>   If there's a good reason to break either of these, that's fine but
>   that justification needs be up front in the patch commit message.
> 
> 2) The only "-cpu" that makes sense is "-cpu host" for KVM on HV (or
>   whatever ya'll call it).  POWER does not have the ability to
>   virtualize the hardware PVR value.  There is a virtual PVR in the
>   device tree but that's orthogonal to what we think of as the VCPU (it
>   essentially means IIUC that the cpu is compatible with that PVR).
> 
>   We should explicitly disallow any -cpu value when KVM on HV is
>   enabled other than host.

With Paulus' latest patches we can support HV and PR dynamically on the same 
host kernel, so there's no way to figure out whether we are in an HV or PR 
environment.

The semantic we probably want there is that -cpu host (and anything that looks 
the same from KVM's point of view, basically guest_pvr == host_pvr) and PAPR 
enabled triggers HV KVM. If we ever support compat mode with HV KVM, that PVR 
will also enable HV KVM.

What we need in addition is a query interface so that QEMU can find out whether 
we are in HV or PR mode. That way we can add a machine force option that allows 
us to bail out when we're falling back to PR mode in case that's not what the 
user wanted.

>   The implementation of "-cpu host" is also goofy on PPC.  -cpu host
>   does a match on existing CPU models meaning that we have to define a
>   CPU model for any possible CPU we run on.  This would require having
>   every possible CPU model implemented in QEMU which is silly.
>   Instead, we should have a passthrough CPU model for use with "-cpu
>   host" which is essentially what Alexey's patch turns -cpu POWER7
>   into.

The world isn't that easy unfortunately. We basically need one "passthrough CPU 
model" for each CPU class, since different CPUs can have different features and 
MMU implementations which QEMU does care about.

That's basically what the conclusion of the discussion was too. That we need to 
be able to instantiate the CPU family class (which currently is abstract) which 
then serves as entry point for -cpu host (and -cpu <pvr> hopefully).


Alex