[libvirt] [PATCH 3/3] conf: restrict where dmi-to-pci-bridge can be connected
Laine Stump
laine at laine.org
Mon Aug 8 19:33:44 UTC 2016
On 08/08/2016 02:25 PM, Andrea Bolognani wrote:
> On Fri, 2016-08-05 at 23:01 -0400, Laine Stump wrote:
>> libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a
>> normal PCIe endpoint can be connected, but this is wrong - it will
>> only work if it's plugged into pcie-root (the PCIe root complex) or a
>> pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the
>> connection flags accordingly.
>>
>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363648
> Doesn't
>
> https://bugzilla.redhat.com/1363648#c4
>
> tell us that we *need* to use a pcie-root-port when plugging
> stuff into a pcie-expander-bus?
No, I think you're misunderstanding Marcel's comment:
> (In reply to Laine Stump fromcomment #2 <https://bugzilla.redhat.com/show_bug.cgi?id=1363648#c2>)
> > Marcel - is this actually supported by qemu?
>
> Yes, and if doesn't work is a bug.
> The best way to think of pxb/pbx-pcie is that it exposes a new pcie.0 like bus.
> The only difference is that you cannot have devices plugged directly into it (integrated device).
I specifically asked him if what the reporter attempted (plugging a
dmi-to-pci-bridge directly into a pcie-expander-bus) was supported, and
he said "yes".
He then said that the only difference is that you can't plug [endpoint]
devices directly into it. A dmi-to-pci-bridge is not an endpoint device.
Aside from endpoint devices, the only other things you are supposed to
plug into pcie-root are pcie-root-ports and dmi-to-pci-bridges.
>
> Looks good otherwise, but I'd like to have Marcel's confirm
> that plugging a dmi-to-pci-bridge directly into a
> pcie-expander-bus is something we want before you push it.
I'll wait for Marcel to respond as well, but without this, there is no
way to put a legacy PCI slot in a NUMA node on a Q35 guest, and it
*does* apparently work.
>
>> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
>> index d594836..933f9be 100644
>> --- a/tests/qemuxml2argvtest.c
>> +++ b/tests/qemuxml2argvtest.c
>> @@ -1631,6 +1631,22 @@ mymain(void)
>> QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_ICH9_USB_EHCI1,
>> QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
>> QEMU_CAPS_VGA_QXL, QEMU_CAPS_DEVICE_QXL);
>> + DO_TEST_PARSE_ERROR("q35-dmi-bad-address1",
>> + QEMU_CAPS_DEVICE_PCI_BRIDGE,
>> + QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
>> + QEMU_CAPS_DEVICE_IOH3420,
>> + QEMU_CAPS_ICH9_AHCI,
>> + QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_ICH9_USB_EHCI1,
>> + QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
>> + QEMU_CAPS_VGA_QXL, QEMU_CAPS_DEVICE_QXL);
>> + DO_TEST_PARSE_ERROR("q35-dmi-bad-address2",
>> + QEMU_CAPS_DEVICE_PCI_BRIDGE,
>> + QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE,
>> + QEMU_CAPS_DEVICE_IOH3420,
>> + QEMU_CAPS_ICH9_AHCI,
>> + QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_ICH9_USB_EHCI1,
>> + QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
>> + QEMU_CAPS_VGA_QXL, QEMU_CAPS_DEVICE_QXL);
>> DO_TEST("q35-pm-disable",
>> QEMU_CAPS_DEVICE_PCI_BRIDGE,
>> QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE, QEMU_CAPS_ICH9_AHCI,
> Can you maybe trim the capabilities a bit? QEMU_CAPS_VGA_QXL
> and friends look like they're hardly a requirement for a test
> case about PCI bridges.
Sure, I can remove those caps, but I think I'll also need to remove the
<video> from the XML. (consider them removed).
>
> Of course I'm okay with this if you're already planning to
> post a follow-up patch that trims the capabilities of all
> q35-* test cases ;)
I'll leave the mass changes to test case files to Cole :-P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160808/24ebb533/attachment-0001.htm>
More information about the libvir-list
mailing list