On Tue, Oct 19, 2021 at 07:21:44AM +0200, Gerd Hoffmann wrote: > On Mon, Oct 18, 2021 at 11:36:45AM -0400, Michael S. Tsirkin wrote: > > On Mon, Oct 11, 2021 at 02:04:58PM +0200, Gerd Hoffmann wrote: > > > > > > > > > Gerd Hoffmann (6): > > > pci: implement power state > > > pcie: implement slow power control for pcie root ports > > > pcie: add power indicator blink check > > > pcie: factor out pcie_cap_slot_unplug() > > > pcie: fast unplug when slot power is off > > > pcie: expire pending delete > > > > So what's left to do here? > > I'm guessing more testing? > > Yes. Maybe ask rh qe to run the patch set through their hotplug test > suite (to avoid a apci-hotplug style disaster where qe found various > issues after release)?
I'll poke around to see if they can help us... we'll need a backport for that though. > > I would also like to see a shorter timeout, maybe 100ms, so > > that we are more responsive to guest changes in resending request. > > I don't think it is a good idea to go for a shorter timeout given that > the 5 seconds are in the specs and we want avoid a resent request being > interpreted as cancel. > It also wouldn't change anything at least for linux guests because linux > is waiting those 5 seconds (with power indicator in blinking state). > Only the reason for refusing 'device_del' changes from "5 secs not over > yet" to "guest is busy processing the hotplug request". First 5 seconds yes. But the retries afterwards? > > We could consider to tackle the 5sec timeout on the guest side, i.e. > have linux skip the 5sec wait in case the root port is virtual (should > be easy to figure by checking the pci id). > > take care, > Gerd Yes ... do we want to control how long it blinks from hypervisor side? And if we do then what? Shorten retry period? -- MST
