Re: [Question] Regarding containers "unattached/peripheral/anonymous" - their relation with hot(un)plug of devices

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 24 Jan 2020 15:02:10 +0000
Salil Mehta <salil.mehta@huawei.com> wrote:

> > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > Sent: Friday, January 24, 2020 1:54 PM
> > To: Salil Mehta <salil.mehta@huawei.com>
> > 
> > On Fri, 24 Jan 2020 11:20:15 +0000
> > Salil Mehta <salil.mehta@huawei.com> wrote:
> >   
> > > Hello,
> > > I am working on vCPU Hotplug feature for ARM64 and I am in mid of understanding
> > > some aspect of device_add/device_del interface of the QEMU.
> > >
> > > Observations:
> > > 1. Any object initialised by qmp_device_add() gets into /machine/unattached
> > > container. I traced the flow to code leg inside  device_set_realized()
> > > 2. I could see the reverse qmp_device_del() expects the device to be in
> > > /machine/peripheral container.
> > > 3. I could see any object initially added to unattached container did not had
> > > their parents until object_add_property_child() was called further in the leg.
> > > which effectively meant a new property was created and property table
> > > populated and child was parented.
> > > 4. Generally, container  /machine/peripheral was being used wherever
> > > DEVICE(dev)->id was present and non-null.
> > >
> > > Question:
> > > 1. Wanted to confirm my understanding about the use of having separate
> > > containers like unattached, peripheral and anonymous.  
> >   
> > > 2. At init time all the vcpus goes under *unattached* container. Now,
> > > qmp_device_del() cannot be used to unplug them. I am wondering  
> > 
> > device is put into 'unattached' in case it wasn't assigned a parent.
> > Usually it happens when board creates device directly.  
> 
> 
> Sure, but if we decide that certain number(N) of vcpus are hotplugabble
> and certain subset of N (say 'n' < 'N') should be allowed to be present
> or cold-plugged at the init time then I wonder which of the following
> is correct approach:
> 
> 1. Bring all of N vcpus at boot time under "peripheral" container
>                                    OR
> 2. Just bring subset 'n' of 'N' under "peripheral" container and rest
>     under "unattached" container? And later as and when rest of the
>     vcpus are hotplugged they should be transferred from "unattached"
>     container to "peripheral" container?

issue with that is that to put device into "peripheral" container,
'the user' must provide 'id'. (currently QEMU isn't able to do it on its own [1])

But it doesn't mean that cold-plugged CPUs can't be unpluged.
What current users could do is start QEMU like this (simplified version):

 $QEMU -smp 1,maxcpus=N -device foo-cpu-type,id=CPU00 -device foo-cpu-type,id=CPU01 ...

i.e. 1st CPU is not manageable due to lack if 'id' and is created by board code,
the rest have 'id' and could be managed.


Question is:
  why you are looking into 'what container' is used for CPUs?


1) here is what I could find on IDs topic
   https://lists.gnu.org/archive/html/qemu-block/2015-09/msg00011.html
 
> > >    if all the hotplug devices need to go under the *peripheral* container while
> > > they are hotplugged and during object init time as well?  
> > 
> > theoretically device_del may use QOM path (the later users can get with
> > query-hotpluggable-cpus),
> > but I think it's mostly debugging feature.  
> 
> 
> Sure.
> 
> 
> > users are supposed to specify 'id' during -device/device_add if they are going
> > to manage that device.
> > afterwards (like unplugging it). Then they could use that 'id' in other commands
> > (including device_del)
> > 
> > So 'id'-ed devices end up in 'peripheral' container.  
> 
> 
> Sure, what if hotplugged device is removed and then added again? It looks 
> qmp_device_add() interface will again end up calling the device_set_realized()
> which eventually would put hotplugged devices under "unattached" container?

it won't, see call chain:

  qmp_device_add()
      -> qdev_device_add()
          -> qdev_set_id()

 
> > > 3. I could not see any device being place under *anonymous* container during  
> > init time. What is the use of this container?
> > 
> > if I recall it right, devices created with help of device_add but without 'id'
> > go to this container  
> 
> 
> Any examples on top of your head where such an interface might be of use?

ex:
one could use -device/device_add without any ids if such devices aren't planned
to be unplugged during runtime or for unpluggable devices

> 
> 
> Many thanks
> Salil.
>