linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: "Michael S. Tsirkin" <mst@redhat.com>
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 19:06:04 +0100	[thread overview]
Message-ID: <20211114180604.GA23907@wunner.de> (raw)
In-Reply-To: <20211114122249-mutt-send-email-mst@kernel.org>

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?


> > 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

  reply	other threads:[~2021-11-14 18:06 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 [this message]
2021-11-14 22:37       ` Michael S. Tsirkin
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=20211114180604.GA23907@wunner.de \
    --to=lukas@wunner.de \
    --cc=bhelgaas@google.com \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mst@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).