[libvirt] [PATCH REBASE 1/2] tests: Add some tests for PCI controller options

[John Ferlan]

On 02/12/2018 04:32 AM, Andrea Bolognani wrote:
> 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.
> 

Well I understood you're going for a put the stake in the ground in
order to supply that valid list of options for the pci controllers on
the related machines.

>> 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?
> 

and of course that got me to wondering if it was possible in any way to
have some way that the "i440fx" xml2{xml|argv} to know that it's
"covering" all it's known and supported relative options.  Secondarily
to know when someone adds something to a machine that won't support it
before they get to the point of actually running and things falling over
dead because of the wrong configuration provided.

Nothing sprang quickly to mind to try other than adding comments which
we all know are ignored anyway ;-0...

I'm not against this patch going in, but if someone has agita over a
small about of test bloat to list everything "currently" possible for a
machine type then they should speak up!

>> 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 :)
> 

We have something - good...

John