From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, "Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH 0/6] RfC: try improve native hotplug for pcie root ports
Date: Mon, 1 Nov 2021 17:47:05 -0400 [thread overview]
Message-ID: <20211101174531-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20211019062919.35wnhiwimr7l3574@sirius.home.kraxel.org>
On Tue, Oct 19, 2021 at 08:29:19AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > 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.
>
> Easy, it's a clean cherry-pick for 6.1, scratch build is on the way.
>
> > > > 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?
>
> Hmm, maybe, but I'd tend to keep it simple and go for 5 secs no matter
> what. If the guest isn't responding (maybe because it is in the middle
> of a reboot) it's unlikely that fast re-requests are fundamentally
> changing things.
>
> > > 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?
>
> Is there a good reason for that?
> If not, then no. Keep it simple.
>
> When the guest powers off the slot pcie_cap_slot_write_config() will
> happily unplug the device without additional checks (no check whenever
> the 5 seconds are over, also no check whenever there is a pending unplug
> request in the first place).
>
> So in theory the guest turning off slot power quickly should work just
> fine and speed up the unplug process in the common case (guest is
> up'n'running and responsitive). Down to 1-2 secs instead of 5-7.
> Didn't actually test that though.
>
> take care,
> Gerd
Even if this speeds up unplug, hotplug remains slow, right?
--
MST
next prev parent reply other threads:[~2021-11-01 21:50 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 12:04 [PATCH 0/6] RfC: try improve native hotplug for pcie root ports Gerd Hoffmann
2021-10-11 12:04 ` [PATCH 1/6] pci: implement power state Gerd Hoffmann
2021-10-11 12:05 ` [PATCH 2/6] pcie: implement slow power control for pcie root ports Gerd Hoffmann
2021-10-11 12:05 ` [PATCH 3/6] pcie: add power indicator blink check Gerd Hoffmann
2021-11-15 11:29 ` Michael S. Tsirkin
2021-11-15 14:52 ` Gerd Hoffmann
2021-10-11 12:05 ` [PATCH 4/6] pcie: factor out pcie_cap_slot_unplug() Gerd Hoffmann
2021-10-11 12:05 ` [PATCH 5/6] pcie: fast unplug when slot power is off Gerd Hoffmann
2021-10-12 5:56 ` Michael S. Tsirkin
2021-10-12 6:46 ` Gerd Hoffmann
2021-10-11 12:05 ` [PATCH 6/6] pcie: expire pending delete Gerd Hoffmann
2021-10-11 12:49 ` Michael S. Tsirkin
2021-10-12 5:30 ` Gerd Hoffmann
2021-10-12 5:46 ` Michael S. Tsirkin
2021-10-12 6:44 ` Gerd Hoffmann
2021-10-12 7:01 ` Michael S. Tsirkin
2021-10-18 15:36 ` [PATCH 0/6] RfC: try improve native hotplug for pcie root ports Michael S. Tsirkin
2021-10-19 5:21 ` Gerd Hoffmann
2021-10-19 5:46 ` Michael S. Tsirkin
2021-10-19 6:29 ` Gerd Hoffmann
2021-11-01 21:47 ` Michael S. Tsirkin [this message]
2021-11-02 12:09 ` Gerd Hoffmann
2021-11-10 12:02 ` Michael S. Tsirkin
2021-11-11 7:53 ` Gerd Hoffmann
2021-11-11 8:20 ` Michael S. Tsirkin
2021-11-11 9:34 ` Gerd Hoffmann
2021-11-11 12:09 ` Gerd Hoffmann
2021-11-11 15:39 ` Michael S. Tsirkin
2021-11-12 11:15 ` Gerd Hoffmann
2021-11-12 12:17 ` Igor Mammedov
2021-11-15 11:13 ` Michael S. Tsirkin
2021-11-11 9:35 ` Daniel P. Berrangé
2021-11-11 17:11 ` Michael S. Tsirkin
2021-11-11 18:08 ` Daniel P. Berrangé
2021-11-11 18:43 ` Michael S. Tsirkin
2021-11-12 10:16 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211101174531-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.