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