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