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

[Igor Mammedov]

On Mon, 3 Feb 2020 05:40:01 -0500
"Michael S. Tsirkin" <address@hidden> wrote:

> On Fri, Jan 24, 2020 at 02:54:04PM +0100, Igor Mammedov wrote:
> > On Fri, 24 Jan 2020 11:20:15 +0000
> > Salil Mehta <address@hidden> 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.
> >   
> > >    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.
> > 
> > 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
> >   
> > > 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  
> 
> BTW, ATM hw/acpi/cpu.c creates _EJ0 for all CPUs (except the 1st one).
Eject on the 1st is disabled because we can't remove it in current impl.

> It might be cleaner to skip it for CPUs which don't have an id - what
> do you think?

Not sure as it's a bit different.
device_del is mgmt means to ask guest to remove CPU and if mgmt cares about 
removal
it should use 'id' during -device/device_add.
Where as _EJ0 is guest's means to actually remove cpus either on mgmt request
or manually via some other tooling running on guest side.
Once guest ejects such CPU, slot becomes free and mgmt could plug a CPU into it
later on.

I don't know if it's used in practice, so the only way to find it out is to
break it and see if someone complains.

Disabling _EJ0 on -smp X cpus looks to me like a policy decision (possible 
config option)
and won't simplify anything in practice (QEMU wise).

(so I'd duck my head into sand due to luck of complains from users)


> >   
> > > 
> > > I would be thankful for your valuable insights and answers and help in 
> > > highlighting any gap in my understanding.
> > > 
> > > Thanks in anticipation!
> > > 
> > > Best Regards
> > > Salil
> > >   
> 
>