From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: pbonzini <pbonzini@redhat.com>,
Salil Mehta <salil.mehta@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"eric.auger@redhat.com" <eric.auger@redhat.com>
Subject: Re: [Question] Regarding containers "unattached/peripheral/anonymous" - their relation with hot(un)plug of devices
Date: Mon, 3 Feb 2020 05:40:01 -0500 [thread overview]
Message-ID: <20200203053819-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200124145404.1d15209e@redhat.com>
On Fri, Jan 24, 2020 at 02:54:04PM +0100, Igor Mammedov wrote:
> 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.
>
> > 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).
It might be cleaner to skip it for CPUs which don't have an id - what
do you think?
>
> >
> > 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
> >
next prev parent reply other threads:[~2020-02-03 10:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 11:20 [Question] Regarding containers "unattached/peripheral/anonymous" - their relation with hot(un)plug of devices Salil Mehta
2020-01-24 13:54 ` Igor Mammedov
2020-01-24 15:02 ` Salil Mehta
2020-01-24 16:06 ` Igor Mammedov
2020-01-24 18:44 ` Salil Mehta
2020-01-27 15:03 ` Igor Mammedov
2020-06-03 15:13 ` Salil Mehta
2020-06-04 9:54 ` Igor Mammedov
2020-06-04 11:08 ` Salil Mehta
2020-02-03 10:40 ` Michael S. Tsirkin [this message]
2020-02-03 15:48 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200203053819-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=eric.auger@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=salil.mehta@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).