On Sun, 2018-02-11 at 08:12 -0500, John Ferlan wrote: > On 02/05/2018 11:08 AM, Andrea Bolognani wrote: > > The input configurations set all existing options for all PCI > > controllers, to see what ends up showing up in the output. > > Not quite sure I understand the need. The only capability not currently > used in some way is QEMU_CAPS_I440FX_PCI_HOLE64_SIZE. The idea is that existing tests only cover valid PCI controller options being handled correctly, not what happens when you specify an option which is not relevant to the PCI controller at hand. > I guess there's nothing wrong with adding them other than test bloat. > Still there's nothing to "force" someone that adds some new thing to > update one of the three if some new option/capability is added. That's correct. Can you think of a way to make sure that happens? > Ironically adding (for example) QEMU_CAPS_Q35_PCI_HOLE64_SIZE to > i440fx-* doesn't cause any failure. I didn't try other ones. Of course it wouldn't: capabilities are a property of the QEMU binary, and the same QEMU binary is used to run both i440fx and q35 guests. Even for something entirely outlandish like adding a q35-specific capability to a pSeries test you shouldn't see any failure unless you actually attempt to use the QEMU feature the capability is tied to. > I'm not opposed to this being added, but do you think we should add > something does the opposite check? That the wrong PCI adapter on the > wrong machine? The wrong option on the wrong adapter is a question for > the next patch though... We should already have at least *some* coverage for that, eg. pseries-serial-invalid-machine and similar. I'm certainly not volunteering to go over all controller and device and machine types and write tests for all combinations :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
