All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedow <imammedo@redhat.com>
Cc: "Ani Sinha" <ani.sinha@nutanix.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Julia Suvorova" <jusual@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Aleksandar Markovic" <aleksandar.qemu.devel@gmail.com>,
	"Ani Sinha" <ani@anisinha.ca>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [PATCH V2] Add a new PIIX option to control PCI hot unplugging of devices on non-root buses
Date: Wed, 20 May 2020 05:47:53 -0400	[thread overview]
Message-ID: <20200520054714-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20200520114354.1982cb63@nas.mammed.net>

On Wed, May 20, 2020 at 11:43:54AM +0200, Igor Mammedow wrote:
> On Fri, 15 May 2020 12:13:53 +0000
> Ani Sinha <ani.sinha@nutanix.com> wrote:
> 
> > > On May 14, 2020, at 1:13 AM, Igor Mammedov <imammedo@redhat.com>
> > > wrote: 
> > >> 
> > >>   
> > >>> Will following hack work for you?
> > >>> possible permutations
> > >>> 1) ACPI hotplug everywhere
> > >>> -global PIIX4_PM.acpi-pci-hotplug=on -global
> > >>> PIIX4_PM.acpi-pci-hotplug-with-bridge-support=on -device
> > >>> pci-bridge,chassis_nr=1,shpc=doesnt_matter -device
> > >>> e1000,bus=pci.1,addr=01,id=netdev1 
> > >>> 
> > >>> 2) No hotplug at all
> > >>> -global PIIX4_PM.acpi-pci-hotplug=off -global
> > >>> PIIX4_PM.acpi-pci-hotplug-with-bridge-support=on -device
> > >>> pci-bridge,chassis_nr=1,shpc=off -device
> > >>> e1000,bus=pci.1,addr=01,id=netdev1
> > >>> 
> > >>> -global PIIX4_PM.acpi-pci-hotplug=off -global
> > >>> PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off -device
> > >>> pci-bridge,chassis_nr=1,shpc=doesnt_matter  -device
> > >>> e1000,bus=pci.1,addr=01,id=netdev1    
> > >> 
> > >> Given that my patch is not acceptable, I’d prefer the following in
> > >> the order of preference:
> > >> 
> > >> (a) Have an option to disable hot ejection of PCI-PCI bridge so
> > >> that Windows does not even show this HW in the “safely remove HW”
> > >> option. If we can do this then from OS perspective the GUI options
> > >> will be same as what is available with PCIE/q35 - none of the
> > >> devices will be hot ejectable if the hot plug option is turned off
> > >> from the PCIE slots where devices are plugged into. I looked at
> > >> the code. It seems to manipulate ACPI tables of the empty slots of
> > >> the root bus where no devices are attached (see comment "/* add
> > >> hotplug slots for non present devices */ “). For cold plugged
> > >> bridges, it recurses down to scan the slots of the bridge. Is it
> > >> possible to disable hot plug for the slot to which the bridge is
> > >> attached?  
> > > 
> > > I don't think it's possible to have per slot hotplug on
> > > conventional PCI hardware. it's per bridge property.  
> > 
> > We add the AMLs per empty slot though. When the pic bridge is
> > attached, we do nothing, just recurse into the bridge slots. That is
> > what I was asking, if it was possible to just disable the AMLs or use
> > some tricks to say that this particular slot is not hotpluggable. I
> > am not sure why Windows is trying to eject the PCI bridge and
> > failing. Maybe something related to this comment?
> > 
> > 
> > /* When hotplug for bridges is enabled, bridges are
> >                               
> >          * described in ACPI separately (see build_pci_bus_end).
> >                                       
> >          * In this case they aren't themselves hot-pluggable.
> >                                       
> >          * Hotplugged bridges *are* hot-pluggable.
> > */
> 
> thinking some more on this topic, it seems that with ACPI hotplug we
> already have implicit non-hotpluggble slot (slot with bridge) while
> the rest are staying hotpluggable.
> 
> So my question is: if it's acceptable to add 'PCIDevice::hotpluggable"
> property to all PCI devices so that user / libvirt could set it to
> false in case they do not want coldplugged device be considered as
> hotpluggable? (this way other devices could be treated the same way as
> bridges)
> 
> [...]


