[libvirt] [PATCH 1/6] extend usb controller model to support xen pvusb

Laine Stump laine at laine.org
Tue Jun 14 15:29:22 UTC 2016


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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160614/df06e039/attachment-0001.htm>


More information about the libvir-list mailing list