Re: [Qemu-devel] [RFC PATCH v0 2/6] spapr: CPU core device

[Igor Mammedov]

On Tue, 1 Mar 2016 12:21:27 +1100
David Gibson <address@hidden> wrote:

> 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 <address@hidden> 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 <address@hidden> 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.
then calling property 'cpu' is fine or one could go by meaning and
use 'core' property (reusing 'core' property)