Re: [Qemu-devel] [RFC 4/8] qdev: link based hotplug

["Andreas Färber" <afaerber@suse.de>]

Am 21.03.2014 11:35, schrieb Igor Mammedov:
> BTW not related to hotplug but why I used link<>s:
> 
> I've added link<>s as an attempt to visualize Andreas' idea to use them for

Anthony's :)

> hotplug and mgmt. It has it's own benefits if we try to provide more or
> less uniform QOM interface view for management. What I have in mind is that
> we could have tree like this:
>  /machine/node[...]/dimm[...]
>                    /cpu[...]/core[...]/thread[...]
> 
> where leaves are link<>s which are prebuilt at startup and set when device
> is added. It provides an easy to enumerate interface for mgmt and also
> gives us a quite informative path that encodes topology and later
> we could use it instead of custom properties. For example:
> 
>   device_add x86cpu,path=/machine/node[1]/cpu[0]/core[3]/thread[2]
> vs
>   device_add x86cpu,apic-id=[who knows how it's calculated]

This still collides with what Anthony and me have been saying about CPU
hot-add: It should not happen on thread level. cpu-add covers the
current approach, but device_add should add a full socket and definitely
not in that /machine/node[n]/... path. You or someone replied on Paolo's
NUMA thread that this was only as an internal convenience for lookups,
now you're pushing this as user ABI. NACK to the latter.

I was hoping that we could let device_add auto-discover free link<>
slots like it does for buses today; having two places to link the same
object would complicate that, so we need to be careful in designing our
link<>s: Having /machine/node[0]/cpu[0] be a link<> would mean no second
link<> directly on /machine/cpu[0], i.e. the NUMA node acting as a
sub-container of the board; on the other hand having a link<> to the
thread CPUState from some NUMA-specific path outside of the composition
model would still be possible due to the different link<> type but
having cpu[0] be a link to the actual socket object rules out using the
same name for a NUMA-only container object as proposed.

> or
>   device_add dimm,path=/machine/node[0]/dimm[5]
> vs
>   device_add dimm,node=0,slot=5
> 
> i.e. being added device could decode all needed information from above
> provided path instead of creating a bunch of custom properties.

Hm, the advantage of having properties there would be better error
checking in terms of restricting paths. I'd be open to having both.

I do wonder in both cases if we should use paths relative to /machine to
avoid them cluttering the command line?

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg