On 02/22/2017 12:53 PM, Andrea Bolognani wrote:
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.
That all sounds fine to me.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
