Re: [PATCH v2 00/16] Crazy shit around -global (pardon my french)

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> Cc: David for insurance against me spewing nonsense about migration.
> 
> John Snow <jsnow@redhat.com> writes:
> 
> > On 6/25/20 12:45 AM, Markus Armbruster wrote:
> >> John Snow <jsnow@redhat.com> writes:
> >> 
> >>> On 6/22/20 5:42 AM, Markus Armbruster wrote:
> >>>> There are three ways to configure backends:
> >>>>
> >>>> * -nic, -serial, -drive, ... (onboard devices)
> >>>>
> >>>> * Set the property with -device, or, if you feel masochistic, with
> >>>>   -set device (pluggable devices)
> >>>>
> >>>> * Set the property with -global (both)
> >>>>
> >>>> The trouble is -global is terrible.
> >>>>
> >>>> It gets applied in object_new(), which can't fail.  We treat failure
> >>>> to apply -global as fatal error, except when hot-plugging, where we
> >>>> treat it as warning *boggle*.  I'm not addressing that today.
> >>>>
> >>>> Some code falls apart when you use both -global and the other way.
> >>>>
> >>>> To make life more interesting, we gave -drive two roles: with
> >>>> interface type other than none, it's for configuring onboard devices,
> >>>> and with interface type none, it's for defining backends for use with
> >>>> -device and such.  Since we neglect to require interface type none for
> >>>> the latter, you can use one -drive in both roles.  This confuses the
> >>>> code about as much as you, dear reader, probably are by now.
> >>>>
> >>>> Because this still isn't interesting enough, there's yet another way
> >>>> to configure backends, just for floppies: set the floppy controller's
> >>>> property.  Goes back to the time when floppy wasn't a separate device,
> >>>> and involves some Bad Magic.  Now -global can interact with itself!
> >>>>
> >>>> Digging through all this took me an embarrassing amount of time.
> >>>> Hair, too.
> >>>>
> >>>> My patches reject some the silliest uses outright, and deprecate some
> >>>> not so silly ones that have replacements.
> >>>>
> >>>> Apply on top of my "[PATCH v2 00/58] qdev: Rework how we plug into the
> >>>> parent bus".
> >>>>
> >>>
> >>> Oof. Thank you for your work in fixing our darkest corners. I sincerely
> >>> appreciate it.
> >>>
> >>> The qdev tree ordering problems don't cause any issues for migration, do
> >>> they?
> >> 
> >> This series should only change device configuration, not device state or
> >> its encoding in the migration stream.
> >> 
> >> I'm not sure what you mean by "qdev tree ordering problems".  Ist it
> >> commit e8c9e65816 'qom: Make "info qom-tree" show children sorted'?
> >> 
> >>> (I see you already sent a PR, so whatever!)
> >> 
> >> A question that might avoid a later migration debugging session is
> >> *never* "whatever"!
> >> 
> >
> > I thought I had read that one of these patches changes the order in
> > which devices get instantiated, which I thought might change their QOM
> > paths. Which I thought *might* have some ramifications for migration,
> > but wasn't sure.
> 
> Device instantiation order changes should not break migration.

They shouldn't; although I only narrowly stopped a new device from
making a mistake that would have made it dependent.
Of course you do have to explicitly state PCI/USB slot IDs otherwise the
allocation of those is order dependent.

> The order in which devices appear in the migration stream should not
> matter.

Order in the stream is a separate issue; we have ways to enforce that;
for example you want the interrupt controller to arrive before a device
that will raise an interrupt.

Dave


Dave

> > If it's just showing the same path outputs *sorted*, then there's no
> > problem.
> >
> > Likely misread.
> >
> > --js
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK