qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ani Sinha <ani.sinha@nutanix.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Aleksandar Markovic" <aleksandar.qemu.devel@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Ani Sinha" <ani@anisinha.ca>,
	"Igor Mammedov" <imammedo@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, 29 Apr 2020 06:30:19 -0400	[thread overview]
Message-ID: <20200429062136-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7F9D8AE0-FC4B-4CF3-A206-FCAEB0DD4CE6@nutanix.com>

On Wed, Apr 29, 2020 at 10:20:31AM +0000, Ani Sinha wrote:
> 
> 
> > On Apr 29, 2020, at 3:45 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > 
> > On Wed, Apr 29, 2020 at 09:14:26AM +0000, Ani Sinha wrote:
> >> 
> >> 
> >>> On Apr 29, 2020, at 2:26 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>> 
> >>> Even if it seems to work for guests now, if we don't stick to emulating
> >>> capabilities that hardware interfaces provide we can never be sure it
> >>> will keep working.
> >> 
> >> OS es use ACPI for PCI bridges: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_qemu_qemu_blob_master_docs_pcie.txt&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=IIUxIyRwG4RGy57y2nvMNYcDkqW-NHozZ2R38VYcg5U&m=9AnuR62iRsUnmV9ggkS_lqen67etHeCjATFLwCJWxQs&s=As__N9BXf0DTSZkD4cxaQsTeg0exh5GSPqkFSh7fxRk&e= 
> >> They use “_EJ0” to detect jot unplug capability: https://urldefense.proofpoint.com/v2/url?u=https-3A__uefi.org_sites_default_files_resources_ACPI-5F3.pdf&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=IIUxIyRwG4RGy57y2nvMNYcDkqW-NHozZ2R38VYcg5U&m=9AnuR62iRsUnmV9ggkS_lqen67etHeCjATFLwCJWxQs&s=SDgOhKGpnlzfbvAOFl2m9a-tdPZEUcCwKWsgkVDafyM&e= 
> >> 
> >> 6.3.3 _EJx (Eject) These control methods are optional and are supplied for devices that support a software-controlled VCRstyle ejection mechanism or that require an action be performed such as isolation of power/data lines before the device can be removed from the system. To support warm (system is in a sleep state) and hot (system is in S0) removal, an _EJx control method is listed for each sleep state from which the device supports removal, where x is the sleeping state supported. For example, _EJ0 indicates the device supports hot removal; _EJ1–EJ4 indicate the device supports warm removal.
> > 
> > Yes. So if there's no _EJx then it's reasonable to assume you can't
> > isolate the slot, and so no hot-plug will happen either.
> 
> Where are you getting that?

It's well known. For example, the pci hot-plug specification, version
1.1, states:

1.6 Asssumptions

...

1.6.2 Orderly Removal and Insertion

...

Furthermore, PCI add-in cards are not generally designed to be connected to a slot that
has power applied. Therefore, the operating-system vendor and Platform vendor define a
sequence of user actions and system behavior that guarantees that power is always
removed from a slot before a card is inserted.

Inserting or removing an add-in card without following the proper sequence leads to
unpredictable results, including data corruption, abnormal termination of the operating
system, or damage to card or Platform hardware. Unless otherwise stated, it is assumed
throughout the remainder of this specification that the user always follows the proper
removal and insertion sequence.

...


2.1 System Components

...

The physical
insertion or removal must not occur until the system software has:
• Quiesced any operating system services or drivers using the add-in card
• Isolated and powered down the slot
• Indicated to the user that it is ready
If an add-in card is inserted or removed without following the proper sequence, this is
considered an improper operation and error conditions and other unexpected events are
possible, including data corruption and hardware damage.

and so on.


> This isn’t true. “_SUN” is used to detect the slot unique number.

That's just enumeration.

> Windows does allow hot plugging on the bridge on which EJ0 has been turned off.

Given no real or virtual hardware that does that, there's no guarantee
that I can see that it will keep supporting that in future versions.


> > 
> >> 
> >> Note that “these control methods are optional” line. If the OS adheres to the spec, it should not expect them to exist all the time.
> >> 
> > 
> > 
> > 
> > -- 
> > MST
> > 
> 



  reply	other threads:[~2020-04-29 10:33 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 [this message]
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
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=20200429062136-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=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 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).