]> xenbits.xensource.com Git - people/liuw/libxenctrl-split/libvirt.git/commit
qemu: implement <model> subelement to <controller>
authorLaine Stump <laine@laine.org>
Thu, 25 Jun 2015 19:37:33 +0000 (15:37 -0400)
committerLaine Stump <laine@laine.org>
Mon, 10 Aug 2015 01:33:58 +0000 (21:33 -0400)
commit572ebdbce7c1d629706882f620d640fc611a9642
treec85e025aef47a530b2569cc5f0dfb3ca5a973c55
parentbf20251048534022efe21785f98949c772ce7a71
qemu: implement <model> subelement to <controller>

This patch provides qemu support for the contents of <model> in
<controller> for the two existing PCI controller types that need it
(i.e. the two controller types that are backed by a device that must
be specified on the qemu commandline):

1) pci-bridge - sets <model> name attribute default as "pci-bridge"

2) dmi-to-pci-bridge - sets <model> name attribute default as
   "i82801b11-bridge".

These both match current hardcoded practice.

The defaults are set at the end of qemuDomainAssignPCIAddresses().
This can't be done earlier because some of the options that will be
autogenerated need full PCI address info for the controller, and
because qemuDomainAssignPCIAddresses() might create extra controllers
which would need default settings added, and that hasn't yet been done
at the time the PostParse callbacks are being run.
qemuDomainAssignPCIAddresses() is still called prior to the XML being
written to disk, though, so the autogenerated defaults are persistent.

qemu capabilities bits aren't checked when the domain is defined, but
rather when the commandline is actually created (so the domain can
possibly be defined on a host that doesn't yet have support for the
given device, or a host different from the one where it will
eventually be run). When the commandline is being generated we compare
the modelName to known qemu device names implementing the given type
of controller, and check the capabilities bit for that device.
src/qemu/qemu_command.c