On 05/11/2012 01:42 AM, Michael S. Tsirkin wrote:
> On Fri, May 11, 2012 at 01:17:38AM +0800, Jiang Liu wrote:
>> On 05/09/2012 03:24 PM, Amos Kong wrote:
>>
>>> ---
>>> src/ssdt-pcihp.dsl | 17
>>> src/ssdt-pcihp.hex | 8869 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>>> 2 files changed, 8781 insertions(+), 105 deletions(-)
>>>
>>> diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl
>>> index 4b435b8..2a3c326 100644
>>> --- a/src/ssdt-pcihp.dsl
>>> +++ b/src/ssdt-pcihp.dsl
>>> @@ -17,14 +17,23 @@ DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1)
>>> // at runtime, if the slot is detected to not support hotplug.
>>> // Extract the offset of the address dword and the
>>> // _EJ0 name to allow this patching.
>>> -#define hotplug_slot(slot) \
>>> - Device (S##slot) { \
>>> +#define hotplug_func(slot, fn) \
>>> + Device (S##slot##fn) { \
>>> ACPI_EXTRACT_NAME_DWORD_CONST aml_adr_dword \
>>> - Name (_ADR, 0x##slot##0000) \
>>> + Name (_ADR, 0x##slot##000##fn) \
>>> ACPI_EXTRACT_METHOD_STRING aml_ej0_name \
>>> Method (_EJ0, 1) { Return(PCEJ(0x##slot)) } \
>>> Name (_SUN, 0x##slot) \
>>> }
>> It would be perfect if the Device object could also support _PS0 and _STA
>> methods.
>
> It needs qemu support, and some backward compatibility hack.
> Why?
>
>> Could we re-add the slot back after hot-removing it from the guest
>> OS with this ACPI implementation? Say execute following scripts from guest OS.
>> echo 0 > /sys/bus/pci/slot/xx/power
>> echo 1 > /sys/bus/pci/slot/xx/power
>
> No because qemu removes device after eject.
> Do you have a need for this functionality? What is it?
I'm not familiar with qemu:(
On native OS, admin could trigger PCI device hotplug operations through
/sys/bus/pci/slot/xx/power. Not sure whether that's needed for guest OS too.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
