[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] cpu modelling and hotplug (was: [PATCH RFC 0/4] target-
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] cpu modelling and hotplug (was: [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1) |
Date: |
Mon, 27 Apr 2015 20:46:07 +1000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Thu, Apr 23, 2015 at 10:17:36AM -0300, Eduardo Habkost wrote:
> On Thu, Apr 23, 2015 at 05:32:33PM +1000, David Gibson wrote:
> > On Tue, Apr 07, 2015 at 02:43:43PM +0200, Christian Borntraeger wrote:
> > > We had a call and I was asked to write a summary about our conclusion.
> > >
> > > The more I wrote, there more I became uncertain if we really came to a
> > > conclusion and became more certain that we want to define the QMP/HMP/CLI
> > > interfaces first (or quite early in the process)
> > >
> > > As discussed I will provide an initial document as a discussion starter
> > >
> > > So here is my current understanding with each piece of information on one
> > > line, so
> > > that everybody can correct me or make additions:
> > >
> > > current wrap-up of architecture support
> > > -------------------
> > > x86
> > > - Topology possible
> > > - can be hierarchical
> > > - interfaces to query topology
> > > - SMT: fanout in host, guest uses host threads to back guest vCPUS
> > > - supports cpu hotplug via cpu_add
> > >
> > > power
> > > - Topology possible
> > > - interfaces to query topology?
> >
> > For power, topology information is communicated via the
> > "ibm,associativity" (and related) properties in the device tree. This
> > is can encode heirarchical topologies, but it is *not* bound to the
> > socket/core/thread heirarchy. On the guest side in Power there's no
> > real notion of "socket", just cores with specified proximities to
> > various memory nodes.
> >
> > > - SMT: Power8: no threads in host and full core passed in due to HW design
> > > may change in the future
> > >
> > > s/390
> > > - Topology possible
> > > - can be hierarchical
> > > - interfaces to query topology
> > > - always virtualized via PR/SM LPAR
> > > - host topology from LPAR can be heterogenous (e.g. 3 cpus in 1st
> > > socket, 4 in 2nd)
> > > - SMT: fanout in host, guest uses host threads to back guest vCPUS
> > >
> > >
> > > Current downsides of CPU definitions/hotplug
> > > -----------------------------------------------
> > > - smp, sockets=,cores=,threads= builds only homogeneous topology
> > > - cpu_add does not tell were to add
> > > - artificial icc bus construct on x86 for several reasons (link, sysbus
> > > not hotpluggable..)
> >
> > Artificial though it may be, I think having a "cpus" pseudo-bus is not
> > such a bad idea
>
> That was considered before[1][2]. We have use cases for adding
> additional information about VCPUs to query-cpus, but we could simply
> use qom-get for that. The only thing missing is a predictable QOM path
> for VCPU objects.
>
> If we provide something like "/cpus/<cpu>" links on all machines,
> callers could simply use qom-get to get just the information they need,
> instead of getting too much information from query-cpus (which also has
> the side-effect of interrupting all running VCPUs to synchronize
> register information).
>
> Quoting part of your proposal below:
> > Ignoring NUMA topology (I'll come back to that in a moment) qemu
> > should really only care about two things:
> >
> > a) the unit of execution scheduling (a vCPU or "thread")
> > b) the unit of plug/unplug
> >
> [...]
> > 3) I'm thinking we'd have a "cpus" virtual bus represented in QOM,
> > which would contain the vCMs (also QOM objects). Their existence
> > would be generic, though we'd almost certainly use arch and/or machine
> > specific subtypes.
> >
> > 4) There would be a (generic) way of finding the vCPUS (threads) in a
> > vCM and the vCM for a specific vCPU.
> >
>
> What I propose now is a bit simpler: just a mechanism for enumerating
> VCPUs/threads (a), that would replace query-cpus. Later we could also
> have a generic mechanism for (b), if we decide to introduce a generic
> "CPU module" abstraction for plug/unplug.
>
> A more complex mechanism to enumerating vCMs and the vCPUs inside a vCM
> would be a superset of (a), so in theory we wouldn't need both. But I
> believe that: 1) we will take some time to define the details of the
> vCM/plug/unplug abstractions; 2) we already have use cases today[2] that
> could benefit from a generic QOM path for (a).
That seems like a reasonable first step. I don't think it conflicts
with any of the things I was suggesting.
--
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_!
http://www.ozlabs.org/~dgibson
pgpg2bTbpFFGH.pgp
Description: PGP signature