qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default
Date: Wed, 16 Nov 2016 19:05:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

On 11/16/2016 06:44 PM, Andrew Jones wrote:
On Sat, Nov 05, 2016 at 06:46:34PM +0200, Marcel Apfelbaum wrote:
On 11/03/2016 09:40 PM, Michael S. Tsirkin wrote:
On Thu, Nov 03, 2016 at 01:05:44PM +0200, Marcel Apfelbaum wrote:
On 11/03/2016 06:18 AM, Michael S. Tsirkin wrote:
On Wed, Nov 02, 2016 at 05:16:42PM +0200, Marcel Apfelbaum wrote:
The shpc component is optional while  ACPI hotplug is used
for hot-plugging PCI devices into a PCI-PCI bridge.
Disabling the shpc by default will make slot 0 usable at boot time

Hi Michael


at the cost of breaking all hotplug for all non-acpi users.


Do we have a non-acpi user that is able to use the shpc component as-is today?

power and some arm systems I guess?


Adding Andrew , maybe he can give us an answer.

Not really :-) My lack of PCI knowledge makes that difficult. I'd be happy
to help with an experiment though. Can you give me command line arguments,
qmp commands, etc. that I should use to try it out? I imagine I should
just boot an ARM guest using DT (instead of ACPI) and then attempt to
hotplug a PCI device. I'm not sure, however, what, if any, special
configuration I need in order to ensure I'm testing what you're
interested in.


Hi Drew,


Just run QEMU with '-device pci-bridge,chassis_nr=1,id=bridge1 -monitor stdio'
with an ARM guest using DT and wait until the guest finish booting.

Then run at hmp:
device_add virtio-net-pci,bus=bridge1,id=net2

Next run lspci in the guest to see the new device.


BTW, will an ARM guest run 'fast' enough to be usable on a x86 machine?
If yes, any pointers on how to create such a guest?


Thanks,
Marcel




Thanks,
drew



[...]



reply via email to

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