On Mon, Feb 29, 2016 at 04:15:25PM +0100, Igor Mammedov wrote:
> On Mon, 29 Feb 2016 18:25:25 +0530
> Bharata B Rao <bhar...@linux.vnet.ibm.com> wrote:
> > On Mon, Feb 29, 2016 at 11:03:16AM +0100, Igor Mammedov wrote:
> > > On Mon, 29 Feb 2016 11:20:19 +0530
> > > Bharata B Rao <bhar...@linux.vnet.ibm.com> wrote:
[snip]
> > > > > "slot" seems intended to be a machine-agnostic of mapping device
> > > > > types discovered from qmp_query_cpu_slots() to an appropriate
> > > > > "bus" location, but here's it a field specific to TYPE_SPAPR_CPU_CORE.
> > > > > It seems like maybe TYPE_CPU_CORE is a better place, but then on
> > > > > x86 I suppose it might be TYPE_CPU_SOCKET or something instead...
> > > >
> > > > Correct.
> > > >
> > > > >
> > > > > It almost seems like a TYPE_INTERFACE_SLOTABLE would be the
> > > > > right approach, but I don't know how we could expose that as
> > > > > a property. I guess it's somewhat implied that this "interface"
> > > > > exists if qmp_query_cpu_slots() returns the type, but I wonder
> > > > > if something a bit more formal should be modeled to make the
> > > > > implementation requirements a bit clearer.
> > > > >
> > > > > Maybe have TYPE_CPU_{CORE,SOCKET} classes have a get_slot/set_slot
> > > > > class method, expose them via "slot" property, then have the
> > > > > defaults generate "not implemented" errors?
> > > >
> > > > Yes makes sense. In fact David has often times said that generic
> > > > properties/routines should be pushed to base class wherever possible.
> > > >
> > > > I didn't do that in this first iteration to keep the generic changes
> > > > as minimum as possible, but yes slot should be a property of the
> > > > base class of core or socket.
> > > Then what will happen to slot if there isn't any core/socket device
> > > to query it, i.e. cpu hasn't been plugged in yet?
> > > To me slot looks like a machine belonged feature.
> >
> > Yes slot belongs to the machine and it is represented by a link that
> > is created b/n the machine object and the core object that sits in
> > the slot.
> >
> > In the context of this thread, slot is actually the slot name that
> > identifies the machine slot which the core occupies or will occupy after
> > hotplug. Thus slot name which is named slot here, it is a property of the
> > core device.
> >
> > (qemu) device_add spapr-cpu-core,slot=core[2]
> > ^
> Is 'slot' a term used by SPAPR on real hardware?
So.. PAPR is a para-virtualized interface, so it never appears on real
hardware.
But, no, "slot" is not a term used by PAPR.
> I'd thought that it's 'core', that's why I suggested to use
> 'core' for POWER as that matched real world concept, see
> my other reply in "[RFC PATCH v0 4/6] spapr: CPU hotplug support" thread
> of this series.
I don't think it uses "core" either, I believe it uses just "cpu" but
meaning a multi-thread core, rather than a single logical cpu thread.
--
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
signature.asc
Description: PGP signature
