Re: [PATCH 6/6] pcie: expire pending delete

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

On Tue, Oct 12, 2021 at 08:44:45AM +0200, Gerd Hoffmann wrote:
> On Tue, Oct 12, 2021 at 01:46:35AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Oct 12, 2021 at 07:30:34AM +0200, Gerd Hoffmann wrote:
> > > > > index f3ac04399969..477c8776aa27 100644
> > > > > --- a/hw/pci/pcie.c
> > > > > +++ b/hw/pci/pcie.c
> > > > > @@ -549,6 +549,8 @@ void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev,
> > > > >      }
> > > > >  
> > > > >      dev->pending_deleted_event = true;
> > > > > +    dev->pending_deleted_expires_ms =
> > > > > +        qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 5000; /* 5 secs */
> > > > >  
> > > > >      /* In case user cancel the operation of multi-function hot-add,
> > > > >       * remove the function that is unexposed to guest individually,
> > > > 
> > > > 
> > > > Well this will be barely enough, right?
> > > > 
> > > > 	Once the Power
> > > > 	Indicator begins blinking, a 5-second abort interval exists during which a second depression of the
> > > > 	Attention Button cancels the operation.
> > > 
> > > Well, canceling the hot-plug is not supported in qemu right now (there
> > > is no qmp command for that).  I'm also not sure it makes sense in the
> > > first place for virtual machines.
> > 
> > Yes. However if you resend an attention button press within the
> > 5 second window, guest will think you cancelled hot-plug
> > and act accordingly.
> > It's a fundamentally racy algorithm :(
> 
> That's why re-sending an attention button press is blocked
> for 5 seconds.
> It's also blocked in case the guest blinks the power
> indicator (see patch #3).
> 
> Both together work well in my testing, I can flood a (linux) guest
> with device_del commands without bad side effects:
> 
> First device_del command sends attention button press.
> Then device_del is rejected because the 5 secs are not over yet.
> Then device_del is rejected because the indicator blinks.

Ah, I see. 5 secs is a lot so yea, most likely it's gonnu
be ok, worst case we'll wait another 5 seconds and
send again, right?

Worth checking with windows guests BTW, we saw lots of
races with these too.


> Then unplug completes (and qemu sends event).
> Then device_del fails because the device doesn't exist any more.
> 
> take care,
>   Gerd