qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH] spapr: move registration of "host" C


From: Igor Mammedov
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] spapr: move registration of "host" CPU core type to machine code
Date: Wed, 27 Sep 2017 14:11:44 +0200

On Wed, 27 Sep 2017 16:39:03 +1000
David Gibson <address@hidden> wrote:

> On Tue, Sep 26, 2017 at 10:29:36AM +0200, Igor Mammedov wrote:
> > On Tue, 26 Sep 2017 09:19:28 +0200
> > Greg Kurz <address@hidden> wrote:
> >   
> > > On Tue, 26 Sep 2017 12:57:39 +1000
> > > David Gibson <address@hidden> wrote:
> > >   
> > > > On Mon, Sep 25, 2017 at 11:47:33AM +0200, Greg Kurz wrote:    
> > > > > The CPU core abstraction belongs to the machine code. This also gets
> > > > > rid of some code duplication.
> > > > > 
> > > > > Signed-off-by: Greg Kurz <address@hidden>
> > > > > ---
> > > > > 
> > > > > hw/ppc/spapr_cpu_core.h is also included elsewhere in target/ppc/kvm.c
> > > > > but this is already handled by the following cleanup patch:      
> > > > 
> > > > I don't really see what the advantage of this is.  As others have
> > > > pointed out it leads to the host type being registered very late,
> > > > which could cause problems.
> > > >     
> > > 
> > > Well, the goal was to consolidate the code to register sPAPRCPUCore types 
> > > in
> > > the spapr code, instead of open-coding it in spapr_cpu_core.c and 
> > > kvm.c... 
> > > 
> > > But now I realize that delaying the registration even more is a bad idea. 
> > > And,
> > > the other way round, registering a static type earlier as asked by Igor 
> > > would
> > > require all parent types to be already registered, which seems to be 
> > > impossible
> > > to guarantee with the current code.  
> > so I'll leave this code as is for now as as it's a bit of topic
> > wrt my work on cpu_model removal (or I'll try not to touch it until I have 
> > to)
> >   
> > > Maybe we could at least have kvm_ppc_register_host_cpu_type() to call a
> > > function in spapr_cpu_core.c instead of duplicating the registration code 
> > > ?  
> > Is it possible for other boards (non core based) to use host CPU?
> > 
> > but for simplicity sake I'd lave it where it's now.
> > 
> > BTW I have an additional question:
> > what PPC boards are supposed to support KVM/host cpu?  
> 
> In theory, any board, but your host has to have a cpu that's suitable
> for the board in question.  So, if your host is a POWER8, you can use
> -cpu host with a machine type which supports a POWER8 cpu; which is
> basically just "pseries".  You couldn't use -cpu host with one of the
> embedded board types, since they don't expect a POWER8 vCPU.
> 
> If you were on an e500 based host, you could use -cpu host with one of
> the various e500 based machine types.  You couldn't use it with
> "pseries", since that will only work with a POWER7/8/9 vCPU.
> 
> The issue is muddied by the fact that KVM HV (the fast KVM
> implementation), a) will only work with a PAPR guest (i.e. pseries
> machine type) and b) can't present a vCPU to the guest that differs
> from the host (this is a hardware limitation).  If these conditions
> aren't met, the host kernel should automatically fall back to KVM PR
> (or fail outright if it's not available).  Of course then it's further
> muddied by the fact that KVM PR has _some_ ability to present a
> different vCPU to the guest than is on the host, but it has some curly
> limitations that we might or might not be able to detect in advance.
> 
> And, it's muddied even further by the fact that some of the CPU
> "variants" are in fact identical cores - the differences are just in
> peripherals, pin-level connections, cache etc. which the guest can't
> see and doesn't care about.  Unfortunately, there aren't separate ways
> for the CPU to advertise core version and other things, so even
> trivial variants like this will have a different PVR value as a rule.
> 
> > (especially taking in account that aliases get patched to it as well,
> > which I very much dislike since user asked for one CPU but got
> > another  
> 
> Uh.. what?  You should never get something different than what you
> asked for.  The worst that can happen is if you request something
> fuzzy, like "POWER8" instead of "POWER8E_v2.0" then exactly which
> thing in that family you get depends on the host.
that's what bothers me since when alias is used /like POWER8/
user gets 'some' cpu and he/she has to be aware that it might be not
the exactly the same cpu on another host.


> > and when the same happens on another host migration probably would be
> > screwed up)  
> 
> So, we can migrate between different CPUs if they're similar enough
> (say, everything within the POWER8 family).  The guest is able to see
> the change in the PVR, but it will be fine in practice.
sounds rather fragile, is there plan to make it more strict and
less ambiguous? /like not allowing 'generic' cpu names and using
only concrete ones/


> This is really ugly, but unfortunately there's no away around it in
> the hardware, it's simply not possible to virtualize the PVR to
> present a different CPU variant to the guest (well, short of putting
> the entire guest into user mode, which is what KVM PR does).
> 




reply via email to

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