On Fri, 24 Jan 2020 15:02:10 +0000 Salil Mehta <salil.me...@huawei.com> wrote:
> > From: Igor Mammedov [mailto:imamm...@redhat.com] > > Sent: Friday, January 24, 2020 1:54 PM > > To: Salil Mehta <salil.me...@huawei.com> > > > > On Fri, 24 Jan 2020 11:20:15 +0000 > > Salil Mehta <salil.me...@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. >
