[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qom device lifecycle interaction with hotplug/hotunplug ?

From: Jens Freimann
Subject: Re: qom device lifecycle interaction with hotplug/hotunplug ?
Date: Wed, 4 Dec 2019 10:18:24 +0100
User-agent: NeoMutt/20180716-1376-5d6ed1

On Tue, Dec 03, 2019 at 06:40:04PM -0300, Eduardo Habkost wrote:
+jfreimann, +mst

On Sat, Nov 30, 2019 at 11:10:19AM +0000, Peter Maydell wrote:
On Fri, 29 Nov 2019 at 20:05, Eduardo Habkost <address@hidden> wrote:
> So, to summarize the current issues:
> 1) realize triggers a plug operation implicitly.
> 2) unplug triggers unrealize implicitly.
> Do you expect to see use cases that will require us to implement
> realize-without-plug?

I don't think so, but only because of the oddity that
we put lots of devices on the 'sysbus' and claim that
that's plugging them into the bus. The common case of
'realize' is where one device (say an SoC) has a bunch of child
devices (like UARTs); the SoC's realize method realizes its child
devices. Those devices all end up plugged into the 'sysbus'
but there's no actual bus there, it's fictional and about
the only thing it matters for is reset propagation (which
we don't model right either). A few devices don't live on
buses at all.

That's my impression as well.

> Similarly, do you expect use cases that will require us to
> implement unplug-without-unrealize?

I don't know enough about hotplug to answer this one:
it's essentially what I'm hoping you'd be able to answer.
I vaguely had in mind that eg the user might be able to
create a 'disk' object, plug it into a SCSI bus, then
unplug it from the bus without the disk and all its data
evaporating, and maybe plug it back into the SCSI
bus (or some other SCSI bus) later ? But I don't know
anything about how we expose that kind of thing to the
user via QMP/HMP.

This ability isn't exposed to the user at all.  Our existing
interfaces are -device, device_add and device_del.

We do have something new that sounds suspiciously similar to
"unplugged but not unrealized", though: the new hidden device
API, added by commit f3a850565693 ("qdev/qbus: add hidden device

Jens, Michael, what exactly is the difference between a "hidden"
device and a "unplugged" device?

"hidden" the way we use it for virtio-net failover is actually unplugged. But it
doesn't have to be that way. You can register a function that decides
if the device should be hidden, i.e. plugged now, or do something else
with it (in the virtio-net failover case we just save everything we
need to plug the device later).
We did introduce a "unplugged but not unrealized" function too as part
of the failover feature. See "a99c4da9fc pci: mark devices partially

This was needed so we would be able to re-plug the device in case a
migration failed and we need to hotplug the primary device back to the
guest. To avoid the risk of not getting the resources the device needs
we don't unrealize but just trigger the unplug from the guest OS.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]