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

[Gerd Hoffmann]

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.
Then unplug completes (and qemu sends event).
Then device_del fails because the device doesn't exist any more.

take care,
  Gerd