On Wed, 2017-02-22 at 09:58 -0500, Laine Stump wrote:
> On 02/21/2017 02:57 PM, Andrea Bolognani wrote:
> >
> > Now that QEMU_CAPS_DEVICE_PCI_BRIDGE is no longer checked
> > unless a pci-bridge is really part of the configuration,
> > and most uses of the legacy PCI controller combo have been
> > dropped from tests that use PCIe machine types, we can
> > drop the corresponding capabilities from a lot of test
> > cases.
>
> ACK?
>
> But what about a hypothetical test that could alert us to a regression
> if e.g. a dmi-to-pci-bridge was added when a pcie-root-port should have
> been, but it doesn't trigger a failure because the capability for
> dmi-to-pci-bridge wasn't set for the test case.
>
> (I guess I don't have a problem with extra caps being set in test cases,
> especially since they make the test cases more similar to real usage.)
How about we leave the {DMI_TO_,}PCI_BRIDGE capability
enabled for three/four of the test cases that we know
don't need them, eg. q35, q35-pcie, q35-virtio-pci and
q35-pcie-autoadd for this purpose, along with a comment
explaining why we've done so? That would still catch a
regression.
By the way, I just noticed I might have missed a few
droppable capabilities; moreover, some test cases don't
seem to be using the same capabilities in xml2argv and
in xml2xml, which is definitely not cool.
So if you're okay with the approach suggested above
I'll take care of all these issues and prepare a v2.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
