On Wed, 4 Dec 2019 15:51:06 -0300
Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Wed, Dec 04, 2019 at 05:21:25PM +0100, Jens Freimann wrote:
> > On Wed, Dec 04, 2019 at 11:35:37AM -0300, Eduardo Habkost wrote:
> > > On Wed, Dec 04, 2019 at 10:18:24AM +0100, Jens Freimann wrote:
> > > > 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 <ehabk...@redhat.com>
> > > > > > 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
> > > > > support").
> > > > >
> > > > > 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
> > > > unplugged"
> > > >
> > > > 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.
> > >
> > > Thanks for the explanation. Let me confirm if I understand the
> > > purpose of the new mechanisms: should_be_hidden is a mechanism
> > > for implementing realize-without-plug. partially_hotplugged is a
> > > mechanism for implementing unplug-without-unrealize. Is that
> > > correct?
> >
> > should_be_hidden is a mechanism for implementing
> > realize-without-plug: kind of. It's a mechanism that ensures
> > qdev_device_add() returns early as long as the condition to hide the
> > device is true. You could to the realize-without-plug in the handler
> > function that decides if the device should be "hidden".
>
> Oh, right. I thought "qdev_device_add() returns early" meant
> "return after realize, before plug". Now I see it returns before
> object_new(). This means we have another user-visible device
> state: "defined (in QemuOpts), but not created".
If I'm not mistaken this new behavior was introduced because
vfio-pci is not split on backend and frontend like majority
of pluggable devices, so the only option (apart from doing split)
was to fake unplug to avoid releasing resources that should be
owned y backend.
> >
> > partially_hotplugged is a mechanism for implementing
> > unplug-without-unrealize: yes.
>
> Thanks!
>
