Re: [PATCH] pci: Refuse to hotplug PCI Devices when the Guest OS is not ready

From: David Gibson <dgibson@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Julia Suvorova <jusual@redhat.com>,
	qemu devel list <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] pci: Refuse to hotplug PCI Devices when the Guest OS is not ready
Date: Wed, 28 Oct 2020 14:31:35 +1100	[thread overview]
Message-ID: <20201028143135.51c0a918@yekko.fritz.box> (raw)
In-Reply-To: <20201027135426.765dd19b@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

On Tue, 27 Oct 2020 13:54:26 +0100
Igor Mammedov <imammedo@redhat.com> wrote:

> On Tue, 27 Oct 2020 07:26:44 -0400
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
>  [...]  
>  [...]  
>  [...]  
> [...]
>  [...]  
> > > 
> > > It certainly shouldn't wait an unbounded time.  But a wait with timeout
> > > seems worth investigating to me.    
> racy, timeout is bound to break once it's in overcommited env.

Hm.  That's no less true at the management layer than it is at the qemu
layer.

> > If it's helpful, I'd add a query to check state
> > so management can figure out why doesn't guest see device yet.  
> that means mgmt would have to poll it and forward it to user
> somehow.

If that even makes sense.  In the case of Kata, it's supposed to be
autonomously creating the VM, so there's nothing meaningful it can
forward to the user other than "failed to create the container because
of some hotplug problem that means nothing to you".

>  [...]  
> I have more questions wrt the suggestion/workflow:
> * at what place would you suggest buffering it?
> * what would be the request in this case, i.e. create PCI device anyways
> and try to signal hotplug event later?
> * what would baremethal do in such case?
> * what to do in case guest is never ready, what user should do in such case?
> * can be such device be removed?
> 
> not sure that all of this is worth of the effort and added complexity.
> 
> alternatively:
> maybe ports can send QMP events about it's state changes, which end user would
> be able to see + error like in this patch.
> 
> On top of it, mgmt could build a better UIx, like retry/notify logic if
> that's what user really wishes for and configures (it would be up to user to
> define behaviour).

That kind of makes sense if the user is explicitly requesting hotplugs,
but that's not necessarily the case.

-- 
David Gibson <dgibson@redhat.com>
Principal Software Engineer, Virtualization, Red Hat

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]