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

[Igor Mammedov]

On Tue, 27 Oct 2020 07:26:44 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Oct 26, 2020 at 05:45:37PM +1100, David Gibson wrote:
> > On Fri, 23 Oct 2020 09:26:48 +0300
> > Marcel Apfelbaum <marcel.apfelbaum@gmail.com> wrote:
> >   
> > > Hi Michael,
> > > 
> > > On Thu, Oct 22, 2020 at 6:01 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > 
> > >  [...]  
[...]
> > > Simplistic does not mean wrong or incorrect.
> > > I fail to see why it is not enough.
> > > 
> > > What QEMU can do better? Wait an unbounded time for the blinking to 
> > > finish?  
> > 
> > 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.

> 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.

> But otherwise just buffer the request until such time as
> we can deliver it to guest ...
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).

> > > What if we have a buggy guest with a kernel stuck in blinking?
> > > Is QEMU's responsibility to emulate the operator itself? Because the
> > > operator
> > > is the one who is supposed to wait.
> > > 
> > > 
> > > Thanks,
> > > Marcel
> > > 
> > > [...]  
> > 
> > 
> > -- 
> > David Gibson <dgibson@redhat.com>
> > Principal Software Engineer, Virtualization, Red Hat  
> 
> 
>