I think Julia already posted a patch adding this to downstream pcie
bridges. Adding this to pci slots sounds like a reasonable thing.

-- 
MST



  reply	other threads:[~2020-05-20  9:48 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 10:16 [PATCH V2] Add a new PIIX option to control PCI hot unplugging of devices on non-root buses Ani Sinha
2020-04-28 10:20 ` Ani Sinha
2020-04-28 16:05 ` Michael S. Tsirkin
2020-04-28 16:09   ` Ani Sinha
2020-04-28 16:21     ` Michael S. Tsirkin
2020-04-28 16:40       ` Ani Sinha
2020-04-28 20:45         ` Michael S. Tsirkin
2020-04-29  0:58           ` Ani Sinha
2020-04-29  5:28             ` Michael S. Tsirkin
2020-04-29  5:59               ` Ani Sinha
2020-04-29  6:11               ` Ani Sinha
2020-04-29  6:52                 ` Michael S. Tsirkin
2020-04-29  6:54                   ` Ani Sinha
2020-04-29  6:57                     ` Michael S. Tsirkin
2020-04-29  7:02                       ` Ani Sinha
2020-04-29  7:38                         ` Michael S. Tsirkin
2020-04-29  7:43                           ` Ani Sinha
2020-04-29  8:09                             ` Michael S. Tsirkin
2020-04-29  8:14                               ` Ani Sinha
2020-04-29  8:56                                 ` Michael S. Tsirkin
2020-04-29  9:14                                   ` Ani Sinha
2020-04-29  9:18                                     ` Ani Sinha
2020-04-29 10:15                                     ` Michael S. Tsirkin
2020-04-29 10:20                                       ` Ani Sinha
2020-04-29 10:30                                         ` Michael S. Tsirkin
2020-04-29 10:37                                           ` Ani Sinha
2020-04-30 17:12                             ` Ani Sinha
2020-04-28 16:28   ` Daniel P. Berrangé
2020-04-28 16:30     ` Michael S. Tsirkin
2020-04-28 16:33       ` Daniel P. Berrangé
2020-04-28 20:44         ` Michael S. Tsirkin
2020-05-11 18:53 ` Igor Mammedov
2020-05-12  5:26   ` Ani Sinha
2020-05-13 19:43     ` Igor Mammedov
2020-05-15 12:13       ` Ani Sinha
2020-05-20  9:43         ` Igor Mammedow
2020-05-20  9:47           ` Michael S. Tsirkin [this message]
2020-05-20  9:56             ` Igor Mammedow
2020-05-20 10:06               ` Daniel P. Berrangé
2020-05-20 11:29                 ` Michael S. Tsirkin
2020-05-20 11:42                   ` Daniel P. Berrangé
2020-05-20 11:44                     ` Michael S. Tsirkin
2020-05-20 10:28               ` Michael S. Tsirkin
2020-05-20 11:05                 ` Igor Mammedow
2020-05-20 11:23                   ` Michael S. Tsirkin
2020-05-20 12:20                     ` Igor Mammedow
2020-05-20 16:13                       ` Michael S. Tsirkin
2020-05-21  7:32                         ` Igor Mammedow
2020-05-21 10:07                           ` Michael S. Tsirkin
2020-05-21 13:23                             ` Igor Mammedov
2020-05-21 15:40                               ` Laine Stump
2020-05-26  5:32                                 ` Ani Sinha

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=20200520054714-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=aleksandar.qemu.devel@gmail.com \
    --cc=ani.sinha@nutanix.com \
    --cc=ani@anisinha.ca \
    --cc=aurelien@aurel32.net \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jusual@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.