[libvirt] [PATCH v5 2/4] qemu: Add PCI-Express root to ARM virt machine

[Martin Kletzander]

On Fri, Aug 07, 2015 at 09:32:56AM +0300, Pavel Fedin wrote:
> Hello!
>
>> >So every ARM qemu with the "virt" machine type supports both PCI and
>> >multiqueue?
>
>Every ARM qemu with "virt" machine AND pci-generic supports them.
>
>>>  How about those "virt-*" for which you check below.  That
>> >might not be related, I'm just curious.
>
> Actually mainstream qemu doesn't have "virt-" at all. Commit message where this has been introduced
>says that this is reserved for distro maintainers. And everywhere "virt-" has been added as an alias
>for "virt", so i just followed this policy.
> What these "virt-" machines really do, depends on their authors. I simply don't know.
>

OK, that's very reasonable then.  If the maintainer adds some 'virt-'
type, they can also add the proper checks for it.

>> >Few questions here.  a) how "temporary" is this since you're not
>> >removing it in this series?
>
> Well, we could discuss it. Personally, i don't have much time to work on the test suite, to tell
>the truth... But, i know, no developer likes documenting and/or testing :)
>
>> > b) for what tests you need this hack
>
> For every qemu-related tests. If you want to see it, you can omit the condition and run "make
>check", the first qemu test will crash upon NULL dereference in virQEMUCapsCacheLookup().
>
>> > and what part of the below is the hack?
>
> The hack is "if (driver->qemuCapsCache)" check. Our test suite does not create the cache, instead
>it builds "caps" object directly and passes around the pointer to all functions which take it. It is
>actually not really difficult to fix this. The test suite should mock up qemuCapsCache too.
>

The qemuxml2argvtest mocks the capability cache, so it must be
qemuxml2xmltest.  And that one should do *nothing* with any
capabilities.  Merely because whatever it does must work without any
qemu installed in the system.

Moreover the test might produce different results for different QEMU
binaries installed in the system, which is even worse.

>Kind regards,
>Pavel Fedin
>Expert Engineer
>Samsung Electronics Research center Russia
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150807/8da53b79/attachment-0001.sig>