<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 08/08/2016 02:25 PM, Andrea Bolognani wrote: </div> <blockquote cite="mid:1470680707.2264.18.camel@redhat.com" type="cite"> <pre wrap="">On Fri, 2016-08-05 at 23:01 -0400, Laine Stump wrote: </pre> <blockquote type="cite"> <pre wrap="">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: <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1363648">https://bugzilla.redhat.com/show_bug.cgi?id=1363648</a> </pre> </blockquote> <pre wrap=""> Doesn't <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/1363648#c4">https://bugzilla.redhat.com/1363648#c4</a> tell us that we *need* to use a pcie-root-port when plugging stuff into a pcie-expander-bus?</pre> </blockquote> No, I think you're misunderstanding Marcel's comment: <pre class="bz_comment_text bz_wrap_comment_text" id="comment_text_4">> (In reply to Laine Stump from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1363648#c2">comment #2</a>) > > 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).</pre> 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. <blockquote cite="mid:1470680707.2264.18.camel@redhat.com" type="cite"> <pre wrap=""> 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.</pre> </blockquote> 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. <blockquote cite="mid:1470680707.2264.18.camel@redhat.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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, </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> Sure, I can remove those caps, but I think I'll also need to remove the <video> from the XML. (consider them removed). <blockquote cite="mid:1470680707.2264.18.camel@redhat.com" type="cite"> <pre wrap=""> 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 ;)</pre> </blockquote> I'll leave the mass changes to test case files to Cole :-P </body> </html>