qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH V2] Add a new PIIX option to control PCI hot unplugging of de


From: Michael S. Tsirkin
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

On Wed, Apr 29, 2020 at 10:20:31AM +0000, Ani Sinha wrote:
> 
> 
> > On Apr 29, 2020, at 3:45 PM, Michael S. Tsirkin <address@hidden> 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 <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]