[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH] spapr: move registration of "host" CPU core type

From: David Gibson
Subject: Re: [Qemu-ppc] [PATCH] spapr: move registration of "host" CPU core type to machine code
Date: Wed, 27 Sep 2017 16:39:03 +1000
User-agent: Mutt/1.9.0 (2017-09-02)

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.

> 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.

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).

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

Attachment: signature.asc
Description: PGP signature

reply via email to

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