From: George Dunlap <george.dunlap@citrix.com>
To: Chunyan Liu <cyliu@suse.com>, xen-devel@lists.xen.org
Cc: jgross@suse.com, wei.liu2@citrix.com, ian.campbell@citrix.com,
george.dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com,
jfehlig@suse.com, Simon Cao <caobosimon@gmail.com>
Subject: Re: [PATCH V15 4/6] libxl: add pvusb API
Date: Wed, 2 Mar 2016 18:46:39 +0000 [thread overview]
Message-ID: <56D7350F.7010000@citrix.com> (raw)
In-Reply-To: <56D731B1.60009@citrix.com>
On 02/03/16 18:32, George Dunlap wrote:
> On 01/03/16 08:09, Chunyan Liu wrote:
>> Add pvusb APIs, including:
>> - attach/detach (create/destroy) virtual usb controller.
>> - attach/detach usb device
>> - list usb controller and usb devices
>> - some other helper functions
>>
>> Signed-off-by: Simon Cao <caobosimon@gmail.com>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> Signed-off-by: Chunyan Liu <cyliu@suse.com>
>> ---
>> Changes:
>> reorder usbdev_remove to following three steps:
>> 1. Unassign all interfaces from usbback, stopping and returning an
>> error as soon as one attempt fails
>> 2. Remove the pvusb xenstore nodes, stopping and returning an error
>> if it fails
>> 3. Attempt to re-assign all interfaces to the original drivers,
>> stopping and returning an error as soon as one attempt fails.
>
> Thanks, Chunyan! One minor comment about these changes...
>
>> +static int usbdev_rebind(libxl__gc *gc, const char *busid)
>> +{
>> + char **intfs = NULL;
>> + char *usbdev_encode = NULL;
>> + char *path = NULL;
>> + int i, num = 0;
>> + int rc;
>> +
>> + rc = usbdev_get_all_interfaces(gc, busid, &intfs, &num);
>> + if (rc) goto out;
>> +
>> + usbdev_encode = usb_interface_xenstore_encode(gc, busid);
>> +
>> + for (i = 0; i < num; i++) {
>> + char *intf = intfs[i];
>> + char *usbintf_encode = NULL;
>> + const char *drvpath;
>> +
>> + /* rebind USB interface to its originial driver */
>> + usbintf_encode = usb_interface_xenstore_encode(gc, intf);
>> + path = GCSPRINTF(USBBACK_INFO_PATH "/%s/%s/driver_path",
>> + usbdev_encode, usbintf_encode);
>> + rc = libxl__xs_read_checked(gc, XBT_NULL, path, &drvpath);
>> + if (rc) goto out;
>> +
>> + if (drvpath) {
>> + rc = bind_usbintf(gc, intf, drvpath);
>> + if (rc) {
>> + LOGE(ERROR, "Couldn't rebind %s to %s", intf, drvpath);
>> + goto out;
>> + }
>> + }
>> + }
>> +
>> + path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode);
>> + rc = libxl__xs_rm_checked(gc, XBT_NULL, path);
>> +
>> +out:
>
> So it looks like if one of the re-binds fails, then it stops where it is
> and leaves the USBBACK re-bind info in xenstore. In that case it's not
> clear to me how that information would ever be removed.
>
> I think until such time as we have a command to re-attempt the re-bind,
> if there's an error in the actual rebind, it should just break out of
> the for loop, and remove the re-bind nodes, and document a way to let
> the user try to clean things up.
>
>> +static int do_usbdev_remove(libxl__gc *gc, uint32_t domid,
>> + libxl_device_usbdev *usbdev)
>> +{
>> + int rc;
>> + char *busid;
>> + libxl_device_usbctrl usbctrl;
>> + libxl_usbctrlinfo usbctrlinfo;
>> +
>> + libxl_device_usbctrl_init(&usbctrl);
>> + libxl_usbctrlinfo_init(&usbctrlinfo);
>> + usbctrl.devid = usbdev->ctrl;
>> +
>> + rc = libxl_device_usbctrl_getinfo(CTX, domid, &usbctrl, &usbctrlinfo);
>> + if (rc) goto out;
>> +
>> + switch (usbctrlinfo.type) {
>> + case LIBXL_USBCTRL_TYPE_PV:
>> + busid = usbdev_busid_from_ctrlport(gc, domid, usbdev);
>> + if (!busid) {
>> + rc = ERROR_FAIL;
>> + goto out;
>> + }
>> +
>> + rc = usbback_dev_unassign(gc, busid);
>> + if (rc) goto out;
>> +
>> + rc = libxl__device_usbdev_remove_xenstore(gc, domid, usbdev);
>> + if (rc) goto out;
>> +
>> + rc = usbdev_rebind(gc, busid);
>> + if (rc) goto out;
>
> I think we need a comment here saying why we're doing things in this
> order. Maybe:
>
> "Things are done in this order to balance simplicity with robustness in
> the case of failure:
> * We unbind all interfaces before rebinding any interfaces, so that we
> never get into a situation where some interfaces are assigned to usbback
> and some are assigned to the original drivers.
> * We also unbind the interfaces before removing the pvusb xenstore
> nodes, so that if the unbind fails in the middle, the device still shows
> up in xl usb-list, and the user can re-try removing it."
Sorry, just looked through the rest of the series, and there's one more
thing.
Neither here nor in the man page do we explain what to do if something
goes wrong with the detach. I think the best thing to do is probably to
make the logged error messages more helpful.
What about something like this:
* On failure to unbind: "Error removing device from guest. Try running
usbdev-detach again."
* On failure to rebind: "USB device removed from guest, but couldn't
re-bind to domain 0. Try removing and re-inserting the USB device or
reloading the driver modules."
What do you think?
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-02 18:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 8:09 [PATCH V15 0/6] xen pvusb toolstack work Chunyan Liu
2016-03-01 8:09 ` [PATCH V15 1/6] libxl: export some functions for pvusb use Chunyan Liu
2016-03-01 8:09 ` [PATCH V15 2/6] libxl_utils: add internal function to read sysfs file contents Chunyan Liu
2016-03-01 8:09 ` [PATCH V15 3/6] refactor DEFINE_DEVICE_REMOVE to fit for more device types Chunyan Liu
2016-03-01 8:09 ` [PATCH V15 4/6] libxl: add pvusb API Chunyan Liu
2016-03-02 18:32 ` George Dunlap
2016-03-02 18:46 ` George Dunlap [this message]
2016-03-03 2:59 ` Chun Yan Liu
2016-03-03 9:27 ` George Dunlap
2016-03-04 3:12 ` Chun Yan Liu
2016-03-03 3:11 ` Chun Yan Liu
2016-03-03 9:20 ` George Dunlap
2016-03-04 3:04 ` Chun Yan Liu
2016-03-01 8:09 ` [PATCH V15 5/6] domcreate: support pvusb in configuration file Chunyan Liu
2016-03-01 8:09 ` [PATCH V15 6/6] xl: add pvusb commands Chunyan Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56D7350F.7010000@citrix.com \
--to=george.dunlap@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=caobosimon@gmail.com \
--cc=cyliu@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=jfehlig@suse.com \
--cc=jgross@suse.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).