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
