From: Zhao Liu <zhao1.liu@intel.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Akihiko Odaki" <akihiko.odaki@daynix.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v2] qdev: Report an error for machine without HotplugHandler
Date: Thu, 21 Dec 2023 00:46:03 +0800 [thread overview]
Message-ID: <ZYMaS8v8sIWhteFm@intel.com> (raw)
In-Reply-To: <87y1dpgvim.fsf@pond.sub.org>
Hi Markus,
On Wed, Dec 20, 2023 at 08:53:21AM +0100, Markus Armbruster wrote:
> Date: Wed, 20 Dec 2023 08:53:21 +0100
> From: Markus Armbruster <armbru@redhat.com>
> Subject: Re: [PATCH v2] qdev: Report an error for machine without
> HotplugHandler
>
> Akihiko Odaki <akihiko.odaki@daynix.com> writes:
>
> > On 2023/12/18 23:02, Markus Armbruster wrote:
> >> Akihiko Odaki <akihiko.odaki@daynix.com> writes:
> >>
> >>> On 2023/12/11 15:51, Markus Armbruster wrote:
> >>>> Akihiko Odaki <akihiko.odaki@daynix.com> writes:
> >>>>
> >>>>> The HotplugHandler of the machine will be used when the parent bus does
> >>>>> not exist, but the machine may not have one. Report an error in such a
> >>>>> case instead of aborting.
> >>>>>
> >>>>> Fixes: 7716b8ca74 ("qdev: HotplugHandler: Add support for unplugging BUS-less devices")
> >>>>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> >>>>
> >>>> Do you have a reproducer for the crash?
> >>>>
> >>>>> ---
> >>>>> Changes in v2:
> >>>>> - Fixed indention.
> >>>>> - Link to v1: https://lore.kernel.org/r/20231202-bus-v1-1-f7540e3a8d62@daynix.com
> >>>>> ---
> >>>>> system/qdev-monitor.c | 13 ++++++++++---
> >>>>> 1 file changed, 10 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> >>>>> index a13db763e5..5fe5d49c20 100644
> >>>>> --- a/system/qdev-monitor.c
> >>>>> +++ b/system/qdev-monitor.c
> >>>>> @@ -927,9 +927,16 @@ void qdev_unplug(DeviceState *dev, Error **errp)
> >>>> void qdev_unplug(DeviceState *dev, Error **errp)
> >>>> {
> >>>> DeviceClass *dc = DEVICE_GET_CLASS(dev);
> >>>> HotplugHandler *hotplug_ctrl;
> >>>> HotplugHandlerClass *hdc;
> >>>> Error *local_err = NULL;
> >>>> if (qdev_unplug_blocked(dev, errp)) {
> >>>> return;
> >>>> }
> >>>> if (dev->parent_bus && !qbus_is_hotpluggable(dev->parent_bus)) {
> >>>> error_setg(errp, QERR_BUS_NO_HOTPLUG, dev->parent_bus->name);
> >>>> return;
> >>>> }
> >>>> if (!dc->hotpluggable) {
> >>>> error_setg(errp, QERR_DEVICE_NO_HOTPLUG,
> >>>> object_get_typename(OBJECT(dev)));
> >>>> return;
> >>>> }
> >>>> if (!migration_is_idle() && !dev->allow_unplug_during_migration) {
> >>>> error_setg(errp, "device_del not allowed while migrating");
> >>>> return;
> >>>> }
> >>>>
> >>>>> qdev_hot_removed = true;
> >>>>> hotplug_ctrl = qdev_get_hotplug_handler(dev);
> >>>>> - /* hotpluggable device MUST have HotplugHandler, if it doesn't
> >>>>> - * then something is very wrong with it */
> >>>>> - g_assert(hotplug_ctrl);
> >>>>> + if (!hotplug_ctrl) {
> >>>>> + /*
> >>>>> + * hotpluggable bus MUST have HotplugHandler, if it doesn't
> >>>>> + * then something is very wrong with it
> >>>>> + */
> >>>>> + assert(!dev->parent_bus);
> >>>>> +
> >>>>> + error_setg(errp, "The machine does not support hotplugging for a device without parent bus");
> >>>>> + return;
> >>>>> + }
> >>>>
> >>>> Extended version of my question above: what are the devices where
> >>>> qdev_get_hotplug_handler(dev) returns null here?
> >>>
> >>> Start a VM: qemu-system-aarch64 -M virt -nographic
> >>> Run the following on its HMP: device_del /machine/unattached/device[0]
> >>>
> >>> It tries to unplug cortex-a15-arm-cpu and crashes.
> >>
> >> This device has no parent bus (dev->parent_bus is null), but is marked
> >> hot-pluggable (dc->hotpluggable is true). Question for somebody
> >> familiar with the hot-plug machinery: is this sane?
> >
> > Setting hotpluggable false for each device without bus_type gives the same effect, but is error-prone.
>
> Having hotpluggable = true when the device cannot be hot-plugged is
> *wrong*. You might be able to paper over the wrongness so the code
> works anyway, but nothing good can come out of lying to developers
> trying to understand how the code works.
>
> Three ideas to avoid the lying:
>
> 1. default hotpluggable to bus_type != NULL.
>
> 2. assert(dc->bus_type || !dc->hotpluggable) in a suitable spot.
>
> 3. Change the meaning of hotpluggable, and rename it to reflect its new
> meaning. Requires a careful reading of its uses. I wouldn't go there.
>
What about 4 (or maybe 3.1) - droping this hotpluggable flag and just use a
helper (like qbus) to check if device is hotpluggable?
This removes the confusion of that flag and also reduces the number of
configuration items for DeviceState that require developer attention.
A simple helper is as follows:
static inline bool qdev_is_hotpluggable(DeviceState *dev)
{
/*
* Many Machines don't implement qdev_hotplug_allowed().
*
* TODO: Once all of them complete missing qdev_hotplug_allowed(),
* use qdev_hotplug_allowed() here.
*/
bool hotpluggable = !!qdev_get_machine_hotplug_handler(dev);
if (!hotpluggable && dev->parent_bus) {
hotpluggable = qbus_is_hotpluggable(dev->parent_bus);
}
return hotpluggable;
}
Thanks,
Zhao
next prev parent reply other threads:[~2023-12-20 16:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 5:34 [PATCH v2] qdev: Report an error for machine without HotplugHandler Akihiko Odaki
2023-12-11 6:51 ` Markus Armbruster
2023-12-13 9:50 ` Akihiko Odaki
2023-12-18 14:02 ` Markus Armbruster
2023-12-19 12:08 ` Akihiko Odaki
2023-12-20 7:53 ` Markus Armbruster
2023-12-20 16:46 ` Zhao Liu [this message]
2023-12-21 6:34 ` Markus Armbruster
2023-12-21 6:36 ` Akihiko Odaki
2023-12-21 8:49 ` Markus Armbruster
2023-12-21 9:36 ` Akihiko Odaki
2024-02-18 5:47 ` Akihiko Odaki
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=ZYMaS8v8sIWhteFm@intel.com \
--to=zhao1.liu@intel.com \
--cc=akihiko.odaki@daynix.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eduardo@habkost.net \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).