[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Question] Regarding containers "unattached/peripheral/anonymous" -
Re: [Question] Regarding containers "unattached/peripheral/anonymous" - their relation with hot(un)plug of devices
Fri, 24 Jan 2020 17:06:45 +0100
On Fri, 24 Jan 2020 15:02:10 +0000
Salil Mehta <address@hidden> wrote:
> > From: Igor Mammedov [mailto:address@hidden]
> > Sent: Friday, January 24, 2020 1:54 PM
> > To: Salil Mehta <address@hidden>
> > 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.
> 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
> 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
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
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.
why you are looking into 'what container' is used for CPUs?
1) here is what I could find on IDs topic
> > > 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.
> 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:
> > > 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?
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