qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: libvir-list@redhat.com, Julia Suvorova <jusual@redhat.com>,
	qemu-devel@nongnu.org, Laine Stump <laine@redhat.com>
Subject: Re: Disabling PCI "hot-unplug" for a guest (and/or a single PCI device)
Date: Wed, 5 Feb 2020 11:36:37 +0000	[thread overview]
Message-ID: <20200205113637.GE2221087@redhat.com> (raw)
In-Reply-To: <20200204113457-mutt-send-email-mst@kernel.org>

On Tue, Feb 04, 2020 at 11:35:37AM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 04, 2020 at 05:13:54PM +0100, Julia Suvorova wrote:
> > On Tue, Feb 4, 2020 at 11:26 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Mon, Feb 03, 2020 at 05:19:51PM -0500, Laine Stump wrote:
> > > > 3) qemu could add a "hotpluggable=no" commandline option to all PCI devices
> > > > (including vfio-pci) and then do whatever is necessary to make sure this is
> > > > honored in the emulated hardware (is it possible to set this on a per-slot
> > > > basis in a PCI controller? Or must it be done for an entire controller?
> > >
> > > I think it's possible on a per-slot basis, yes.
> > 
> > There's a "Hot-Plug Capable" option in Slot Capability register, so we
> > can switch it off. But it's only for pcie devices, can't say anything
> > about conventional pci.
> > 
> > Best regards, Julia Suvorova.
> 
> For conventional PCI, we can drop SHPC capability and remove
> the eject method from ACPI.

Before considering this, is there any compelling reason to care about
this for PCI ?  Currently with i440fx there's no direct representation
of the 32 slots as objects in either QEMU or libvirt. So extending this
to allow disabling hotplug for i440fx PCI slots is going to need much
more config work for QEMU, libvirt and mgmt apps.  Personally I'd only
do this for PCIe until there's a clear requirement given for legacy PCI
support too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2020-02-05 11:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03 22:19 Disabling PCI "hot-unplug" for a guest (and/or a single PCI device) Laine Stump
2020-02-04 10:24 ` Michael S. Tsirkin
2020-02-04 16:13   ` Julia Suvorova
2020-02-04 16:35     ` Michael S. Tsirkin
2020-02-05 11:36       ` Daniel P. Berrangé [this message]
2020-02-05 13:10         ` Michael S. Tsirkin
2020-02-04 18:43 ` Daniel P. Berrangé
2020-02-05 16:29   ` Laine Stump

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=20200205113637.GE2221087@redhat.com \
    --to=berrange@redhat.com \
    --cc=jusual@redhat.com \
    --cc=laine@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mst@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 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).