On 18.11.2015 21:19, Laine Stump wrote:
While playing with the idea of forcing explicit USB controller
models, I
ended up with the qemuargv2xml test failing; it ended up that this was
because changes I had made to qemuDomainDefPostParse() were affecting
the XML produced by qemuParseCommandline(). The reason - after
constructing a virDomainDef object by parsing a qemu commandline,
qemuParseCommandline() calls two functions that are supposed to be
called after parsing domain XML - virDomainDefPostParse() (which calls
qemuDomainDefPostParse()).
I'm afraid you are touching area of the code that is not maintained.
Brace yourself :)
In my opinion, qemuParseCommandLine() shouldn't be calling
virDomainDefPostParse() (or virDomainefAddImplicitControllers(), which
it calls in the wrong order relative to virDomainDefPostParse() BTW).
The reasons are:
1) this is causing the argv-to-xml conversion to include things in the
XML that were not on the original commandline, in particular "default"
devices like PCI and USB controllers (added in qemuDomainDefPostParse()
based on machinetype) as well as disk, smartcard, virtio-serial, and
hostdev-scsi controllers in virDomainDefAddImplicitControllers() (why
the duality there, anyway?)
Hold on, so they are not even visible in the guest? I mean, if I run
qemu by hand, don't I always get virtio-serial? If not, then we should
not add them during cmd line parse.
2) If the output of argv-to-xml is used for a virDomainDefine, those
post-parse functions will be called then, and the implicit/auto devices
will be added at that time anyway, so in practice nothing is gained by
adding them during argv-to-xml.
Correct.
Does anyone else have an opinion about this?
I believe there's not much gain in calling post parse callbacks during
cmd line parsing.
Michal