On Tue, 4 Apr 2023 08:40:45 -0400 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Tue, Apr 04, 2023 at 01:06:38PM +0530, Ani Sinha wrote: > > > > > > On Tue, 4 Apr 2023, Gerd Hoffmann wrote: > > > > > Hi, > > > > > > > > Allowing pending delete expire brings ACPI PCI hotplug on par > > > > > with native PCIe unplug behavior [1] which in its turn refers > > > > > back to ACPI PCI hotplug ability to repeat unplug requests. > > > > > > > A bit concerned about how this interacts with failover, > > > > and 5sec is a lot of time that I hoped we'd avoid with acpi. > > > > Any better ideas of catching such misbehaving guests? > > > > > > The 5sec are coming from the pcie spec: The hot-unplug request can be > > > canceled within 5 seconds by pressing the button again. The problem here > > > is that both hotplug and hot-unplug use the same signaling path, so we > > > really have to wait the 5 seconds to avoid the OS mis-interpreting the > > > button press as 'cancel' event. > > > > > > ACPI hotplug hasn't this problem. A unplug request is a unplug request, > > > > For ACPI case, I think all we want is to make sure that the first unplug > > event to not stick forever. A non-zero but small delay would make sure > > that the first > > unplug event would get cleared after that interval and subsequent unplug > > events will get registered without that error. > > > > > period. And it can't be canceled. So it should be possible to use a > > > shorter period. Possibly even no delay at all. > > > > > > take care, > > > Gerd > > > > > > > > > But why do we want a delay at all? for acpi you can resend > the interrupt as many times as you like. yep, we can. It makes possible for user to cause limited "interrupt storm". That also leads to device_del abuse [1] 1) https://www.mail-archive.com/qemu-devel@nongnu.org/msg952738.html
