On 06/14/2016 01:02 AM, Jim Fehlig wrote:
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> >index 490260f..5c3de83 100644
> >--- a/src/qemu/qemu_command.c
> >+++ b/src/qemu/qemu_command.c
> >@@ -133,6 +133,10 @@ VIR_ENUM_IMPL(qemuControllerModelUSB,
VIR_DOMAIN_CONTROLLER_MODEL_USB_LAST,
> > "vt82c686b-usb-uhci",
> > "pci-ohci",
> > "nec-usb-xhci",
> >+ "pvusb1",
> >+ "pvusb2",
> >+ "qusb1",
> >+ "qusb2",
> > "none");
It seems odd that these need to be added to qemu_command.c. But sadly, I'm not
familiar with how USB controllers are handled in the qemu driver to give much
useful feedback at this time. I can certainly start investigating that, but in
the meantime I've added Laine to the cc list. He has done quite a bit of work in
this area in the past and might have a few minutes free to comment on these changes.
This enum exists because the model strings recognized/stored by
libvirt's XML parser are slightly different from the exact name of the
devices on the qemu commandline. For example, if you put "ehci" in the
XML, the device that qemu uses is called "usb-ehci". Internally (in the
domain object) it is stored as an enum value, and when we create the
qemu commandline we use qemuControllerModelUSBTypeToString(model) to get
the name of the device.
This points out a couple of things:
1) the VIR_ENUM_IMPL for qemuControllerModelUSB and
virDomainontrollerModelUSB must be kept in sync (this is partly enforced
by the VIR_ENUM_IMPL() macro, which checks that the array of strings has
as many entries as VIR_DOMAIN_CONTROLLER_MODEL_USB_LAST).
2) If new models are added that aren't supported in a particular
hypervisor, the post-parse validation for that hypervisor should check
for those models and flag them as errors.