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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Oct 27, 2020 at 01:54:26PM +0100, Igor Mammedov wrote:
> 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?

PCIESlot maybe?

> * what would be the request in this case, i.e. create PCI device anyways
> and try to signal hotplug event later?


that was my idea, yes.

> * what would baremethal do in such case?

exactly the same, human would wait until blinking stops.

> * what to do in case guest is never ready, what user should do in such case?

As in guest is stuck? Do we care? It can't use the device.

> * can be such device be removed?

why not? device_del could complete immediately ...

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

I'd say let's get expected behaviour for existing commands first.
We can add events and stuff on top.

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