From: "Michael S. Tsirkin" <mst@redhat.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] pciehp: fast unplug for virtual machines
Date: Sun, 14 Nov 2021 17:37:15 -0500 [thread overview]
Message-ID: <20211114173550-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20211114180604.GA23907@wunner.de>
On Sun, Nov 14, 2021 at 07:06:04PM +0100, Lukas Wunner wrote:
> On Sun, Nov 14, 2021 at 12:24:43PM -0500, Michael S. Tsirkin wrote:
> > On Sun, Nov 14, 2021 at 05:39:58PM +0100, Lukas Wunner wrote:
> > > Why does virtual hardware implement the Attention Button if it's
> > > perceived as annoying? Just amend qemu so that it doesn't advertise
> > > presence of an Attention Button to get rid of the delay. (Clear the
> > > Attention Button Present bit in the Slot Capabilities register.)
> >
> > Because we want ability to request device removal from outside the
> > guest.
>
> Please elaborate. Does "outside the guest" mean on the host?
> How do you represent the Attention Button outside the guest
> and route events through to the guest?
The usual way, using kvm ioctls.
>
> > > An Attention Button doesn't make any sense for virtual hardware
> > > except to test or debug support for it in the kernel. Just make
> > > presence of the Attention Button optional and be done with it.
> > >
> > > You'll still be able to bring down the slot in software via the
> > > "remove" attribute in sysfs.
> >
> > This requires guest specific code though. Emulating the attention button
> > works in a guest independent way.
>
> It sounds like you're using the Attention Button because it does
> almost, but not quite what you want for your specific use case.
> Now you're trying to change its behavior in a way that deviates
> from the spec to align it with your use case.
>
> Why don't you just trigger surprise-removal from outside the guest?
>
> Thanks,
>
> Lukas
Because linux does not handle it well for all devices. Fixing that
requires fixing all drivers.
--
MST
next prev parent reply other threads:[~2021-11-14 22:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 9:02 [PATCH] pciehp: fast unplug for virtual machines Gerd Hoffmann
2021-11-11 17:00 ` Michael S. Tsirkin
2021-11-12 9:56 ` Gerd Hoffmann
2021-11-12 10:09 ` Michael S. Tsirkin
2021-11-11 21:50 ` Bjorn Helgaas
2021-11-12 11:28 ` Gerd Hoffmann
2021-11-12 0:00 ` Krzysztof Wilczyński
2021-11-14 16:39 ` Lukas Wunner
2021-11-14 17:24 ` Michael S. Tsirkin
2021-11-14 18:06 ` Lukas Wunner
2021-11-14 22:37 ` Michael S. Tsirkin [this message]
2021-11-15 9:59 ` Gerd Hoffmann
2021-11-15 7:45 ` Lukas Wunner
2021-11-15 10:09 ` 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=20211114173550-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=bhelgaas@google.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
/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.