| Message ID | 1457622051-30189-4-git-send-email-jgross@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: > Add a new pvusb backend type "qusb" which is provided by qemu. It can > be selected either by specifying the type directly in the configuration > or it is selected automatically by libxl in case there is no "usbback" > driver loaded. > > Signed-off-by: Juergen Gross <jgross@suse.com> It would be awesome if we could get a patch like this in for 4.7. However... > --- > docs/man/xl.cfg.pod.5 | 11 +++- > tools/libxl/libxl_device.c | 3 +- > tools/libxl/libxl_dm.c | 8 +++ > tools/libxl/libxl_internal.h | 1 + > tools/libxl/libxl_pvusb.c | 102 +++++++++++++++++++++++++++-------- > tools/libxl/libxl_types.idl | 1 + > tools/libxl/libxl_types_internal.idl | 1 + > 7 files changed, 101 insertions(+), 26 deletions(-) > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > index 1dde66b..06eeb42 100644 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -737,8 +737,15 @@ Possible B<KEY>s are: > > =item B<type=TYPE> > > -Specifies the usb controller type. Currently only 'pv' and 'auto' > -are supported. > +Specifies the usb controller type. > + > +"pv" denotes a kernel based pvusb backend. > + > +"qusb" specifies a qemu base backend for pvusb. > + > +"auto" (the default) determines whether a kernel based backend is installed. > +If this is the case, "pv" is selected, "qusb" will be selected if no kernel > +backend is currently available. I'm going back and forth a bit about whether having a "qusb" option here makes the most sense, or whether it makes more sense to have a separate option, like "backendtype" (as we have for disks). The reason I suggested having "type" here at all is that libxl cannot know ahead of time whether the guest has pvusbfront available. It *can*, however, tell whether pvusbback is available (as your code demonstrates). On the other hand -- given that qemu will shortly have pvusbback, I'm wondering if it's possible to make pvusbfront do something similar to what the blkfront drivers do -- write a magic port that tell qemu, "Actually, I have pvusb drivers; unplug the emulated controller." From a UI point of view that would be the best, right? Just like disks or network cards -- you can simply say you want a controller, and you automatically get the most appropriate kind based on what the kernel you run actually has available. I think you've been working on the pvusbfront drivers for Linux, as well as the qusb backend in qemu -- do you think that's workable? If so, I think adding 'qusb' to this field is probably the right thing to do. One technical question... > @@ -1559,7 +1616,6 @@ int libxl_ctrlport_to_device_usbdev(libxl_ctx *ctx, > dompath = libxl__xs_get_dompath(gc, domid); > > fe_path = GCSPRINTF("%s/device/vusb/%d", dompath, ctrl); Did you miss a vusb -> %s here? -George
On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: > Add a new pvusb backend type "qusb" which is provided by qemu. It can > be selected either by specifying the type directly in the configuration > or it is selected automatically by libxl in case there is no "usbback" > driver loaded. > > Signed-off-by: Juergen Gross <jgross@suse.com> Oh, last thing -- shouldn't we have a way for libxl to tell whether qemu can provide a qusb backend before we offer to start it up? -George
On 17/03/16 17:39, George Dunlap wrote: > On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >> Add a new pvusb backend type "qusb" which is provided by qemu. It can >> be selected either by specifying the type directly in the configuration >> or it is selected automatically by libxl in case there is no "usbback" >> driver loaded. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > It would be awesome if we could get a patch like this in for 4.7. > > However... > >> --- >> docs/man/xl.cfg.pod.5 | 11 +++- >> tools/libxl/libxl_device.c | 3 +- >> tools/libxl/libxl_dm.c | 8 +++ >> tools/libxl/libxl_internal.h | 1 + >> tools/libxl/libxl_pvusb.c | 102 +++++++++++++++++++++++++++-------- >> tools/libxl/libxl_types.idl | 1 + >> tools/libxl/libxl_types_internal.idl | 1 + >> 7 files changed, 101 insertions(+), 26 deletions(-) >> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 >> index 1dde66b..06eeb42 100644 >> --- a/docs/man/xl.cfg.pod.5 >> +++ b/docs/man/xl.cfg.pod.5 >> @@ -737,8 +737,15 @@ Possible B<KEY>s are: >> >> =item B<type=TYPE> >> >> -Specifies the usb controller type. Currently only 'pv' and 'auto' >> -are supported. >> +Specifies the usb controller type. >> + >> +"pv" denotes a kernel based pvusb backend. >> + >> +"qusb" specifies a qemu base backend for pvusb. >> + >> +"auto" (the default) determines whether a kernel based backend is installed. >> +If this is the case, "pv" is selected, "qusb" will be selected if no kernel >> +backend is currently available. > > I'm going back and forth a bit about whether having a "qusb" option > here makes the most sense, or whether it makes more sense to have a > separate option, like "backendtype" (as we have for disks). > > The reason I suggested having "type" here at all is that libxl cannot > know ahead of time whether the guest has pvusbfront available. It > *can*, however, tell whether pvusbback is available (as your code > demonstrates). > > On the other hand -- given that qemu will shortly have pvusbback, I'm > wondering if it's possible to make pvusbfront do something similar to > what the blkfront drivers do -- write a magic port that tell qemu, > "Actually, I have pvusb drivers; unplug the emulated controller." > > From a UI point of view that would be the best, right? Just like > disks or network cards -- you can simply say you want a controller, > and you automatically get the most appropriate kind based on what the > kernel you run actually has available. > > I think you've been working on the pvusbfront drivers for Linux, as > well as the qusb backend in qemu -- do you think that's workable? Hmm, could work. This would require the frontend to register rather early at boot in order to bind the devices to it before the emulated USB connector can grab them, right? Or would the emulated USB devices seem to be unplugged from the emulated adapter and then again plugged in via the pvusb frontend? > If so, I think adding 'qusb' to this field is probably the right thing to do. > > One technical question... > >> @@ -1559,7 +1616,6 @@ int libxl_ctrlport_to_device_usbdev(libxl_ctx *ctx, >> dompath = libxl__xs_get_dompath(gc, domid); >> >> fe_path = GCSPRINTF("%s/device/vusb/%d", dompath, ctrl); > > Did you miss a vusb -> %s here? No. The frontend won't need to know whether the backend is kernel or qemu based. Juergen
On 17/03/16 17:55, George Dunlap wrote: > On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >> Add a new pvusb backend type "qusb" which is provided by qemu. It can >> be selected either by specifying the type directly in the configuration >> or it is selected automatically by libxl in case there is no "usbback" >> driver loaded. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > Oh, last thing -- shouldn't we have a way for libxl to tell whether > qemu can provide a qusb backend before we offer to start it up? How? Is this possible for qdisk? Or for an emulated frame buffer? Juergen
On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote: > On 17/03/16 17:55, George Dunlap wrote: > > On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: > >> Add a new pvusb backend type "qusb" which is provided by qemu. It can > >> be selected either by specifying the type directly in the configuration > >> or it is selected automatically by libxl in case there is no "usbback" > >> driver loaded. > >> > >> Signed-off-by: Juergen Gross <jgross@suse.com> > > > > Oh, last thing -- shouldn't we have a way for libxl to tell whether > > qemu can provide a qusb backend before we offer to start it up? > > How? Is this possible for qdisk? Or for an emulated frame buffer? > I don't think it is possible at the moment. But I think you might be able to do it either via qmp command or parsing qemu help string. The latter functionality is implemented in Ian's device model deprivilege patch series IIRC -- but it is not yet merged either. Wei. > > Juergen >
On 24/03/16 21:07, Wei Liu wrote: > On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote: >> On 17/03/16 17:55, George Dunlap wrote: >>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >>>> Add a new pvusb backend type "qusb" which is provided by qemu. It can >>>> be selected either by specifying the type directly in the configuration >>>> or it is selected automatically by libxl in case there is no "usbback" >>>> driver loaded. >>>> >>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>> >>> Oh, last thing -- shouldn't we have a way for libxl to tell whether >>> qemu can provide a qusb backend before we offer to start it up? >> >> How? Is this possible for qdisk? Or for an emulated frame buffer? >> > > I don't think it is possible at the moment. But I think you might be > able to do it either via qmp command or parsing qemu help string. The > latter functionality is implemented in Ian's device model deprivilege > patch series IIRC -- but it is not yet merged either. Won't help for qusb, as there is no qemu parameter or help text related to the backend. It would be possible to add a qmp command to print the supported backend types, of course. Juergen
On Fri, Mar 25, 2016 at 6:09 AM, Juergen Gross <jgross@suse.com> wrote: > On 24/03/16 21:07, Wei Liu wrote: >> On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote: >>> On 17/03/16 17:55, George Dunlap wrote: >>>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >>>>> Add a new pvusb backend type "qusb" which is provided by qemu. It can >>>>> be selected either by specifying the type directly in the configuration >>>>> or it is selected automatically by libxl in case there is no "usbback" >>>>> driver loaded. >>>>> >>>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>>> >>>> Oh, last thing -- shouldn't we have a way for libxl to tell whether >>>> qemu can provide a qusb backend before we offer to start it up? >>> >>> How? Is this possible for qdisk? Or for an emulated frame buffer? >>> >> >> I don't think it is possible at the moment. But I think you might be >> able to do it either via qmp command or parsing qemu help string. The >> latter functionality is implemented in Ian's device model deprivilege >> patch series IIRC -- but it is not yet merged either. > > Won't help for qusb, as there is no qemu parameter or help text related > to the backend. It would be possible to add a qmp command to print the > supported backend types, of course. Well as I understand it, for qemu-upstream we can't assume what version of qemu we'll end up getting: we need to be compatible with recent releases of qemu which don't provide qusb. Which I'm pretty sure means failing gracefully (i.e., giving a sensible warning message) if someone tries to add qusb when their qemu binary doesn't support it. If you can tell from the qemu failure that qusb is at fault, that's OK I think; but if not, I think you'll have to add some way to query whether qusb is supported by the qemu binary before starting it. -George
On 29/03/16 11:45, George Dunlap wrote: > On Fri, Mar 25, 2016 at 6:09 AM, Juergen Gross <jgross@suse.com> wrote: >> On 24/03/16 21:07, Wei Liu wrote: >>> On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote: >>>> On 17/03/16 17:55, George Dunlap wrote: >>>>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >>>>>> Add a new pvusb backend type "qusb" which is provided by qemu. It can >>>>>> be selected either by specifying the type directly in the configuration >>>>>> or it is selected automatically by libxl in case there is no "usbback" >>>>>> driver loaded. >>>>>> >>>>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>>>> >>>>> Oh, last thing -- shouldn't we have a way for libxl to tell whether >>>>> qemu can provide a qusb backend before we offer to start it up? >>>> >>>> How? Is this possible for qdisk? Or for an emulated frame buffer? >>>> >>> >>> I don't think it is possible at the moment. But I think you might be >>> able to do it either via qmp command or parsing qemu help string. The >>> latter functionality is implemented in Ian's device model deprivilege >>> patch series IIRC -- but it is not yet merged either. >> >> Won't help for qusb, as there is no qemu parameter or help text related >> to the backend. It would be possible to add a qmp command to print the >> supported backend types, of course. > > Well as I understand it, for qemu-upstream we can't assume what > version of qemu we'll end up getting: we need to be compatible with > recent releases of qemu which don't provide qusb. Which I'm pretty > sure means failing gracefully (i.e., giving a sensible warning > message) if someone tries to add qusb when their qemu binary doesn't > support it. > > If you can tell from the qemu failure that qusb is at fault, that's OK > I think; but if not, I think you'll have to add some way to query > whether qusb is supported by the qemu binary before starting it. So we would want a qemu command line option (e.g. -xen-help) printing the supported pv backends. I think this should be easy to setup. Juergen
On 29/03/16 12:35, Juergen Gross wrote: > On 29/03/16 11:45, George Dunlap wrote: >> On Fri, Mar 25, 2016 at 6:09 AM, Juergen Gross <jgross@suse.com> wrote: >>> On 24/03/16 21:07, Wei Liu wrote: >>>> On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote: >>>>> On 17/03/16 17:55, George Dunlap wrote: >>>>>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote: >>>>>>> Add a new pvusb backend type "qusb" which is provided by qemu. It can >>>>>>> be selected either by specifying the type directly in the configuration >>>>>>> or it is selected automatically by libxl in case there is no "usbback" >>>>>>> driver loaded. >>>>>>> >>>>>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>>>>> >>>>>> Oh, last thing -- shouldn't we have a way for libxl to tell whether >>>>>> qemu can provide a qusb backend before we offer to start it up? >>>>> >>>>> How? Is this possible for qdisk? Or for an emulated frame buffer? >>>>> >>>> >>>> I don't think it is possible at the moment. But I think you might be >>>> able to do it either via qmp command or parsing qemu help string. The >>>> latter functionality is implemented in Ian's device model deprivilege >>>> patch series IIRC -- but it is not yet merged either. >>> >>> Won't help for qusb, as there is no qemu parameter or help text related >>> to the backend. It would be possible to add a qmp command to print the >>> supported backend types, of course. >> >> Well as I understand it, for qemu-upstream we can't assume what >> version of qemu we'll end up getting: we need to be compatible with >> recent releases of qemu which don't provide qusb. Which I'm pretty >> sure means failing gracefully (i.e., giving a sensible warning >> message) if someone tries to add qusb when their qemu binary doesn't >> support it. >> >> If you can tell from the qemu failure that qusb is at fault, that's OK >> I think; but if not, I think you'll have to add some way to query >> whether qusb is supported by the qemu binary before starting it. > > So we would want a qemu command line option (e.g. -xen-help) printing > the supported pv backends. I think this should be easy to setup. Actually there is a solution which is _really_ simple: before setting it's state to "running" in xenstore, qemu could write the supported backend types to xenstore, too. I'd add a xenstore directory /local/domain/<backend-domid>/device-model/<domid>/backends containing a directory for each supported backend. By using a directory for each backend it would even be possible to indicate supported features and/or parameters in the future. "qusb" backend would be regarded to be supported only if /local/domain/<backend-domid>/device-model/<domid>/backends/qusb is existing. "qdisk" would be regarded to be supported if either: - /local/domain/<backend-domid>/device-model/<domid>/backends/qdisk is existing or: - /local/domain/<backend-domid>/device-model/<domid>/backends is not existing. Juergen
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 1dde66b..06eeb42 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -737,8 +737,15 @@ Possible B<KEY>s are: =item B<type=TYPE> -Specifies the usb controller type. Currently only 'pv' and 'auto' -are supported. +Specifies the usb controller type. + +"pv" denotes a kernel based pvusb backend. + +"qusb" specifies a qemu base backend for pvusb. + +"auto" (the default) determines whether a kernel based backend is installed. +If this is the case, "pv" is selected, "qusb" will be selected if no kernel +backend is currently available. =item B<version=VERSION> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index 4ced9b6..eba3087 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -680,7 +680,8 @@ void libxl__devices_destroy(libxl__egc *egc, libxl__devices_remove_state *drs) aodev->action = LIBXL__DEVICE_ACTION_REMOVE; aodev->dev = dev; aodev->force = drs->force; - if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB) + if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB || + dev->backend_kind == LIBXL__DEVICE_KIND_QUSB) libxl__initiate_device_usbctrl_remove(egc, aodev); else libxl__initiate_device_generic_remove(egc, aodev); diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 637b11d..3793d2c 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -2143,6 +2143,14 @@ int libxl__need_xenpv_qemu(libxl__gc *gc, libxl_domain_config *d_config) } } + for (i = 0; i < d_config->num_usbctrls; i++) { + if (d_config->usbctrls[i].type == LIBXL_USBCTRL_TYPE_QUSB && + d_config->usbctrls[i].backend_domid == domid) { + ret = 1; + goto out; + } + } + out: return ret; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index fc7bdab..2db8b1b 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -487,6 +487,7 @@ typedef struct { #define QEMU_BACKEND(dev) (\ (dev)->backend_kind == LIBXL__DEVICE_KIND_QDISK || \ (dev)->backend_kind == LIBXL__DEVICE_KIND_VFB || \ + (dev)->backend_kind == LIBXL__DEVICE_KIND_QUSB || \ (dev)->backend_kind == LIBXL__DEVICE_KIND_VKBD) #define XC_PCI_BDF "0x%x, 0x%x, 0x%x, 0x%x" diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c index 256add9..d9bac3c 100644 --- a/tools/libxl/libxl_pvusb.c +++ b/tools/libxl/libxl_pvusb.c @@ -22,6 +22,21 @@ #define USBHUB_CLASS_CODE 9 +static int usbback_is_loaded(libxl__gc *gc) +{ + int r; + struct stat st; + + r = lstat(SYSFS_USBBACK_DRIVER, &st); + + if (r == 0) + return 1; + if (r < 0 && errno == ENOENT) + return 0; + LOGE(ERROR, "Accessing %s", SYSFS_USBBACK_DRIVER); + return -1; +} + static int libxl__device_usbctrl_setdefault(libxl__gc *gc, uint32_t domid, libxl_device_usbctrl *usbctrl) { @@ -36,7 +51,8 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, uint32_t domid, if (usbctrl->type == LIBXL_USBCTRL_TYPE_AUTO) { if (domtype == LIBXL_DOMAIN_TYPE_PV) { - usbctrl->type = LIBXL_USBCTRL_TYPE_PV; + usbctrl->type = usbback_is_loaded(gc) ? LIBXL_USBCTRL_TYPE_PV + : LIBXL_USBCTRL_TYPE_QUSB; } else if (domtype == LIBXL_DOMAIN_TYPE_HVM) { /* FIXME: See if we can detect PV frontend */ usbctrl->type = LIBXL_USBCTRL_TYPE_DEVICEMODEL; @@ -54,7 +70,9 @@ int libxl__device_from_usbctrl(libxl__gc *gc, uint32_t domid, { device->backend_devid = usbctrl->devid; device->backend_domid = usbctrl->backend_domid; - device->backend_kind = LIBXL__DEVICE_KIND_VUSB; + device->backend_kind = (usbctrl->type == LIBXL_USBCTRL_TYPE_PV) + ? LIBXL__DEVICE_KIND_VUSB + : LIBXL__DEVICE_KIND_QUSB; device->devid = usbctrl->devid; device->domid = domid; device->kind = LIBXL__DEVICE_KIND_VUSB; @@ -64,9 +82,9 @@ int libxl__device_from_usbctrl(libxl__gc *gc, uint32_t domid, /* Add usbctrl information to xenstore. * - * Adding a usb controller will add a new 'vusb' device in xenstore, and - * add corresponding frontend, backend information to it. According to - * "update_json", decide wether to update json config file. + * Adding a usb controller will add a new 'qusb' or 'vusb' device in xenstore, + * and add corresponding frontend, backend information to it. According to + * "update_json", decide whether to update json config file. */ static int libxl__device_usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_device_usbctrl *usbctrl, @@ -159,6 +177,18 @@ out: return rc; } +static char *pvusb_get_device_type(libxl_usbctrl_type type) +{ + switch (type) { + case LIBXL_USBCTRL_TYPE_PV: + return "vusb"; + case LIBXL_USBCTRL_TYPE_QUSB: + return "qusb"; + default: + return NULL; + } +} + /* AO operation to add a usb controller. * * Generally, it does: @@ -190,7 +220,8 @@ void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid, } } - if (usbctrl->type != LIBXL_USBCTRL_TYPE_PV) { + if (usbctrl->type != LIBXL_USBCTRL_TYPE_PV && + usbctrl->type != LIBXL_USBCTRL_TYPE_QUSB) { LOG(ERROR, "Unsupported USB controller type"); rc = ERROR_FAIL; goto out; @@ -252,7 +283,8 @@ void libxl__initiate_device_usbctrl_remove(libxl__egc *egc, rc = libxl_device_usbctrl_getinfo(CTX, domid, &usbctrl, &usbctrlinfo); if (rc) goto out; - if (usbctrlinfo.type != LIBXL_USBCTRL_TYPE_PV) { + if (usbctrlinfo.type != LIBXL_USBCTRL_TYPE_PV && + usbctrlinfo.type != LIBXL_USBCTRL_TYPE_QUSB) { LOG(ERROR, "Unsupported USB controller type"); rc = ERROR_FAIL; goto out; @@ -293,6 +325,7 @@ static const char *vusb_be_from_xs_fe(libxl__gc *gc, const char *fe_path, const char *be_path; int r; uint32_t be_domid, fe_domid; + char be_type[16]; r = libxl__xs_read_checked(gc, XBT_NULL, GCSPRINTF("%s/backend", fe_path), &be_path); @@ -300,10 +333,10 @@ static const char *vusb_be_from_xs_fe(libxl__gc *gc, const char *fe_path, /* Check to see that it has the proper form, and that fe_domid == * target domid */ - r = sscanf(be_path, "/local/domain/%d/backend/vusb/%d", - &be_domid, &fe_domid); + r = sscanf(be_path, "/local/domain/%d/backend/%15[^/]/%d", + &be_domid, be_type, &fe_domid); - if (r != 2 || fe_domid != tgt_domid) { + if (r != 3 || fe_domid != tgt_domid) { LOG(ERROR, "Malformed backend, refusing to use"); return NULL; } @@ -740,8 +773,9 @@ libxl__device_usbdev_set_default_usbctrl(libxl__gc *gc, uint32_t domid, for (j = 0; j < usbctrls[i].ports; j++) { const char *path, *tmp; - path = GCSPRINTF("%s/backend/vusb/%d/%d/port/%d", + path = GCSPRINTF("%s/backend/%s/%d/%d/port/%d", libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID), + pvusb_get_device_type(usbctrls[i].type), domid, usbctrls[i].devid, j + 1); rc = libxl__xs_read_checked(gc, XBT_NULL, path, &tmp); if (rc) goto out; @@ -883,11 +917,12 @@ out: /* Add usb information to xenstore * - * Adding a usb device won't create new 'vusb' device, but only write + * Adding a usb device won't create new 'qusb'/'vusb' device, but only write * the device busid to the controller:port in xenstore. */ static int libxl__device_usbdev_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_device_usbdev *usbdev, + libxl_usbctrl_type type, bool update_json) { char *be_path, *busid; @@ -931,8 +966,9 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc *gc, uint32_t domid, if (rc) goto out; } - be_path = GCSPRINTF("%s/backend/vusb/%d/%d/port/%d", + be_path = GCSPRINTF("%s/backend/%s/%d/%d/port/%d", libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID), + pvusb_get_device_type(type), domid, usbdev->ctrl, usbdev->port); LOG(DEBUG, "Adding usb device %s to xenstore: controller %d, port %d", @@ -956,12 +992,14 @@ out: } static int libxl__device_usbdev_remove_xenstore(libxl__gc *gc, uint32_t domid, - libxl_device_usbdev *usbdev) + libxl_device_usbdev *usbdev, + libxl_usbctrl_type type) { char *be_path; - be_path = GCSPRINTF("%s/backend/vusb/%d/%d/port/%d", + be_path = GCSPRINTF("%s/backend/%s/%d/%d/port/%d", libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID), + pvusb_get_device_type(type), domid, usbdev->ctrl, usbdev->port); LOG(DEBUG, "Removing usb device from xenstore: controller %d, port %d", @@ -971,12 +1009,14 @@ static int libxl__device_usbdev_remove_xenstore(libxl__gc *gc, uint32_t domid, } static char *usbdev_busid_from_ctrlport(libxl__gc *gc, uint32_t domid, - libxl_device_usbdev *usbdev) + libxl_device_usbdev *usbdev, + libxl_usbctrl_type type) { return libxl__xs_read(gc, XBT_NULL, - GCSPRINTF("%s/backend/vusb/%d/%d/port/%d", + GCSPRINTF("%s/backend/%s/%d/%d/port/%d", libxl__xs_get_dompath(gc, LIBXL_TOOLSTACK_DOMID), - domid, usbdev->ctrl, usbdev->port)); + pvusb_get_device_type(type), + domid, usbdev->ctrl, usbdev->port)); } /* get original driver path of usb interface, stored in @drvpath */ @@ -1334,15 +1374,25 @@ static int do_usbdev_add(libxl__gc *gc, uint32_t domid, goto out; } - rc = libxl__device_usbdev_add_xenstore(gc, domid, usbdev, update_json); + rc = libxl__device_usbdev_add_xenstore(gc, domid, usbdev, + LIBXL_USBCTRL_TYPE_PV, + update_json); if (rc) goto out; rc = usbback_dev_assign(gc, busid); if (rc) { - libxl__device_usbdev_remove_xenstore(gc, domid, usbdev); + libxl__device_usbdev_remove_xenstore(gc, domid, usbdev, + LIBXL_USBCTRL_TYPE_PV); goto out; } break; + case LIBXL_USBCTRL_TYPE_QUSB: + rc = libxl__device_usbdev_add_xenstore(gc, domid, usbdev, + LIBXL_USBCTRL_TYPE_QUSB, + update_json); + if (rc) goto out; + + break; case LIBXL_USBCTRL_TYPE_DEVICEMODEL: default: LOG(ERROR, "Unsupported usb controller type"); @@ -1459,7 +1509,7 @@ static int do_usbdev_remove(libxl__gc *gc, uint32_t domid, switch (usbctrlinfo.type) { case LIBXL_USBCTRL_TYPE_PV: - busid = usbdev_busid_from_ctrlport(gc, domid, usbdev); + busid = usbdev_busid_from_ctrlport(gc, domid, usbdev, usbctrlinfo.type); if (!busid) { rc = ERROR_FAIL; goto out; @@ -1468,13 +1518,20 @@ static int do_usbdev_remove(libxl__gc *gc, uint32_t domid, rc = usbback_dev_unassign(gc, busid); if (rc) goto out; - rc = libxl__device_usbdev_remove_xenstore(gc, domid, usbdev); + rc = libxl__device_usbdev_remove_xenstore(gc, domid, usbdev, + LIBXL_USBCTRL_TYPE_PV); if (rc) goto out; rc = usbdev_rebind(gc, busid); if (rc) goto out; break; + case LIBXL_USBCTRL_TYPE_QUSB: + rc = libxl__device_usbdev_remove_xenstore(gc, domid, usbdev, + LIBXL_USBCTRL_TYPE_QUSB); + if (rc) goto out; + + break; case LIBXL_USBCTRL_TYPE_DEVICEMODEL: default: LOG(ERROR, "Unsupported usb controller type"); @@ -1559,7 +1616,6 @@ int libxl_ctrlport_to_device_usbdev(libxl_ctx *ctx, dompath = libxl__xs_get_dompath(gc, domid); fe_path = GCSPRINTF("%s/device/vusb/%d", dompath, ctrl); - be_path = vusb_be_from_xs_fe(gc, fe_path, domid); if (!be_path) { rc = ERROR_FAIL; diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index b0a9776..8934276 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -618,6 +618,7 @@ libxl_usbctrl_type = Enumeration("usbctrl_type", [ (0, "AUTO"), (1, "PV"), (2, "DEVICEMODEL"), + (3, "QUSB"), ]) libxl_usbdev_type = Enumeration("usbdev_type", [ diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl index 696f5f8..177f9b7 100644 --- a/tools/libxl/libxl_types_internal.idl +++ b/tools/libxl/libxl_types_internal.idl @@ -23,6 +23,7 @@ libxl__device_kind = Enumeration("device_kind", [ (7, "CONSOLE"), (8, "VTPM"), (9, "VUSB"), + (10, "QUSB"), ]) libxl__console_backend = Enumeration("console_backend", [
Add a new pvusb backend type "qusb" which is provided by qemu. It can be selected either by specifying the type directly in the configuration or it is selected automatically by libxl in case there is no "usbback" driver loaded. Signed-off-by: Juergen Gross <jgross@suse.com> --- docs/man/xl.cfg.pod.5 | 11 +++- tools/libxl/libxl_device.c | 3 +- tools/libxl/libxl_dm.c | 8 +++ tools/libxl/libxl_internal.h | 1 + tools/libxl/libxl_pvusb.c | 102 +++++++++++++++++++++++++++-------- tools/libxl/libxl_types.idl | 1 + tools/libxl/libxl_types_internal.idl | 1 + 7 files changed, 101 insertions(+), 26 deletions(-)