Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

[Chun Yan Liu]

>>> On 5/9/2016 at 11:28 PM, in message
<6db04875-03d4-4542-b06c-2b0412d08...@gmail.com>, Lars Kurth
 wrote: 
> Hi all, 
>  
> I added the following sections based on git logs to man pages. Authors are  
> on the CC list and should review and modify (or suggest edits by replying to  
> this thread). I added/updated/added TODO's to: 
>  
> I do have some questions, to ... 
> - Konrad/Ross: is there any documentation for xSplice which I have missed? 
> - Julien: Any ARM specific stuff you want people to test? 
> - Doug: are there any docs / tests for KCONFIG you want to push 
> - George: are there any manual tests for credit 2 hard affinity, for hotplug  
> disk backends (drbd, iscsi, ) and soft reset for HVM guests that should be  
> added? 
>  
> For the following sections there are some TODO's - please verify and modify  
> and once OK, remove the TODO from the wiki pages. 
>  
> VCPU-PIN (Juergen Gross) 
> -  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#-f_option_for_xl 
> _vcpu-pin 
>  
> RTDS (Meng Xu, Chong Li) 
> - Meng, you mention improvements to the RTDS scheduler in another thread 
> - Are any specific test instructions needed in  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions 
> -  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RTDS_scheduler_i 
> mprovements 
>  
> COLO (Wen Congyang) 
> - http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping 
> -  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#COLO_-_Coarse_Gr 
> ain_Lock_Stepping 
>  
> USB (Chunyan Liu) 
> -  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#USB_Support_for_ 
> xl 
> - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB 
> - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB_in_xl.2Flibxl 

Updated!

- Chunyan

> CDP (He Chen) 
> -  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Intel_Code_and_D 
> ata_Prioritization_.28CDP.29 
> -  
> http://wiki.xenproject.org/wiki/Intel_Platform_QoS_Technologies#Code_and_Data 
> _Prioritization_.28CDP.29 
>  
> Are there any other big items that are missing? 
>  
> Regards 
> Lars 
>  
> > On 5 May 2016, at 18:08, Lars Kurth  wrote: 
> >  
> > Hi everyone, 
> >  
> > I updated http://wiki.xenproject.org/wiki/Xen_Project_Test_Days and created 
> >  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions (note that we  
> only have one page for all RC's now to avoid unnecessary copy and pasting). 
> >  
> > For those who want new features to be tested, please expect to  
> > a) Explain what to test (a very short description of the feature) 
> > b) Add some instructions on how to test (e.g. some command line  
> instructions) 
> >  
> > You can add a new headline (an example is marked with TODO) to either 
> > -  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_ARM_Tes 
> t_Instructions 
> > -  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_x86_Tes 
> t_Instructions 
> > - OR  
> http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RC_specific_thin 
> gs_to_test (under a specific RC heading) 
> >  
> > I will start promoting Test Days from early next week (on the blog, but  
> also on the mailing lists). The more specific test instructions for Xen 4.7  
> related features, the better the coverage will be and the more likely people  
> are to actually test. 
> >  
> > Best Regards 
> > Lars 
>  
>  
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] bind_usbintf: do not reuse 'path'

[Chun Yan Liu]

>>> On 4/8/2016 at 12:52 AM, in message
<22278.36941.470901.631...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Chunyan Liu writes ("[PATCH] bind_usbintf: do not reuse 'path'"): 
> > To avoid confusion, add a new variable "intf_path" to indicate 
> > driver/interface path, let "path" indicate driver/bind path only. 
>  
> I think it would be better to rename both variables, as I suggested in 
> my mail yesterday.  That makes it much more obvious that each place 
> where `path' was used has been checked and the reference to the 
> proper variable substituted. 

Updated. Sent V2.

>  
> Thanks, 
> Ian. 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] libxl: Set rc on failure of usbdev_busaddr_to_busid

[Chun Yan Liu]

>>> On 4/8/2016 at 01:04 AM, in message
<22278.37677.975595.101...@mariner.uk.xensource.com>, Ian Jackson
<ian.jack...@eu.citrix.com> wrote: 
> Chun Yan Liu writes ("Re: [PATCH 1/2] libxl: Set rc on failure of  
> usbdev_busaddr_to_busid"): 
> > Thanks, Ian! 
>  
> Should I take that as a Reviewed-by ? 

Ah, yes. Acked. :-)

Chunyan

>  
> Thanks, 
> Ian. 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/4] a fix in libxl_device_usbdev_list

[Chun Yan Liu]

>>> On 4/8/2016 at 12:45 AM, in message
<22278.36492.245114.295...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Chunyan Liu writes ("[PATCH 1/4] a fix in libxl_device_usbdev_list"): 
> > In testing with libvirt pvusb functionality, found a rc check 
> > error in libxl_device_usbdev_list. Correct it. 
>  
> Thanks.  But now that I look at this code I'm not sure your fix is 
> complete. 
>  
> > diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c 
> > index 5f92628..04e41b4 100644 
> > --- a/tools/libxl/libxl_pvusb.c 
> > +++ b/tools/libxl/libxl_pvusb.c 
> > @@ -701,13 +701,13 @@ libxl_device_usbdev_list(libxl_ctx *ctx, uint32_t  
> domid, int *num) 
> >  usbctrls = libxl__xs_directory(gc, XBT_NULL, path, ); 
> >   
> >  for (i = 0; i < nc; i++) { 
> > -int r, nd = 0; 
> > +int rc, nd = 0; 
> >  libxl_device_usbdev *tmp = NULL; 
> >   
> > -r = libxl__device_usbdev_list_for_usbctrl(gc, domid, 
> > +rc = libxl__device_usbdev_list_for_usbctrl(gc, domid, 
> >atoi(usbctrls[i]), 
> >, ); 
> > -if (!r || !nd) continue; 
> > +if (rc || !nd) continue; 
>  
> If libxl__device_usbdev_list_for_usbctrl fails, shouldn't 
> libxl_device_usbdev_list fail too ? 

Following the similar definitions of other device types, the return value of
this function is "libxl_device_usbdev *", to treat the above case as failure,
it cannot be reflected through return value, we can only set return value
to NULL, but that will be confusing with a real no-device case.

- Chunyan
>  
> Ian. 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Redundant lstats in libxl_pvusb.c

[Chun Yan Liu]

>>> On 4/7/2016 at 06:43 PM, in message
<22278.14817.248393.423...@mariner.uk.xensource.com>, Ian Jackson
<ian.jack...@eu.citrix.com> wrote: 
> Chun Yan Liu writes ("Re: Redundant lstats in libxl_pvusb.c"): 
> > <22274.33583.712655.413...@mariner.uk.xensource.com>, Ian Jackson 
> > <ian.jack...@eu.citrix.com> wrote:  
> > > In libxl_usb.c, usbintf_get_drvpath calls stat(2) on the driver sysfs  
> > > path, and then realpath on the same path.  
> >  
> > It's true. This could be done by calling realpath only. Will correct. 
>  
> Thanks. 
>  
> > > And bind_usbintf calls stat(2) on the driver directory path, and then  
> > > open(2) on a file in that directory.  
> >  
> > It's not true. It calls stat(2) on a file in driver path  
> (driver/interface), 
> > and open(2) on another file in that driver path (driver/bind). 
>  
> I have read the function again and you are right. 
>  
> Coverity said: 
>  
> > > > >>> CID 1358111: Security best practices violations (TOCTOU) 
> > > > >>> Calling function "open" that uses "path" after a check 
> > > > >>> function. This can cause a time-of-check, time-of-use 
> > > > >>> race condition. 
>  
> But it seems that it is confused by the reuse of the path variable. 
> I think this is arguably a bug in Coverity. 
>  
> But, evidently, the same reuse confused me too.  Maybe we should turn 
> `path' into two variables, `intf_path' and `bind_path' ?  What do you 
> think ? 

Yeah, maybe it's better to change into 'intf_path' and 'bind_path', I'll update.
But it's unavoidable that some temp variable will be reused for many
times.

Chunyan

>  
> Thanks, 
> Ian. 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Redundant lstats in libxl_pvusb.c

[Chun Yan Liu]

>>> On 4/4/2016 at 11:07 PM, in message
<22274.33583.712655.413...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> In libxl_usb.c, usbintf_get_drvpath calls stat(2) on the driver sysfs 
> path, and then realpath on the same path. 

It's true. This could be done by calling realpath only. Will correct.

>  
> And bind_usbintf calls stat(2) on the driver directory path, and then 
> open(2) on a file in that directory. 

It's not true. It calls stat(2) on a file in driver path (driver/interface),
and open(2) on another file in that driver path (driver/bind).

Chunyan
>  
> It seems to be that in both cases, libxl could simply directly access 
> the target object.  Ie, it could always call realpath, and always call 
> open.  Appropriate error handling would deal with the cases currently 
> dealt with by the stat. 
>  
> Am I wrong about this ? 
>  
> I'm prompted to look at this by Coverity, Coverity thinks that this 
> stat-then-realpath, or stat-then-open, might be a TOCTOU security 
> problem.  I think it's wrong, but it would be nice to tidy up the code 
> and eliminate these complaints. 
>  
> If I am right, I'd appreciate patch(es).  They should mention 
> CID: 1358112 
> CID: 1358111 
> for these two functions, respectively. 
>  
> Thanks, 
> Ian. 
>  
> > *** CID 1358112:  Security best practices violations  (TOCTOU) 
> > /tools/libxl/libxl_pvusb.c: 995 in usbintf_get_drvpath() 
> > 989 spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf); 
> > 990  
> > 991 r = lstat(spath, ); 
> > 992 if (r == 0) { 
> > 993 /* Find the canonical path to the driver. */ 
> > 994 dp = libxl__zalloc(gc, PATH_MAX); 
> > >>> CID 1358112:  Security best practices violations  (TOCTOU) 
> > >>> Calling function "realpath" that uses "spath" after a check 
> > >>> function.  
> This can cause a time-of-check, time-of-use race condition. 
> > 995 dp = realpath(spath, dp); 
> > 996 if (!dp) { 
> > 997 LOGE(ERROR, "get realpath failed: '%s'", spath); 
> > 998 return ERROR_FAIL; 
> > 999 } 
> > 1000 } else if (errno == ENOENT) { 
>  
> > *** CID 1358111:  Security best practices violations  (TOCTOU) 
> > /tools/libxl/libxl_pvusb.c: 1061 in bind_usbintf() 
> > 1055 return 0; 
> > 1056 if (r < 0 && errno != ENOENT) 
> > 1057 return ERROR_FAIL; 
> > 1058  
> > 1059 path = GCSPRINTF("%s/bind", drvpath); 
> > 1060  
> > >>> CID 1358111:  Security best practices violations  (TOCTOU) 
> > >>> Calling function "open" that uses "path" after a check function. 
> > >>> This  
> can cause a time-of-check, time-of-use race condition. 
> > 1061 fd = open(path, O_WRONLY); 
> > 1062 if (fd < 0) { 
> > 1063 LOGE(ERROR, "open file failed: '%s'", path); 
> > 1064 rc = ERROR_FAIL; 
> > 1065 goto out; 
> > 1066 } 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] libxl: Set rc on failure of usbdev_busaddr_to_busid

[Chun Yan Liu]

Thanks, Ian!

>>> On 4/4/2016 at 11:09 PM, in message
<1459782600-16073-1-git-send-email-ian.jack...@eu.citrix.com>, Ian Jackson
 wrote: 
> We must set rc before using `goto out'. 
>  
> Bug introduced in bf7628f0 "libxl: add pvusb API". 
>  
> CID: 1358113 
> Signed-off-by: Ian Jackson  
> CC: cover...@xenproject.org 
> CC: Simon Cao  
> CC: George Dunlap  
> CC: Chunyan Liu  
> --- 
>  tools/libxl/libxl_pvusb.c |1 + 
>  1 file changed, 1 insertion(+) 
>  
> diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c 
> index 5f92628..6f53317 100644 
> --- a/tools/libxl/libxl_pvusb.c 
> +++ b/tools/libxl/libxl_pvusb.c 
> @@ -905,6 +905,7 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc  
> *gc, uint32_t domid, 
>  usbdev->u.hostdev.hostaddr); 
>  if (!busid) { 
>  LOG(DEBUG, "Fail to get busid of usb device"); 
> +rc = ERROR_FAIL; 
>  goto out; 
>  } 
>   
 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] libxl: Do not leak data on error path from libxl__read_sysfs_file_contents

[Chun Yan Liu]

>>> On 4/4/2016 at 11:10 PM, in message
<1459782600-16073-2-git-send-email-ian.jack...@eu.citrix.com>, Ian Jackson
 wrote: 
> Bug introduced in bc023ecd 
> "libxl_utils: add internal function to read sysfs file contents" 
>  
> CID: 1358108 
> Signed-off-by: Ian Jackson  
> CC: cover...@xenproject.org 
> CC: Chunyan Liu  
> --- 
>  tools/libxl/libxl_utils.c |1 + 
>  1 file changed, 1 insertion(+) 
>  
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c 
> index ceb8825..bd58a52 100644 
> --- a/tools/libxl/libxl_utils.c 
> +++ b/tools/libxl/libxl_utils.c 
> @@ -466,6 +466,7 @@ int libxl__read_sysfs_file_contents(libxl__gc *gc, const  
> char *filename, 
>  e = errno; 
>  assert(e != ENOENT); 
>  if (f) fclose(f); 
> +free(data); 

'data' is malloced with 'gc', it'll be freed by GC_FREE. Do we need to free
it here?

Chunyan

>  return e; 
>  } 
>   
 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/5] libxl: add new pvusb backend "qusb" provided by qemu

[Chun Yan Liu]

>>> On 3/25/2016 at 02:29 PM, in message <56f4dade.4040...@suse.com>, Juergen 
>>> Gross
<jgr...@suse.com> wrote: 
> On 25/03/16 03:23, Chun Yan Liu wrote: 
> >  
> >  
> >>>> On 3/23/2016 at 08:24 PM, in message 
> > <1458735847-9448-3-git-send-email-jgr...@suse.com>, Juergen Gross 
> > <jgr...@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 <jgr...@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(-)  
> >>   
> >> 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  
> >> @@ -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, );  
> >> +  
> >> +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 
> >>  
> > The condition should be (usbback_is_loaded(gc) > 0)? 
> > usbback_is_loaded(gc) < 0 means lstat error, cannot determine if the 
> > usbback driver is loaded. 
>  
> Good point. I think in error case I should rather abort the operation. 
>  
> Thoughts? 

I think it's OK. In another case when we check if a USB device is assigned
or not, we call get_assigned_devices(), it that function fails, we cannot
determine if a USB device is assigned or not, the handling is just abort.
So I think here if cannot determine usbback is loaded or not, we can
also abort and report error directly.

Chunyan


>  
>  
> Juergen 
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 4/5] libxl: check for dynamic device model start required

[Chun Yan Liu]

>>> On 3/25/2016 at 02:25 PM, in message <56f4d9d6.8030...@suse.com>, Juergen 
>>> Gross
<jgr...@suse.com> wrote: 
> On 25/03/16 03:06, Chun Yan Liu wrote: 
> >  
> >  
> >>>> On 3/23/2016 at 08:24 PM, in message 
> > <1458735847-9448-5-git-send-email-jgr...@suse.com>, Juergen Gross 
> > <jgr...@suse.com> wrote:  
> >> Add a service routine checking whether a device model must be started  
> >> after adding a device to a domain.  
> >>   
> >> Signed-off-by: Juergen Gross <jgr...@suse.com>  
> >> ---  
> >>  tools/libxl/libxl.c  | 12   
> >>  tools/libxl/libxl_dm.c   | 14 ++  
> >>  tools/libxl/libxl_internal.h |  4   
> >>  tools/libxl/libxl_pci.c  |  3 +++  
> >>  tools/libxl/libxl_pvusb.c|  6 ++  
> >>  5 files changed, 39 insertions(+)  
> >>   
> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c  
> >> index dcd0951..2b4e36f 100644  
> >> --- a/tools/libxl/libxl.c  
> >> +++ b/tools/libxl/libxl.c  
> >> @@ -2084,6 +2084,9 @@ void libxl__device_vtpm_add(libxl__egc *egc, 
> >> uint32_t  
>   
> >> domid,  
> >>  if (rc) goto out;  
> >>
> >>  DEVICE_ADD(vtpm, vtpms, domid, _saved, COMPARE_DEVID,   
> >> _config);  
> >> +  
> >> +rc = libxl__dm_check_start(gc, _config, domid);  
> >> +if (rc) goto out;  
> >>  } 
> >  
> > Why is this check put inside the if (aodev->update_json) {  }? I think it's 
> >  
> a common 
> > check, so should move outside. 
>  
> It is the only case where the check makes sense: update_json isn't set 
> when we are just creating the domain, in which case the test for the 
> device model needed is already in place.

See. That's OK then.

Thanks,
Chunyan
 
> When the device is added to an 
> already running domain update_json will always be true. 
>  
>  
> Juergen 
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/5] libxl: add new pvusb backend "qusb" provided by qemu

[Chun Yan Liu]

>>> On 3/23/2016 at 08:24 PM, in message
<1458735847-9448-3-git-send-email-jgr...@suse.com>, Juergen Gross
 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  
> --- 
>  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 ec739cc..a4cc1b3 100644 
> --- a/docs/man/xl.cfg.pod.5 
> +++ b/docs/man/xl.cfg.pod.5 
> @@ -737,8 +737,15 @@ Possible Bs are: 
>   
>  =item 

Re: [Xen-devel] [PATCH v3 4/5] libxl: check for dynamic device model start required

[Chun Yan Liu]

>>> On 3/23/2016 at 08:24 PM, in message
<1458735847-9448-5-git-send-email-jgr...@suse.com>, Juergen Gross
 wrote: 
> Add a service routine checking whether a device model must be started 
> after adding a device to a domain. 
>  
> Signed-off-by: Juergen Gross  
> --- 
>  tools/libxl/libxl.c  | 12  
>  tools/libxl/libxl_dm.c   | 14 ++ 
>  tools/libxl/libxl_internal.h |  4  
>  tools/libxl/libxl_pci.c  |  3 +++ 
>  tools/libxl/libxl_pvusb.c|  6 ++ 
>  5 files changed, 39 insertions(+) 
>  
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> index dcd0951..2b4e36f 100644 
> --- a/tools/libxl/libxl.c 
> +++ b/tools/libxl/libxl.c 
> @@ -2084,6 +2084,9 @@ void libxl__device_vtpm_add(libxl__egc *egc, uint32_t  
> domid, 
>  if (rc) goto out; 
>   
>  DEVICE_ADD(vtpm, vtpms, domid, _saved, COMPARE_DEVID,  
> _config); 
> + 
> +rc = libxl__dm_check_start(gc, _config, domid); 
> +if (rc) goto out; 
>  }

Why is this check put inside the if (aodev->update_json) {  }? I think it's a 
common
check, so should move outside.

- Chunyan 
 
>   
>  for (;;) { 
> @@ -2388,6 +2391,9 @@ static void device_disk_add(libxl__egc *egc, uint32_t  
> domid, 
>  if (rc) goto out; 
>   
>  DEVICE_ADD(disk, disks, domid, _saved, COMPARE_DISK, 
> _config); 
> + 
> +rc = libxl__dm_check_start(gc, _config, domid); 
> +if (rc) goto out; 
>  } 
>   
>  for (;;) { 
> @@ -2928,6 +2934,9 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid,  
> libxl_device_disk *disk, 
>   
>  DEVICE_ADD(disk, disks, domid, _saved, COMPARE_DISK, _config); 
>   
> +rc = libxl__dm_check_start(gc, _config, domid); 
> +if (rc) goto out; 
> + 
>  if (dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { 
>  rc = libxl__qmp_insert_cdrom(gc, domid, disk); 
>  if (rc) goto out; 
> @@ -3354,6 +3363,9 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t  
> domid, 
>  if (rc) goto out; 
>   
>  DEVICE_ADD(nic, nics, domid, _saved, COMPARE_DEVID, _config); 
> + 
> +rc = libxl__dm_check_start(gc, _config, domid); 
> +if (rc) goto out; 
>  } 
>   
>  for (;;) { 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c 
> index bffb8f8..78c46674 100644 
> --- a/tools/libxl/libxl_dm.c 
> +++ b/tools/libxl/libxl_dm.c 
> @@ -2160,6 +2160,20 @@ int libxl__dm_active(libxl__gc *gc, uint32_t domid) 
>  return pid != NULL; 
>  } 
>   
> +int libxl__dm_check_start(libxl__gc *gc, libxl_domain_config *d_config, 
> +  uint32_t domid) 
> +{ 
> +if (libxl__dm_active(gc, domid)) 
> +return 0; 
> + 
> +if (!libxl__need_xenpv_qemu(gc, d_config)) 
> +return 0; 
> + 
> +LOG(ERROR, "device model required but not running"); 
> + 
> +return ERROR_FAIL; 
> +} 
> + 
>  /* 
>   * Local variables: 
>   * mode: C 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h 
> index 2db8b1b..9708a46 100644 
> --- a/tools/libxl/libxl_internal.h 
> +++ b/tools/libxl/libxl_internal.h 
> @@ -1618,6 +1618,10 @@ _hidden const char  
> *libxl__domain_device_model(libxl__gc *gc, 
>  const libxl_domain_build_info  
> *info); 
>  _hidden int libxl__need_xenpv_qemu(libxl__gc *gc, 
> libxl_domain_config *d_config); 
> +_hidden int libxl__dm_active(libxl__gc *gc, uint32_t domid); 
> +_hidden int libxl__dm_check_start(libxl__gc *gc, 
> +  libxl_domain_config *d_config, 
> +  uint32_t domid); 
>   
>  /* 
>   * This function will fix reserved device memory conflict 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c 
> index dc10cb7..300fd4d 100644 
> --- a/tools/libxl/libxl_pci.c 
> +++ b/tools/libxl/libxl_pci.c 
> @@ -169,6 +169,9 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc,  
> uint32_t domid, libxl_d 
>   
>  DEVICE_ADD(pci, pcidevs, domid, _saved, COMPARE_PCI, _config); 
>   
> +rc = libxl__dm_check_start(gc, _config, domid); 
> +if (rc) goto out; 
> + 
>  for (;;) { 
>  rc = libxl__xs_transaction_start(gc, ); 
>  if (rc) goto out; 
> diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c 
> index 7200ead..976e4c7 100644 
> --- a/tools/libxl/libxl_pvusb.c 
> +++ b/tools/libxl/libxl_pvusb.c 
> @@ -139,6 +139,9 @@ static int libxl__device_usbctrl_add_xenstore(libxl__gc  
> *gc, uint32_t domid, 
>   
>  DEVICE_ADD(usbctrl, usbctrls, domid, _saved, 
> COMPARE_USBCTRL, _config); 
> + 
> +rc = libxl__dm_check_start(gc, _config, domid); 
> +if (rc) goto out; 
>  } 
>   
>  for (;;) { 
> @@ -955,6 +958,9 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc  
> *gc, uint32_t domid, 
>   
>  DEVICE_ADD(usbdev, usbdevs, 

[Xen-devel] issue: xen pv guest text mode key press by TigerVNC

[Chun Yan Liu]

Hi, List,

Currently after switch from TightVNC to TigerVNC, found a key-press issue
in XEN pv guest, after investigation by myself, didn't find root cause yet,
could anyone help to have a look or have some idea?

Following is a description of the issue and some investigation result:

In Xen pv guest text mode, when press a key for long time, it's expected to
show the key repeately, but actual result is it only shows one. (e.g, press
 'p' for long time, should show 'p', but actually it just show 'p').
When using TightVNC, it has no problem.
After investigation:
1. TightVNC send "keydown, keyup, keydown, keyup" in this case,
has no problem in result.
2. TigerVNC send "keydown, keydown, keydown, keyup" in this case,
will have problem.
3. In Xen HVM guest text mode, also with TigerVNC, but has no problem.
4. In debugging, I set breakpoint at qemu ps2.c ps2_put_keycode for
comparison with pv guest code path (qemu hw/display/xenfb.c:
xenfb_kbd_event), however, after set breakpoint, on HVM guest,
it also has problem, only shown one 'p'.

I checked kernel code drivers/xen/fbfront/xenkbd.c and traced down,
but couldn't see where is the problem.

Any ideas?

Thanks,
Chunyan 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RESEND][PATCH V16 0/6] xen pvusb toolstack work

[Chun Yan Liu]

>>> On 3/8/2016 at 07:33 PM, in message <56deb899.7080...@citrix.com>, George
Dunlap  wrote: 
> On 08/03/16 01:37, Chunyan Liu wrote: 
> > This patch series is to add pvusb toolstack work, supporting hot add|remove 
> > USB device to|from guest and specify USB device in domain configuration  
> file. 
> >  
> > RESEND to remove a incorrect rc in 4/6: 
> > +out: 
> > +path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode); 
> > +rc = libxl__xs_rm_checked(gc, XBT_NULL, path); 
> > 'rc' should be removed here. 
> > +return rc; 
> >  
> > Sorry for trouble you. 
>  
> Hey Chunyan, 
>  
> If you make any change at all to the patch series, you should increase 
> the revision number.  Otherwise, the person who ultimately commits it is 
> likely to think that the original version and the resend are the same, 
> and accidentally commit the original (incorrect) version.  (For 
> instance, they may already like me have downloaded the original patch 
> series and imported it into git.) 
>  
> The best thing to do in this situation would have been to reply to your 
> own patch, saying "And this 'rc' should be removed.  I'll spin another 
> version." 
>  
> I took a brief look at the diff between v14 and v15v1 yesterday, and it 
> looks good.  IanJ is away this week, and I'm sure he'll want to take a 
> look at it before Ack-ing it next week.  So would you mind sending a 
> v16, and I'll review it by the end of the week? 

Got it. Will post the RESEND series with a new version number.

>  
> Thanks, 
>  -George 
>  
> >  
> > Changes to V15: 
> > * address George's comments (patch 4/6) 
> >  
> > V15: 
> > http://lists.xen.org/archives/html/xen-devel/2016-03/msg00040.html 
> >  
> > V14: 
> > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02745.html 
> >  
> > V13: 
> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02125.html 
> >  
> > V12: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html 
> >  
> > V11: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html 
> >  
> > V10: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html 
> >  
> > V9: 
> > http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html 
> >  
> > V8: 
> > http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html 
> >  
> > V7: 
> > http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html 
> >  
> > V6: 
> > http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html 
> >  
> > V5: 
> > http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html 
> >  
> > V4: 
> > http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html 
> >  
> > Related Discussion Threads: 
> > http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html 
> > http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html 
> >  
> >   <<< pvusb work introduction >>> 
> >  
> > 1. Overview 
> >  
> > There are two general methods for passing through individual host 
> > devices to a guest. The first is via an emulated USB device 
> > controller; the second is PVUSB. 
> >  
> > Additionally, there are two ways to add USB devices to a guest: via 
> > the config file at domain creation time, and via hot-plug while the VM 
> > is running. 
> >  
> > * Emulated USB 
> >  
> > In emulated USB, the device model (qemu) presents an emulated USB 
> > controller to the guest. The device model process then grabs control 
> > of the device from domain 0 and and passes the USB commands between 
> > the guest OS and the host USB device. 
> >  
> > This method is only available to HVM domains, and is not available for 
> > domains running with device model stubdomains. 
> >  
> > * PVUSB 
> >  
> > PVUSB uses a paravirtialized front-end/back-end interface, similar to 
> > the traditional Xen PV network and disk protocols. In order to use 
> > PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
> > your USB driver domain). 
> >  
> > 2. Specifying a host USB device 
> >  
> > QEMU qmp commands allows USB devices to be specified either by their 
> > bus address (in the form bus.device) or their device tag (in the form 
> > vendorid:deviceid). 
> >  
> > Each way of specifying has its advantages: 
> >  
> > Specifying by device tag will always get the same device, 
> > regardless of where the device ends up in the USB bus topology. 
> > However, if there are two identical devices, it will not allow you to 
> > specify which one. 
> >  
> > Specifying by bus address will always allow you to choose a 
> > specific device, even if you have duplicates. However, the bus address 
> > may change depending on which port you plugged the device into, and 
> > possibly also after a reboot. 
> >  
> > To avoid duplication of vendorid:deviceid, we'll use bus address to 
> > specify host USB device in xl toolstack. 
> >  
> > You can use lsusb to list the USB devices on the system: 

Re: [Xen-devel] [PATCH V16 4/6] libxl: add pvusb API

[Chun Yan Liu]

Sorry, corrected a wrong rc. Resent it, please refer to:
http://lists.xen.org/archives/html/xen-devel/2016-03/msg00908.html

>>> On 3/4/2016 at 12:55 PM, in message
<1457067356-3306-5-git-send-email-cy...@suse.com>, 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  
> Signed-off-by: George Dunlap  
> Signed-off-by: Chunyan Liu  
> --- 
> Changes: 
>   * Address George's comments 
>  
>  tools/libxl/Makefile |3 +- 
>  tools/libxl/libxl.c  |   18 + 
>  tools/libxl/libxl.h  |   77 ++ 
>  tools/libxl/libxl_device.c   |5 +- 
>  tools/libxl/libxl_internal.h |   18 + 
>  tools/libxl/libxl_osdeps.h   |   13 + 
>  tools/libxl/libxl_pvusb.c| 1620  
> ++ 
>  tools/libxl/libxl_types.idl  |   46 + 
>  tools/libxl/libxl_types_internal.idl |1 + 
>  tools/libxl/libxl_utils.c|   18 + 
>  tools/libxl/libxl_utils.h|5 + 
>  11 files changed, 1822 insertions(+), 2 deletions(-) 
>  create mode 100644 tools/libxl/libxl_pvusb.c 
>  
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile 
> index 789a12e..8fa7b87 100644 
> --- a/tools/libxl/Makefile 
> +++ b/tools/libxl/Makefile 
> @@ -105,7 +105,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o  
> libxl_dm.o libxl_pci.o \ 
>   libxl_stream_read.o libxl_stream_write.o \ 
>   libxl_save_callout.o _libxl_save_msgs_callout.o \ 
>   libxl_qmp.o libxl_event.o libxl_fork.o \ 
> - libxl_dom_suspend.o libxl_dom_save.o $(LIBXL_OBJS-y) 
> + libxl_dom_suspend.o libxl_dom_save.o libxl_pvusb.o \ 
> +$(LIBXL_OBJS-y) 
>  LIBXL_OBJS += libxl_genid.o 
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o 
>   
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> index 2ab5ad3..1e68688 100644 
> --- a/tools/libxl/libxl.c 
> +++ b/tools/libxl/libxl.c 
> @@ -4102,6 +4102,8 @@ out: 
>   * libxl_device_vkb_destroy 
>   * libxl_device_vfb_remove 
>   * libxl_device_vfb_destroy 
> + * libxl_device_usbctrl_remove 
> + * libxl_device_usbctrl_destroy 
>   */ 
>  #define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\ 
>  int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
> @@ -4159,6 +4161,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1) 
>  DEFINE_DEVICE_REMOVE(vtpm, remove, 0) 
>  DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
>   
> +/* usbctrl */ 
> +DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0) 
> +DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1) 
> + 
>  /* channel/console hotunplug is not implemented. There are 2 possibilities: 
>   * 1. add support for secondary consoles to xenconsoled 
>   * 2. dynamically add/remove qemu chardevs via qmp messages. */ 
> @@ -4174,6 +4180,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
>   * libxl_device_disk_add 
>   * libxl_device_nic_add 
>   * libxl_device_vtpm_add 
> + * libxl_device_usbctrl_add 
> + * libxl_device_usbdev_add 
>   */ 
>   
>  #define DEFINE_DEVICE_ADD(type) \ 
> @@ -4205,6 +4213,12 @@ DEFINE_DEVICE_ADD(nic) 
>  /* vtpm */ 
>  DEFINE_DEVICE_ADD(vtpm) 
>   
> +/* usbctrl */ 
> +DEFINE_DEVICE_ADD(usbctrl) 
> + 
> +/* usb */ 
> +DEFINE_DEVICE_ADD(usbdev) 
> + 
>  #undef DEFINE_DEVICE_ADD 
>   
>   
> / 
> **/ 
> @@ -6750,6 +6764,10 @@ int libxl_retrieve_domain_configuration(libxl_ctx  
> *ctx, uint32_t domid, 
>   
>  MERGE(pci, pcidevs, COMPARE_PCI, {}); 
>   
> +MERGE(usbctrl, usbctrls, COMPARE_USBCTRL, {}); 
> + 
> +MERGE(usbdev, usbdevs, COMPARE_USB, {}); 
> + 
>  /* Take care of removable device. We maintain invariant in the 
>   * insert / remove operation so that: 
>   * 1. if xenstore is "empty" while JSON is not, the result 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> index 0859383..5cc3ce3 100644 
> --- a/tools/libxl/libxl.h 
> +++ b/tools/libxl/libxl.h 
> @@ -123,6 +123,12 @@ 
>  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1 
>   
>  /* 
> + * LIBXL_HAVE_PVUSB indicates functions for plugging in USB devices 
> + * through pvusb -- both hotplug and at domain creation time.. 
> + */ 
> +#define LIBXL_HAVE_PVUSB 1 
> + 
> +/* 
>   * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the 
>   * libxl_vendor_device field is present in the hvm sections of 
>   * libxl_domain_build_info. This field tells libxl which 
> @@ -1536,6 +1542,77 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t  
> domid, libxl_device_disk *disk, 
> const libxl_asyncop_how 

Re: [Xen-devel] [PATCH V16 0/6] xen pvusb toolstack work

[Chun Yan Liu]

Sorry, just corrected a rc in 4/6, and resent patch series, please refer to:
http://lists.xen.org/archives/html/xen-devel/2016-03/msg00904.html

>>> On 3/4/2016 at 12:55 PM, in message
<1457067356-3306-1-git-send-email-cy...@suse.com>, Chunyan Liu 
wrote: 
> This patch series is to add pvusb toolstack work, supporting hot add|remove 
> USB device to|from guest and specify USB device in domain configuration  
> file. 
>  
> Changes to V15: 
> * address George's comments (patch 4/6) 
>  
> V15: 
> http://lists.xen.org/archives/html/xen-devel/2016-03/msg00040.html 
>  
> V14: 
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02745.html 
>  
> V13: 
> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02125.html 
>  
> V12: 
> http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html 
>  
> V11: 
> http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html 
>  
> V10: 
> http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html 
>  
> V9: 
> http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html 
>  
> V8: 
> http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html 
>  
> V7: 
> http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html 
>  
> V6: 
> http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html 
>  
> V5: 
> http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html 
>  
> V4: 
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html 
>  
> Related Discussion Threads: 
> http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html 
> http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html 
>  
>   <<< pvusb work introduction >>> 
>  
> 1. Overview 
>  
> There are two general methods for passing through individual host 
> devices to a guest. The first is via an emulated USB device 
> controller; the second is PVUSB. 
>  
> Additionally, there are two ways to add USB devices to a guest: via 
> the config file at domain creation time, and via hot-plug while the VM 
> is running. 
>  
> * Emulated USB 
>  
> In emulated USB, the device model (qemu) presents an emulated USB 
> controller to the guest. The device model process then grabs control 
> of the device from domain 0 and and passes the USB commands between 
> the guest OS and the host USB device. 
>  
> This method is only available to HVM domains, and is not available for 
> domains running with device model stubdomains. 
>  
> * PVUSB 
>  
> PVUSB uses a paravirtialized front-end/back-end interface, similar to 
> the traditional Xen PV network and disk protocols. In order to use 
> PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
> your USB driver domain). 
>  
> 2. Specifying a host USB device 
>  
> QEMU qmp commands allows USB devices to be specified either by their 
> bus address (in the form bus.device) or their device tag (in the form 
> vendorid:deviceid). 
>  
> Each way of specifying has its advantages: 
>  
> Specifying by device tag will always get the same device, 
> regardless of where the device ends up in the USB bus topology. 
> However, if there are two identical devices, it will not allow you to 
> specify which one. 
>  
> Specifying by bus address will always allow you to choose a 
> specific device, even if you have duplicates. However, the bus address 
> may change depending on which port you plugged the device into, and 
> possibly also after a reboot. 
>  
> To avoid duplication of vendorid:deviceid, we'll use bus address to 
> specify host USB device in xl toolstack. 
>  
> You can use lsusb to list the USB devices on the system: 
>  
> Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 003 Device 002: ID f617:0905 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
> Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra 
> Fast Media Reader 
> Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse 
>  
> To pass through the Logitec mouse, for instance, you could specify 
> 1.6 (remove leading zeroes). 
>  
> Note: USB hubs can not be assigned to guest. 
>  
> 3. PVUSB toolstack 
>  
> * Specify USB device in xl config file 
>  
> You can just specify usb devices, like: 
> usbdev=['hostbus=1, hostaddr=6'] 
>  
> Then it will create a USB controller automatically and attach the USB 
> device to the first available USB controller:port. 
>  
> or, you can explicitly specify usb controllers and usb devices, like: 
> usbctrl=['verison=1, ports=4', 'version=2, ports=8', ] 
> usbdev=['hostbus=1, hostaddr=6, controller=0, port=1'] 
>  
> Then it will create two USB controllers as you specified. 
> And if controller and port are specified in usb config, then it will 
> attach the USB device to that controller:port. About the controller 
> and port value: 
> Each USB controller has a 

Re: [Xen-devel] [PATCH V15 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 3/3/2016 at 05:27 PM, in message
<caflbxzaf5fjoj6dgbcmsm4kda5_xihowshqhos1zwwxju9b...@mail.gmail.com>, George
Dunlap <george.dun...@eu.citrix.com> wrote: 
> On Thu, Mar 3, 2016 at 2:59 AM, Chun Yan Liu <cy...@suse.com> wrote: 
>>>>> On 3/3/2016 at 02:46 AM, in message <56d7350f.7010...@citrix.com>, George 
> > Dunlap <george.dun...@citrix.com> wrote: 
> >> 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." 
> > Here, user could first try 'echo xxx > sysfs_driver_path/bind", so maybe: 
> > "Try binding USB device to original driver by echoing the device to 
> > [driver_path]/bind, or removing and re-inserting the USB device, or 
> > reloading the driver modules." 
>  
> Yes, I had thought about the idea of giving the user specific commands 
> to retry.  The question is how much we can expect the user to do to 
> recover the state.  At some point "reloading the driver module" was 
> seen as something reasonable for a reasonably advanced user, while 
> "messing around with sysfs" was seen to be something too technical. 
> But as you say, giving them the exact command to cut-and-paste might 
> be somewhat more reasonable. 
>  
> I'm still inclined to say that we should just stick with module 
> reloading and removing and re-inserting the device, but I wouldn't 
> insist on it. 

I see. Just use what you suggested. Will update and repost.

Thanks,
Chunyan

>  
> If we do print this kind of help message, then we should make sure to 
> print a more complete message that includes cut-and-paste commands for 
> *all* remaining unbound interfaces. 
>  
>  -George 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V15 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 3/3/2016 at 05:20 PM, in message
<caflbxzaoyb0psxxji_mf3g6yie80oh2x_o3tjahth1xjmjj...@mail.gmail.com>, George
Dunlap <george.dun...@eu.citrix.com> wrote: 
> On Thu, Mar 3, 2016 at 3:11 AM, Chun Yan Liu <cy...@suse.com> wrote: 
>>>>> On 3/3/2016 at 02:32 AM, in message <56d731b1.60...@citrix.com>, George 
>>>>> Dunlap 
> > <george.dun...@citrix.com> wrote: 
> >> On 01/03/16 08:09, Chunyan Liu wrote: 
> >> > +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, , ); 
> >> > +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, ); 
> >> > +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. 
> > 
> > Just according to last time discussion about how to handle the rebind 
> > failure, seems Ian preferred to add a xl command to deal with rebind 
> > in future, based on that need, I think driver_path info should be kept 
> > in xenstore then. Without that need, I agree it's best to remove 
> > xenstore nodes. So, keep or remove? 
>  
> Well when we have such a command, then yes, we'll need to keep the 
> nodes for it to use and delete.  But at the moment, we have no such 
> command, so these nodes will just sit around cluttering up the libxl 
> xenstore space, and nothing will delete them (unless a user manually 
> runs xenstore-rm). 
>  
> So I think for now we should delete them on failure; and at some point 
> later, when someone implements a recovery command, then they should 
> change this code to not delete the xenstore nodes (and also change the 
> log messages to point to that command). 

OK. Got it. Will update.

-  Chunyan

>  
>  -George 
>  
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V15 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 3/3/2016 at 02:32 AM, in message <56d731b1.60...@citrix.com>, 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  
> > Signed-off-by: George Dunlap  
> > Signed-off-by: Chunyan Liu  
> > --- 
> > 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, , ); 
> > +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, ); 
> > +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. 

Just according to last time discussion about how to handle the rebind
failure, seems Ian preferred to add a xl command to deal with rebind
in future, based on that need, I think driver_path info should be kept
in xenstore then. Without that need, I agree it's best to remove
xenstore nodes. So, keep or remove?

[Post last time Ian's idea]
[start]
The only wrinkle is that the obvious implementation reads the old
bindings from xenstore between 1 and 2, deletes the information from
xenstore in 2, and uses that information in step 3, which is cheating
(and leads to the sysfs-wrangling-required state).  But that is quite
easy to avoid:
  - record the old driver bindings somewhere in xenstore (keyed by
the physical host device, not the guest domain)
  - provide a libxl call and corresponding xl command which attempts
to rebind

But, FAOD, I do not want to block this patch until such a thing is
implemented.  I think it is sufficient to document the existence of
the awkward state, and the likely workarounds.
[end]

>  
> > +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(); 
> > +libxl_usbctrlinfo_init(); 
> > +usbctrl.devid = usbdev->ctrl; 
> > + 
> > +rc = libxl_device_usbctrl_getinfo(CTX, domid, , ); 
> > +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 

Re: [Xen-devel] [PATCH V15 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 3/3/2016 at 02:46 AM, in message <56d7350f.7010...@citrix.com>, George
Dunlap  wrote: 
> 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  
> >> Signed-off-by: George Dunlap  
> >> Signed-off-by: Chunyan Liu  
> >> --- 
> >> 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, , ); 
> >> +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, ); 
> >> +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(); 
> >> +libxl_usbctrlinfo_init(); 
> >> +usbctrl.devid = usbdev->ctrl; 
> >> + 
> >> +rc = libxl_device_usbctrl_getinfo(CTX, domid, , 
> >> ); 
> >> +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 

Re: [Xen-devel] [PATCH V14 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 2/29/2016 at 06:14 PM, in message <56d419f6.8030...@citrix.com>, George
Dunlap  wrote: 
> On 26/02/16 12:09, Ian Jackson wrote: 
> > George Dunlap writes ("Re: [Xen-devel] [PATCH V14 4/6] libxl: add pvusb  
> API"): 
> >> On Fri, Feb 19, 2016 at 10:39 AM, Chunyan Liu  wrote: 
> >>> +  [...] 
> >> 
> >> So I see below that you're calling this before removing things from 
> >> xenstore, so that if any of these fail, the user can still call "xl 
> >> usb-remove" to retry. 
> >> 
> >> Unfortunately, since you reassign interfaces to the original driver 
> >> before all interfaces are de-assigned from usbback, you can end up in 
> >> a situation where the device is partially re-plugged into the original 
> >> drivers, partially still assigned to pciback. 
> >> 
> >> I think this whole process should be 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. 

I'll update codes to this order and post.

-Chunyan

> >  
> > This seems like a good plan to me. 
> >  
> > (Making 3 after 2 re-attemptable would mean that the original driver 
> > information needs to be saved in a different location in xenstore to 
> > the pvusb control nodes, but that is not a problem.) 
> >  
> >> * If one of the re-assignments fail, then the user will have to reload 
> >> the drivers, reboot, or mess around with sysfs to fix things. 
> >> *However*, this avoids a scenario where a user is completely unable to 
> >> remove a device from a domain because of a buggy driver. 
> >  
> > Right. 
> >  
> >> I realize this falls short of the "crash-only" design IanJ suggested 
> >> we try to do, but I think that in this case the work required to do 
> >> such a design would be a lot more work than the benefit it gives us. 
> >  
> > I think what you have above is indeed crash-only.  You can tell by all 
> > the "if any error occurs, stop immediately". 
> >  
> > The only wrinkle is that the obvious implementation reads the old 
> > bindings from xenstore between 1 and 2, deletes the information from 
> > xenstore in 2, and uses that information in step 3, which is cheating 
> > (and leads to the sysfs-wrangling-required state).  But that is quite 
> > easy to avoid: 
> >   - record the old driver bindings somewhere in xenstore (keyed by 
> > the physical host device, not the guest domain) 
> >   - provide a libxl call and corresponding xl command which attempts 
> > to rebind 
>  
> The re-bind information is already stored in a different location, keyed 
> by physical host device. :-) (Search for uses of USBBACK_INFO_PATH.) 
>  
> But we would, as you say, need to add a separate function/command for 
> doing clean-up (simply calling xl usb-detach on the virtual device again 
> doesn't make much sense, since the virtual devices no longer shows up in 
> xl usb-list).  Since we don't have another such command to copy, we'd be 
> inventing a new one, which means thinking very carefully about the 
> design of the interface (since we'd want future such functions to follow 
> this precedent if possible),  , so... 
>  
> > But, FAOD, I do not want to block this patch until such a thing is 
> > implemented.  I think it is sufficient to document the existence of 
> > the awkward state, and the likely workarounds. 
>  
> Great, thanks. :-) 
>  
>  -George 
>  
>  
>  
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V14 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 2/24/2016 at 01:10 AM, in message
, George
Dunlap  wrote: 
> On Fri, Feb 19, 2016 at 10:39 AM, 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  
> > Signed-off-by: George Dunlap  
> > Signed-off-by: Chunyan Liu  
> > --- 
> > changes: 
> >   Address Olaf's comments: 
> >   * move DEFINE_DEVICE_REMOVE changes to a separate patch 
> >   Address Ian's comments: 
> >   * adjust order of removing xenstore and bind/unbind driver in usb_remove. 
> >   * reuse libxl_write_exactly in usbintf_bind/unbind 
> >   * several coding style fix 
>  
> [snip] 
>  
> > +/* Unbind USB device from "usbback" driver. 
> > + * 
> > + * If there are many interfaces under USB device, check each interface, 
> > + * unbind from "usbback" driver and rebind to its original driver. 
> > + */ 
> > +static int usbback_dev_unassign(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, , ); 
> > +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; 
> > + 
> > +/* check if the USB interface is already bound to "usbback" */ 
> > +if (usbintf_is_assigned(gc, intf) > 0) { 
> > +/* unbind interface from usbback driver */ 
> > +rc = unbind_usbintf(gc, intf); 
> > +if (rc) { 
> > +LOGE(ERROR, "Couldn't unbind %s from usbback", intf); 
> > +goto out; 
> > +} 
> > +} 
> > + 
> > +/* 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, ); 
> > +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; 
> > +} 
> > +} 
> > +} 
>  
> So I see below that you're calling this before removing things from 
> xenstore, so that if any of these fail, the user can still call "xl 
> usb-remove" to retry. 
>  
> Unfortunately, since you reassign interfaces to the original driver 
> before all interfaces are de-assigned from usbback, you can end up in 
> a situation where the device is partially re-plugged into the original 
> drivers, partially still assigned to pciback. 
>  
> I think this whole process should be 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. 
>  
> And in the case of #3, the log message should give a suggestion as to 
> what might help; for instance, "Couldn't rebind USB device to driver 
> [driver name].  Reloading the module may help."  (I think you should 
> be able to get the driver name from the path, right?) 

Yes, that's right.

>  
> A couple of properties this gives us: 
>  
> * If the un-assign partially succeeds, the user can re-try the unassign 
>  
> * If one of the re-assignments fail, then the user will have to reload 
> the drivers, reboot, or mess around with sysfs to fix things. 
> *However*, this avoids a scenario where a user is completely unable to 
> remove a device from a domain because of a buggy driver. 

To guest or host, this situation that some interface is bound to pciback
but some is to original driver, is indeed a mess. But to toolstack, it can
still have chance to redo 'xl usbdev-remove' to retry the left work (unassign
interfaces those bound to pciback, and reassign to original interface).

>  
> What do you think? 

The 3 steps above are indeed more reasonable. Codes need to be
reorganized (previously doing unassingn_form_pciback and rebind to
original driver in a same cycle for each interface, now will be split into
two separate processes: walk through each interface to do
unassign_from_pciback, and walk through each interface to rebind to
original 

Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Chun Yan Liu]

>>> On 2/17/2016 at 12:56 AM, in message <20160216165608.ga21...@gmail.com>, 
>>> Olaf
Hering  wrote: 
> On Tue, Jan 19, Chunyan Liu wrote: 
>  
> >  #xl usbctrl-attach test_vm version=1 ports=8 
>  
> >  #xl usbdev-attach test_vm hostbus=1 hostaddr=2 
>  
> I think this does not handle the -N knob of xl. Other commands check the 
> global dryrun_only variable. 

Just sent V14. I tried to add dryrun_only codes but finally gave up. For 
usbdev-attach,
since it will automatically and dynamically create usb controller in some 
cases, it's hard
to print dryrun-only information.

Chunyan
>  
> Olaf 
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Chun Yan Liu]

n

>>> On 2/17/2016 at 12:56 AM, in message <20160216165608.ga21...@gmail.com>, 
>>> Olaf
Hering  wrote: 
> On Tue, Jan 19, Chunyan Liu wrote: 
>  
> >  #xl usbctrl-attach test_vm version=1 ports=8 
>  
> >  #xl usbdev-attach test_vm hostbus=1 hostaddr=2 
>  
> I think this does not handle the -N knob of xl. Other commands check the 
> global dryrun_only variable. 

Thanks. I'll add.

>  
> Olaf 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 2/3/2016 at 10:38 PM, in message <56b210fa.7040...@citrix.com>, George
Dunlap <george.dun...@citrix.com> wrote: 
> On 03/02/16 07:34, Chun Yan Liu wrote: 
> >  
> >  
> >>>> On 2/3/2016 at 02:11 AM, in message 
> > <22192.61775.427189.268...@mariner.uk.xensource.com>, Ian Jackson 
> > <ian.jack...@eu.citrix.com> wrote:  
> >> George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb  
> API"):  
> >>> There are effectively four states a device can be in, from the  
> >>> 'assignment' point of view:  
> >>>   
> >>> 1. Assigned to the normal Linux device driver(s) for the USB device  
> >>>   
> >>> 2. Assigned to no driver  
> >>>   
> >>> 3. Assigned to usbback, but not yet assigned to any guest  
> >>>   
> >>> 4. Assigned to a guest  
> >>   
> >> Thanks for your clear explanation (of which I will snip much).  
> >>   
> >>> Additionally, each USB "device" has one or more "interfaces".  To  
> >>> assign a "device" to usbback in the sysfs case means assigning all of  
> >>> the "interfaces".  The code seems to assume that different interfaces  
> >>> from the same device can be assigned to different drivers.  
> >>   
> >> It is indeed the case that in principle a single USB device with  
> >> multiple interfaces can be assigned to multiple different drivers.  
> >>   
> >>> Regarding Ian's comments:  
> >>>   
> >>> Since "assigned to the guest" and "listed under the pvusb xenstore  
> >>> node" are the same thing, is it even *possible* to (safely) unassign  
> >>> the device from usbback before removing the xenstore nodes?  
> >>   
> >> It might be possible to remove some of the xenstore nodes but leave  
> >> others present, so that usbback detaches, but enough information  
> >> remains for libxl to know that Xen still `owns' the device.  
> >  
> > Indeed "unassign from usbback, but listed under pvusb xenstore" is 
> > a confusing state. usb-list can list it but guest can not see it.  
> > What user can do under that state is: reattempt usbdev_remove, if it  
> > succeeds, everything is cleaned up, that's the best result; but  
> > possibly it still fails (for example, in my testing, always cannot  
> > rebind to original driver), in this case, the confusing state will  
> > be lasting, and the device could not be removed, this is worse. 
>  
> As I said in my other mail, I think removing the pvusb nodes should be 
> done once it's successfully un-bound from usbback, *even if* the re-bind 
> to the original driver fails.  (That is, once it reaches state 2, 
> usb-list should no longer list it.) 
>  
> >>> Perhaps the best approach code-wise is to change the "goto out" on  
> >>> failure of unbind_usbintf() into a "continue".  That way:  
> >>>   
> >>> 1. All interfaces which can be re-assigned are re-assigned (and work  
> >>> as much as possible)  
> >>>   
> >>> 2. All interfaces which can be unbound but not re-assigned are at  
> >>> least unbound (so that reloading the original driver might pick them  
> >>> up)  
> >>   
> >> I certainly don't mind the software trying to do as much of its task  
> >> as possible. 
> >  
> > Could I understand that this way is acceptable? That means: removing  
> > xenstore, and as much as we could (on failure of "unbind from usbback" 
> > or "bind to original driver", don't "goto out", just "continue"). 
>  
> I think part of it depends on what is *possible*.  If it's possible to 
> safely unbind the device from usbback while retaining its place in the 
> pvusb-related xenstore nodes, then I think we should (so that the user

Juergen, I think you are the person who can answer the question best.
Can you confirm that?

-Chunyan

> can re-try removing it).  If it's not possible, then of course we have 
> to remove the pvusb xenstore nodes first, and then we'll just have to 
> deal as gracefully as possible with failure unbinding from usbback. 
>  
>  -George 
>  
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 2/3/2016 at 10:33 PM, in message <56b20fcc.3010...@citrix.com>, George
Dunlap  wrote: 
> On 02/02/16 18:11, Ian Jackson wrote: 
> > George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb  
> API"): 
> >> There are effectively four states a device can be in, from the 
> >> 'assignment' point of view: 
> >> 
> >> 1. Assigned to the normal Linux device driver(s) for the USB device 
> >> 
> >> 2. Assigned to no driver 
> >> 
> >> 3. Assigned to usbback, but not yet assigned to any guest 
> >> 
> >> 4. Assigned to a guest 
> >  
> > Thanks for your clear explanation (of which I will snip much). 
> >  
> >> Additionally, each USB "device" has one or more "interfaces".  To 
> >> assign a "device" to usbback in the sysfs case means assigning all of 
> >> the "interfaces".  The code seems to assume that different interfaces 
> >> from the same device can be assigned to different drivers. 
> >  
> > It is indeed the case that in principle a single USB device with 
> > multiple interfaces can be assigned to multiple different drivers. 
> >  
> >> Regarding Ian's comments: 
> >> 
> >> Since "assigned to the guest" and "listed under the pvusb xenstore 
> >> node" are the same thing, is it even *possible* to (safely) unassign 
> >> the device from usbback before removing the xenstore nodes? 
> >  
> > It might be possible to remove some of the xenstore nodes but leave 
> > others present, so that usbback detaches, but enough information 
> > remains for libxl to know that Xen still `owns' the device. 
> >  
> > But, surely usbback needs to cope with the notion that the device 
> > might disappear.  USB devices can disappear at any time. 
>  
> That's true. But if the USB device has actually disappeared, the device 
> is in fact "safe" from usbback.  I think I might consider state 2 safe 
> to go to, but I definitely wouldn't consider state 1 safe with the 
> xenstore nodes still in place. 
>  
> >  
> >> It's not clear to me under what conditions 3->2 might fail, 
> >  
> > As an example, someone might press ^C on `xl usb-detach'. 
>  
> *grumble* 
>  
> >> or what could be done about it if it did fail. 
> >  
> > The most obvious reason for it failing is that something somewhere 
> > still held onto the device.  (For umounting filesystems, and detaching 
> > block devices, this happens a lot.)  So if the detach from usbback 
> > fails would probably be possible to simply retry it. 
>  
> I'm not sure what this means in the context of moving from 3 (assigned 
> to usbback) to 2 (unassigned).  usbback will definitely not use the 
> device to mount something in dom0; and I'm pretty sure has no visibility 
> as to whether it's being used as a filesystem in the domU. 
>  
> (Moving from 1 -> 2 of course would be subject to this sort of thing, 
> but that's a different issue.) 
>  
> >> Regarding 2->1, again it's not clear that there's anything libxl can 
> >> do.  Reloading the driver's module might reset it enough to pick up 
> >> the (now unassigned) USB devices again; other than that, rebooting is 
> >> probably the best option. 
> >  
> > I think re-attempting the bind may work.  USB devices can be flaky. 
> >  
> >> It's also not clear to me, if some functions succeed in being 
> >> reassigned and others fail, whether it's best to just try to assign as 
> >> many as we can, or better to go back and un-assign all the ones that 
> >> succeeded. 
> >  
> > Unless explicitly requested, I don't think the system should create 
> > situations some interfaces are assigned to host drivers and some to 
> > usbback. 
>  
> I was talking here about whether it would be better to have some 
> interfaces assigned to the original drivers and some interfaces left 
> unassigned, or to try to leave all interfaces unassigned if any of the 
> assignments fail. 
>  
> I agree, it would be better to try to avoid the possibility of having 
> some interfaces bound to usbback and some interfaces bound to the 
> original drivers. 
>  
> > And, I'm a fan of `crash-only software': in general, if a failure 
> > occurs, the situation should just be left as-is.  The intermediate 
> > state needs to be visible and rectifiable. 
> >  
> > This approach to software state machines avoids bugs where the system 
> > gets into `impossible' states, recovery from which is impossible 
> > because the designers didn't anticipate them. 
> >  
> > It would be tolerable if the recovery sometimes involves `lsusb' and 
> > echoing things into sysfs, but it would be better if not. 
>  
> Right -- so what about this.  When removing a USB device: 
>  
> * First modify the pvusb xenstore nodes such that 1) it's safe to 
> attempt removing the interfaces from usbback, but 2) they still show up 
> in usb-list.  (This may be a noop.) 
>  
> * Attempt to remove all interfaces from usbback; if any of these fail, 
> stop and report an error.  Possible recovery options: 
>  - Re-try the usb_remove command 
>  - Re-load 

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 1/27/2016 at 12:21 AM, in message
<caflbxzatwuvibujh663tr-gwfwrgcwsnkorecik9+q6tj3h...@mail.gmail.com>, George
Dunlap <george.dun...@eu.citrix.com> wrote: 
> On Tue, Jan 26, 2016 at 7:43 AM, Chun Yan Liu <cy...@suse.com> wrote: 
> > 
> > 
> >>>> On 1/20/2016 at 12:56 PM, in message 
> > <569f83f502660009e...@relay2.provo.novell.com>, "Chun Yan Liu" 
> > <cy...@suse.com> wrote: 
> > 
> >> 
> >>>>> On 1/19/2016 at 11:48 PM, in message 
> >> <22174.23240.402164.635...@mariner.uk.xensource.com>, Ian Jackson 
> >> <ian.jack...@eu.citrix.com> wrote: 
> >> > Chunyan Liu writes ("[PATCH V13 3/5] libxl: add pvusb API"): 
> >> > > 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 
> >> > 
> >> > 
> >> > Thanks.  This is making progress but I'm afraid we're not quite there 
> >> > yet. 
> >> > 
> >> > 
> >> > > +static int usbback_dev_unassign(libxl__gc *gc, const char *busid) 
> >> > > +{ 
> >> > ... 
> >> > > +/* Till here, USB device has been unbound from USBBACK and 
> >> > > + * removed from xenstore, usb list couldn't show it anymore, 
> >> > > + * so no matter removimg driver path successfully or not, 
> >> > > + * we will report operation success. 
> >> > > + */ 
> >> > 
> >> > I'm still unconvinced by this and this may mean that the code in this 
> >> > function is in the wrong order.  Earlier we had this exchange: 
> >> > 
> >> > > > Ought this function to really report success if these calls fail ? 
> >> > > 
> >> > > I think so. Till here, the USB device has already been unbound from 
> >> > > usbback and removed from xenstore. usb-list cannot list it any more. 
> >> > 
> >> > The problem is that I think that if this function fails, it can leave 
> >> >  - debris in xenstore (the usbback path) 
> >> Yes, it's true. 
> >> 
> >> >  - the interface bound to the wrong driver 
> >> No, it won't be bound to 'wrong' driver, only maybe not bound to any 
> >> driver 
> >> (Already unbound from usbback, but failed to rebound to its original 
> >> driver). 
> >> In this case, we would report warning: failed to rebind to driver xxx. 
> >> 
> >> > And then there is no way for the user to get libxl to re-attempt the 
> >> > operation, or clean up.  Am I right ? 
> >> 
> >> Yes. No way to re-attempt usbdev-detach or cleanup driver path in 
> >> xenstore. But won't affect next time usbdev-attach the same device. 
> >> 
> >> > 
> >> > One way to avoid this kind of problem is to deal with the xenstore 
> >> > path last.  That way the device will still appear as attached to the 
> >> > domain. 
> >> 
> >> I'm afraid if the side effect is acceptable? In my testing, some USB
> >> bluetooth 
> >> device always fails to rebind to 'btusb' driver after it's unbound 
> >> from 'usbback'. In this case, we can't detach it from the domain then. 

George & Ian, may I have your thoughts? Except for above case, I think dealing
with xenstore at last place is indeed better.
PS: I'll take vocation for half month, so hope to make any progress before that 
:-)

Thanks,
Chunyan

> > 
> > Ian J., any opinion on this? If it's still thought to be better, I'll  
> update patch. 
>  
> I think Ian may be waiting for me to reply and express an opinion; but 
> unfortunately that will have to wait until next week. :-( 
>  
>  -George 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 1/27/2016 at 12:12 AM, in message <20160126161253.ga9...@gmail.com>, Olaf
Hering  wrote: 
> On Tue, Jan 19, Chunyan Liu wrote: 
>  
> > +++ b/tools/libxl/libxl.c 
> > @@ -3204,7 +3204,7 @@ void  
> libxl__device_disk_local_initiate_detach(libxl__egc *egc, 
> >  aodev->dev = device; 
> >  aodev->callback = local_device_detach_cb; 
> >  aodev->force = 0; 
> > -libxl__initiate_device_remove(egc, aodev); 
> > +libxl__initiate_device_generic_remove(egc, aodev); 
> >  return; 
> >  } 
> >   
> > @@ -4172,8 +4172,10 @@ out: 
> >   * libxl_device_vkb_destroy 
> >   * libxl_device_vfb_remove 
> >   * libxl_device_vfb_destroy 
> > + * libxl_device_usbctrl_remove 
> > + * libxl_device_usbctrl_destroy 
>  
> This should be moved down to DEFINE_DEVICE_REMOVE_CUSTOM. 
>  
> >   */ 
> > -#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\ 
> > +#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\ 
> >  int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
> >  uint32_t domid, libxl_device_##type *type,  \ 
> >  const libxl_asyncop_how *ao_how)\ 
> > @@ -4193,13 +4195,19 @@ out: 
> >  aodev->dev = device;\ 
> >  aodev->callback = device_addrm_aocomplete;  \ 
> >  aodev->force = f;   \ 
> > -libxl__initiate_device_remove(egc, aodev);  \ 
> > +libxl__initiate_device_##remtype##_remove(egc, aodev);  \ 
> >  \ 
> >  out:\ 
> > -if (rc) return AO_CREATE_FAIL(rc); 
> >   
>   \ 
> > +if (rc) return AO_CREATE_FAIL(rc);  \ 
> >  return AO_INPROGRESS;   \ 
> >  } 
> >   
> > +#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \ 
> > +DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f) 
> > + 
> > +#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \ 
> > +DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f) 
> > + 
> >  /* Define all remove/destroy functions and undef the macro */ 
> >   
> >  /* disk */ 
>  
>  
> If this is the way to move forward, please split this out into a 
> separate change which can be applied to staging independent of any pvusb 
> changes. 
>  
> I think the patch needs also the #undef. 
>  

Got you. Will update.

>  
> > @@ -4223,6 +4231,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1) 
> >  DEFINE_DEVICE_REMOVE(vtpm, remove, 0) 
> >  DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
> >   
> > +/* usbctrl */ 
> > +DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0) 
> > +DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1) 
> > + 
> >  /* channel/console hotunplug is not implemented. There are 2  
> possibilities: 
> >   * 1. add support for secondary consoles to xenconsoled 
> >   * 2. dynamically add/remove qemu chardevs via qmp messages. */ 
>  
> A comment should mention both libxl_device_usbctrl_remove/destroy and 
> libxl__initiate_device_usbctrl_remove/destroy. 

Will add comments.

Thanks,
Chunyan

>  
> Olaf 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 1/20/2016 at 12:56 PM, in message
<569f83f502660009e...@relay2.provo.novell.com>, "Chun Yan Liu"
<cy...@suse.com> wrote: 

>  
>>>> On 1/19/2016 at 11:48 PM, in message 
> <22174.23240.402164.635...@mariner.uk.xensource.com>, Ian Jackson 
> <ian.jack...@eu.citrix.com> wrote:  
> > Chunyan Liu writes ("[PATCH V13 3/5] libxl: add pvusb API"):  
> > > 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  
> >   
> >   
> > Thanks.  This is making progress but I'm afraid we're not quite there  
> > yet.  
> >   
> >   
> > > +static int usbback_dev_unassign(libxl__gc *gc, const char *busid)  
> > > +{  
> > ...  
> > > +/* Till here, USB device has been unbound from USBBACK and  
> > > + * removed from xenstore, usb list couldn't show it anymore,  
> > > + * so no matter removimg driver path successfully or not,  
> > > + * we will report operation success.  
> > > + */  
> >   
> > I'm still unconvinced by this and this may mean that the code in this  
> > function is in the wrong order.  Earlier we had this exchange:  
> >   
> > > > Ought this function to really report success if these calls fail ?  
> > >   
> > > I think so. Till here, the USB device has already been unbound from  
> > > usbback and removed from xenstore. usb-list cannot list it any more.  
> >   
> > The problem is that I think that if this function fails, it can leave  
> >  - debris in xenstore (the usbback path)  
> Yes, it's true. 
>  
> >  - the interface bound to the wrong driver 
> No, it won't be bound to 'wrong' driver, only maybe not bound to any driver 
> (Already unbound from usbback, but failed to rebound to its original  
> driver). 
> In this case, we would report warning: failed to rebind to driver xxx.  
>  
> > And then there is no way for the user to get libxl to re-attempt the  
> > operation, or clean up.  Am I right ? 
>  
> Yes. No way to re-attempt usbdev-detach or cleanup driver path in 
> xenstore. But won't affect next time usbdev-attach the same device. 
>   
> >   
> > One way to avoid this kind of problem is to deal with the xenstore  
> > path last.  That way the device will still appear as attached to the  
> > domain.  
>  
> I'm afraid if the side effect is acceptable? In my testing, some USB  
> bluetooth 
> device always fails to rebind to 'btusb' driver after it's unbound 
> from 'usbback'. In this case, we can't detach it from the domain then.  

Ian J., any opinion on this? If it's still thought to be better, I'll update 
patch.

>  
> >   
> > To do this properly I think bind_usbintf may need to become idempotent  
> > even in the face of other callers racing to assign the device.  I  
> > think that would mean bind_usbif it would have to know what driver to  
> > expect to find the device bound to. 

bind_usbintf already has parameter to indicate which driver to be bound to.

- Chunyan
> >   
> > George, am I right here ?  
> >   
> >   
> > I have a few other comments too:  
> >   
> > > +/* get original driver path of usb interface, stored in @drvpath */  
> > > +static int usbintf_get_drvpath(libxl__gc *gc, const char *intf, char   
> > **drvpath)  
> > > +{  
> > > +char *spath, *dp = NULL;  
> > > +struct stat st;  
> > > +int rc;  
> > > +  
> > > +spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf);  
> > > +  
> > > +rc = lstat(spath, );  
> >   
> > This `rc' should be `r'.  (CODING_STYLE.)  
> >   
> > I mentioned this in my review of v12 in the context of  
> > sysfs_write_intf.  But there is still more than one occurrence in v13  
> > of `rc' for a syscall return value.  
> >   
>  
> Sorry, will double check again. 
>  
> >   
> > > +static int sysfs_write_intf(libxl__gc *gc, const char *intf, const char  
> > >  
> > *path)  
> > > +{  
> >   
> > Last time I wrote:  
> >   
> >   But there is nothing usb specific about this function.  Looking for  
> >   similar code elsewhere this function seems very similar to  
> >   libxl_pci.c:sysfs_write_bdf, but I won't ask you to try to refactor  
> >   these two functions together.  
> >   
> > This time I have remembered

Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 1/19/2016 at 11:48 PM, in message
<22174.23240.402164.635...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Chunyan Liu writes ("[PATCH V13 3/5] libxl: add pvusb API"): 
> > 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 
>  
>  
> Thanks.  This is making progress but I'm afraid we're not quite there 
> yet. 
>  
>  
> > +static int usbback_dev_unassign(libxl__gc *gc, const char *busid) 
> > +{ 
> ... 
> > +/* Till here, USB device has been unbound from USBBACK and 
> > + * removed from xenstore, usb list couldn't show it anymore, 
> > + * so no matter removimg driver path successfully or not, 
> > + * we will report operation success. 
> > + */ 
>  
> I'm still unconvinced by this and this may mean that the code in this 
> function is in the wrong order.  Earlier we had this exchange: 
>  
> > > Ought this function to really report success if these calls fail ? 
> >  
> > I think so. Till here, the USB device has already been unbound from 
> > usbback and removed from xenstore. usb-list cannot list it any more. 
>  
> The problem is that I think that if this function fails, it can leave 
>  - debris in xenstore (the usbback path) 
Yes, it's true.

>  - the interface bound to the wrong driver
No, it won't be bound to 'wrong' driver, only maybe not bound to any driver
(Already unbound from usbback, but failed to rebound to its original driver).
In this case, we would report warning: failed to rebind to driver xxx. 

> And then there is no way for the user to get libxl to re-attempt the 
> operation, or clean up.  Am I right ?

Yes. No way to re-attempt usbdev-detach or cleanup driver path in
xenstore. But won't affect next time usbdev-attach the same device.
 
>  
> One way to avoid this kind of problem is to deal with the xenstore 
> path last.  That way the device will still appear as attached to the 
> domain. 

I'm afraid if the side effect is acceptable. In my testing, some USB bluetooth
device always fails to rebind to 'btusb' driver after it's unbound
from 'usbback'. In this case, we can't detach it from the domain then. 

>  
> To do this properly I think bind_usbintf may need to become idempotent 
> even in the face of other callers racing to assign the device.  I 
> think that would mean bind_usbif it would have to know what driver to 
> expect to find the device bound to. 
>  
> George, am I right here ? 
>  
>  
> I have a few other comments too: 
>  
> > +/* get original driver path of usb interface, stored in @drvpath */ 
> > +static int usbintf_get_drvpath(libxl__gc *gc, const char *intf, char  
> **drvpath) 
> > +{ 
> > +char *spath, *dp = NULL; 
> > +struct stat st; 
> > +int rc; 
> > + 
> > +spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf); 
> > + 
> > +rc = lstat(spath, ); 
>  
> This `rc' should be `r'.  (CODING_STYLE.) 
>  
> I mentioned this in my review of v12 in the context of 
> sysfs_write_intf.  But there is still more than one occurrence in v13 
> of `rc' for a syscall return value. 
>  

Sorry, will double check again.

>  
> > +static int sysfs_write_intf(libxl__gc *gc, const char *intf, const char  
> *path) 
> > +{ 
>  
> Last time I wrote: 
>  
>   But there is nothing usb specific about this function.  Looking for 
>   similar code elsewhere this function seems very similar to 
>   libxl_pci.c:sysfs_write_bdf, but I won't ask you to try to refactor 
>   these two functions together. 
>  
> This time I have remembered that libxl_write_exactly exists, and could 
> be used.  Sorry for not saing this last time but I think you can 
> probably just get rid of this in favour of libxl_write_exactly.  If 
> you think not, please say why. 

After checking the codes, yes, except for open and close fd,
libxl_write_exactly does the work. Will reuse it.

>  
>  
> > +static int bind_usbintf(libxl__gc *gc, const char *intf, const char  
> *drvpath) 
> > +{ 
> > +char *path; 
> > +struct stat st; 
> > + 
> > +path = GCSPRINTF("%s/%s", drvpath, intf); 
> > +/* if already bound, return */ 
> > +if (!lstat(path, )) 
> > +return 0; 
> > +else if (errno != ENOENT) 
> > +return ERROR_FAIL; 
>  
> This new ERROR_FAIL fails to log anything, and probably should.  I 
> think the anomalous style leads to this mistake.  You should say 
>r = lstat... 
> and adopt the pattern from the rest of libxl. 

Will update.

Thanks,
Chunyan

>  
>  
> Thanks, 
> Ian. 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V12 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 1/13/2016 at 02:31 AM, in message
<22165.18064.452737.543...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Chunyan Liu writes ("[PATCH V12 3/5] libxl: add pvusb API"): 
> > 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: Chunyan Liu  
> > Signed-off-by: Simon Cao  
> > Signed-off-by: George Dunlap  
> > Reviewed-by: George Dunlap  
>  
> Thanks.  I have re-reviewed this and found a few issues, I'm afraid, 
> mostly in the error handling. 
>  
> > +/* find first unused controller:port and give that to usb device */ 
> > +static int 
> > +libxl__device_usbdev_set_default_usbctrl(libxl__gc *gc, uint32_t domid, 
> > + libxl_device_usbdev *usbdev) 
> > +{ 
> ... 
> > +path = GCSPRINTF("%s/backend/vusb/%d/%d/port/%d", 
> > + libxl__xs_get_dompath(gc,  
> LIBXL_TOOLSTACK_DOMID), 
> > + domid, usbctrls[i].devid, j + 1); 
> > +tmp = libxl__xs_read(gc, XBT_NULL, path); 
>  
> I think this probably ought to be libxl__xs_read_checked ?  (With 
> corresponding change to handling of return value.) 
OK.
>  
> > +/* get original driver path of usb interface, stored in @drvpath */ 
> > +static int usbintf_get_drvpath(libxl__gc *gc, const char *intf, char  
> **drvpath) 
> > +{ 
> > +char *spath, *dp = NULL; 
> > +struct stat st; 
> > +int rc; 
> > + 
> > +spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf); 
> > + 
> > +rc = lstat(spath, ); 
> > +if (rc == 0) { 
> > +/* Find the canonical path to the driver. */ 
> > +dp = libxl__zalloc(gc, PATH_MAX); 
> > +dp = realpath(spath, dp); 
>  
> This call to realpath seems to lack error checking/handling. 

Will update.

>  
> > +static int sysfs_write_intf(libxl__gc *gc, const char *intf, const char  
> *path) 
> > +{ 
>  
> What is `intf' here ?  Maybe `interface' ?  But there is nothing usb 
> specific about this function.  Looking for similar code elsewhere this 
> function seems very similar to libxl_pci.c:sysfs_write_bdf, but I 
> won't ask you to try to refactor these two functions together. 

Yes, it means 'interface'. It is referring to old xend/xm naming.
For example, a USB device in Linux sysfs is 3-11, under it, there might be
3-11:1.0 and 3-11:1.1 (these are two interfaces). To assign this USB device
to guest, both 3-11:1.0 and 3-11:1.1 should be unbind from original driver
and bind to usbback.

>  
> > +rc = write(fd, intf, strlen(intf)); 
>  
> rc ought not be used for a syscall return value.  (CODING_STYLE) 

Will update.

>  
> > +close(fd); 
>  
> This is a pretty ad-hoc error handling approach.  Can you please use 
> the CODYING_STYLE-recommended pattern ? 

Will update.

> > +static int bind_usbintf(libxl__gc *gc, const char *intf, const char  
> *drvpath) 
> > +{ 
> > +char *path; 
> > +struct stat st; 
> > + 
> > +path = GCSPRINTF("%s/%s", drvpath, intf); 
> > +/* if already bound, return */ 
> > +if (!lstat(path, )) 
> > +return 0; 
>  
> If lstat fails, you need to check the error return to see why. 

Will update.

>  
> > +/* Encode usb interface so that it could be written to xenstore as a key. 
> > + * 
> > + * Since xenstore key cannot include '.' or ':', we'll change '.' to '_', 
> > + * change ':' to '@'. For example, 3-1:2.1 will be encoded to 3-1@2_1. 
> > + * This will be used to save original driver of USB device to xenstore. 
> > + */ 
> > +static char *usb_interface_xenstore_encode(libxl__gc *gc, const char  
> *busid) 
> > +{ 
> > +char *str = libxl__strdup(gc, busid); 
> > +int i, len = strlen(str); 
> > + 
> > +for (i = 0; i < len; i++) { 
> > +if (str[i] == '.') 
> > +str[i] = '_'; 
> > +if (str[i] == ':') 
> > +str[i] = '@'; 
>  
> I know I'm late with this comment and it's trivial and my 
> comaintainers may disagree, but I would find this 
>  
>   +if (str[i] == '.') str[i] = '_'; 
>   +if (str[i] == ':') str[i] = '@'; 
>  
> clearer because the layout reflects the regular structure of the code. 
> But please don't change this until another maintainer has commented 
> and said whether they agree with me.  Certainly this is observation of 
> mine does not block this patch. 
>  
> > +static int usbback_dev_unassign(libxl__gc *gc, const char *busid) 
> > +{ 
> > +char **intfs = NULL; 
> > +char *usbdev_encode = NULL; 
> > +char *path = NULL; 
> > +int i, num = 0; 
> > +int rc; 
> > + 
> > +if (usbdev_get_all_interfaces(gc, busid, , ) < 0) 
> > +return ERROR_FAIL; 
>  
> usbdev_get_all_interfaces returns a libxl error code, which you 

Re: [Xen-devel] Xen 4.7 Development Update

[Chun Yan Liu]

>>> On 1/4/2016 at 06:15 PM, in message , Wei Liu
 wrote: 
> This email only tracks big items for xen.git tree. Please reply for items you 
> woulk like to see in 4.7 so that people have an idea what is going on and 
> prioritise accordingly. 
>  
> You're welcome to provide description and use cases of the feature you're 
> working on. 
>  
> = Timeline = 
>  
> We now adopt a fixed cut-off date scheme. We will release twice a 
> year. The upcoming 4.7 timeline are as followed: 
>  
> * Last posting date: March 18, 2016 
> * Hard code freeze: April 1, 2016 
> * RC1: TBD 
> * Release: June 3, 2016 
>  
> Note that we don't have freeze exception scheme anymore. All patches 
> that wish to go into 4.7 must be posted no later than the last posting 
> date. All patches posted after that date will be automatically queued 
> into next release. 
>  
> RCs will be arranged immediately after freeze. 
>  
> = Projects = 
>  
> == Hypervisor ==  
>  
> *  Use Kconfig to configure hypervisor components 
>   -  Doug Goldstein 
>  
> === x86 ===  
>  
> *  CPUID handling improvement 
>   -  Andrew Cooper 
>  
> *  VMWare tools support 
>   -  Don Slutz 
>  
> *  xSplice, hypervisor hot-patching 
>   -  Konrad Wilk 
>   -  Ross Lagerwall 
>  
> *  Porting Intel PState driver 
>   -  Wei Wang 
>  
> *  HVM-nodm support 
>   -  Roger Pau Monne 
>  
> *  Posted interrupt 
>   -  Wu, Feng 
>  
> *  VMX TSC scaling support 
>   -  Haozhong Zhang 
>  
> *  VT-d asynchronous flush issue 
>   -  Quan Xu 
>  
> *  Memory protection-key support 
>   -  Huaitong Han 
>  
> === ARM ===  
>  
> *  Guest save / restore support 
>   -  Ian Campbell 
>  
> == Toolstack ==  
>  
> *  Make it easy to run xenstore in a domain 
>   -  Juergen Gross 
>  
> *  Libxc support for migrating large PV domains 
>   -  Juergen Gross 
>  
> *  Disentangle libxenctrl to stable libraries 
>   -  Ian Campbell 
>  
> *  Libxl PVSCSI support 
>   -  Olaf Hering 
>  
> *  PV USB passthrough 
>   -  Chunyan Liu 

Reviewed by George Dunlap.
V12:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html

>  
> *  HVM USB passthrough 
>   -  George Dunlap 
>  
> *  QEMU based PVUSB backend 
>   -  Juergen Gross 
>  
> *  Domain snapshot API 
>   -  Chunyan Liu 

Doc:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00884.html

RFC implementation, has many limitations, call for comments:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg02384.html

Chunyan

>  
> *  Fix hotplug script machinery and remove blktap 
>   -  George Dunlap 
>  
> *  Basic xSplice tooling (see hypervisor item) 
>   -  Konrad Wilk 
>  
> *  Load BIOS via toolstack 
>   -  Anthony Perard 
>  
> *  Libxl depriv QEMU 
>   -  Ian Jackson 
>  
> *  COLO 
>   -  Wen Congyang 
>  
> == Documentation ==  
>  
> *  Feature maturity lifecycle 
>   -  Lars Kurth 
>  
> == Completed ==  
>  
> *  vgic-v3 
>   -  Julien Grall 
>  
> *  xsave/xrtors support 
>   -  Shuai Ruan 
>  
> *  Toolstack-based soft reset 
>   -  Vitaly Kuznetsov 
>  
> *  Libxc support for building large PV domains 
>   -  Juergen Gross 
>  
> *  Run QEMU as non-root 
>   -  Stefano Stabellini 
>  
> *  Intel CDP support 
>   -  He Chen 
>  
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v10 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 12/14/2015 at 07:37 PM, in message
<caflbxzzowhysotu7zzuxytd0rwrydo0lgskzfee9zmmojzn...@mail.gmail.com>, George
Dunlap <george.dun...@eu.citrix.com> wrote: 
> On Mon, Dec 14, 2015 at 7:25 AM, Chun Yan Liu <cy...@suse.com> wrote: 
> > 
> > 
> >>>> On 12/10/2015 at 08:08 PM, in message <56696b4b.7060...@citrix.com>, 
> >>>> George 
> > Dunlap <george.dun...@citrix.com> wrote: 
> >> On 10/12/15 12:05, George Dunlap wrote: 
> >> > From: Chunyan Liu <cy...@suse.com> 
> >> > 
> >> > 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: Chunyan Liu <cy...@suse.com> 
> >> > Signed-off-by: Simon Cao <caobosi...@gmail.com> 
> >> > Signed-off-by: George Dunlap <george.dun...@citrix.com> 
> >> 
> >> Attached is a diff of v9 -> v10 for convenience. 
> > 
> > Thanks very much, George! 
> > I've applied your new patch and tested, there are a couple of changes  
> needed to 
> > get tests PASSED. A small extra patch is written on top of your new patch,  
> as in 
> > attachment, please have a look. 
>  
> Thanks -- the changes in the patch look good. 
>  
> >> > +static int usbdev_get_all_interfaces(libxl__gc *gc, const char *busid, 
> >> > + char ***intfs, int *num) 
> >> > +{ 
> >> > +DIR *dir; 
> >> > +char *buf; 
> >> > +int rc; 
> >> > + 
> >> > +*intfs = NULL; 
> >> > +*num = 0; 
> >> > + 
> >> > +buf = GCSPRINTF("%s:", busid); 
> >> > + 
> >> > +dir = opendir(SYSFS_USB_DEV); 
> >> > +if (!dir) { 
> >> > +LOGE(ERROR, "opendir failed: '%s'", SYSFS_USB_DEV); 
> >> > +return ERROR_FAIL; 
> >> > +} 
> >> > + 
> >> > +size_t need = offsetof(struct dirent, d_name) + 
> >> > +pathconf(SYSFS_USB_DEV, _PC_NAME_MAX) + 1; 
> >> > +struct dirent *de_buf = libxl__zalloc(gc, need); 
> >> 
> >> Is this thing with manually calculating the size of the structure really 
> >> necessary?  Could we not just declare "struct dirent de_buf" on the stack? 
> > 
> > Calculating in above way is to allocate enough space for d_name, whereas 
> > "struct dirent de_buf" won't allocate space for d_name (which is char *). 
> > 
> > Codes for calling read_dir_r are often done like above. 
>  
> OK -- in that case, can you put the allocation of the structure into a 
> macro or helper function, fold in the patch you sent, and re-send this 
> series as v11? 

OK. Will update soon!

- Chunyan

>  
> Thanks! 
>  
>  -George 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v10 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 12/10/2015 at 08:08 PM, in message <56696b4b.7060...@citrix.com>, George
Dunlap  wrote: 
> On 10/12/15 12:05, George Dunlap wrote: 
> > From: Chunyan Liu  
> >  
> > 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: Chunyan Liu  
> > Signed-off-by: Simon Cao  
> > Signed-off-by: George Dunlap  
>  
> Attached is a diff of v9 -> v10 for convenience. 

Thanks very much, George!
I've applied your new patch and tested, there are a couple of changes needed to
get tests PASSED. A small extra patch is written on top of your new patch, as in
attachment, please have a look.

Otherwise, I agreed with all your other changes. It's great improvement.
Thanks a lot!  

>  
> One remaining question I had regarding this patch... 

For the question, see below.

>  
> > +static int usbdev_get_all_interfaces(libxl__gc *gc, const char *busid, 
> > + char ***intfs, int *num) 
> > +{ 
> > +DIR *dir; 
> > +char *buf; 
> > +int rc; 
> > + 
> > +*intfs = NULL; 
> > +*num = 0; 
> > + 
> > +buf = GCSPRINTF("%s:", busid); 
> > + 
> > +dir = opendir(SYSFS_USB_DEV); 
> > +if (!dir) { 
> > +LOGE(ERROR, "opendir failed: '%s'", SYSFS_USB_DEV); 
> > +return ERROR_FAIL; 
> > +} 
> > + 
> > +size_t need = offsetof(struct dirent, d_name) + 
> > +pathconf(SYSFS_USB_DEV, _PC_NAME_MAX) + 1; 
> > +struct dirent *de_buf = libxl__zalloc(gc, need); 
>  
> Is this thing with manually calculating the size of the structure really 
> necessary?  Could we not just declare "struct dirent de_buf" on the stack?

Calculating in above way is to allocate enough space for d_name, whereas
"struct dirent de_buf" won't allocate space for d_name (which is char *).

Codes for calling read_dir_r are often done like above.

- Chunyan

>  
> If it is necessary, it would be better to have it inside a function or 
> macro called "alloc_dirent" or something like that. 
>  
>  -George 
>  
>  


>From 771c99218a4704eb6a4850dfafb1cafad0798b9d Mon Sep 17 00:00:00 2001
From: Chunyan Liu 
Date: Mon, 14 Dec 2015 15:00:50 +0800
Subject: [PATCH 4/6] libxl pvusb API changes

* format fix: extra white space, line > 80, etc.
* return ERROR_FAILED instead of errno (>0) in sysfs_write_intf
* fix an error in libxl_ctrlport_to_device_usbdev

Signed-off-by: Chunyan Liu 
---
 tools/libxl/libxl_pvusb.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index cb25fa8..5f189d6 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -287,14 +287,15 @@ out:
 return;
 }
 
-static const char * vusb_be_from_xs_fe(libxl__gc *gc, const char *fe_path,
-   uint32_t tgt_domid) {
+static const char *vusb_be_from_xs_fe(libxl__gc *gc, const char *fe_path,
+  uint32_t tgt_domid)
+{
 const char *be_path;
 int r;
 uint32_t be_domid, fe_domid;
-
+
 r = libxl__xs_read_checked(gc, XBT_NULL, GCSPRINTF("%s/backend", fe_path),
- _path);
+   _path);
 if (r || !be_path) return NULL;
 
 /* Check to see that it has the proper form, and that fe_domid ==
@@ -302,11 +303,11 @@ static const char * vusb_be_from_xs_fe(libxl__gc *gc, 
const char *fe_path,
 r = sscanf(be_path, "/local/domain/%d/backend/vusb/%d",
_domid, _domid);
 
-if ( r != 2 || fe_domid != tgt_domid ) {
+if (r != 2 || fe_domid != tgt_domid) {
 LOG(ERROR, "Malformed backend, refusing to use");
 return NULL;
 }
-
+
 return be_path;
 }
 
@@ -810,7 +811,7 @@ static int libxl__device_usbdev_setdefault(libxl__gc *gc,
 } else {
 /* A controller was specified; look it up */
 const char *fe_path, *be_path, *tmp;
-
+
 fe_path = GCSPRINTF("%s/device/vusb/%d",
 libxl__xs_get_dompath(gc, domid),
 usbdev->ctrl);
@@ -828,7 +829,7 @@ static int libxl__device_usbdev_setdefault(libxl__gc *gc,
   be_path, usbdev->port),
 );
 if (rc) goto out;
-
+
 if (tmp && strcmp(tmp, "")) {
 LOG(ERROR, "The controller port isn't available");
 rc = ERROR_FAIL;
@@ -837,7 +838,7 @@ static int libxl__device_usbdev_setdefault(libxl__gc *gc,
 } else {
 /* No port was requested. Choose free port. */
 int i, ports;
-
+
 rc = 

Re: [Xen-devel] [PATCH v10 0/5] xen pvusb toolstack work

[Chun Yan Liu]

>>> On 12/10/2015 at 08:05 PM, in message
<1449749113-1243-1-git-send-email-george.dun...@eu.citrix.com>, George Dunlap
 wrote: 
> Chunyan, 
>  
> I did a thorough review of v3, and almost all the comments I had fell 
> into two categories: 
>  
> 1. Trivial things that could be easily fixed 
>  
> 2. Complicated things that would be difficult to explain and might 
> take several rounds to correct. 
>  
> As such, I hope you don't mind that I took the liberty to simply fix 
> up the series the way I thought it should be.  I've only 
> compile-tested this; if you could review it, and test it (and if 

Sure, I will. Thank you a lot!

- Chunyan

> necessary give more feedback), and then either ack it or revise and 
> re-send it, I'd appreciate it. 
>  
>  -George 
>  
> Below is Chunyan's original pvusb cover letter. 
>  
> --- 
> This patch series is to add pvusb toolstack work, supporting hot add|remove 
> USB device to|from guest and specify USB device in domain configuration  
> file. 
>  
> Changes to V9: 
> * Rebased to staging (ec0712576198633dd7fbfe25290b030d5a23b252) 
> * Lots of changes to patch 3/5 
> * Removed patches related to "list-assignable-devices" functionality 
>  
>   <<< pvusb work introduction >>> 
>  
> 1. Overview 
>  
> There are two general methods for passing through individual host 
> devices to a guest. The first is via an emulated USB device 
> controller; the second is PVUSB. 
>  
> Additionally, there are two ways to add USB devices to a guest: via 
> the config file at domain creation time, and via hot-plug while the VM 
> is running. 
>  
> * Emulated USB 
>  
> In emulated USB, the device model (qemu) presents an emulated USB 
> controller to the guest. The device model process then grabs control 
> of the device from domain 0 and and passes the USB commands between 
> the guest OS and the host USB device. 
>  
> This method is only available to HVM domains, and is not available for 
> domains running with device model stubdomains. 
>  
> * PVUSB 
>  
> PVUSB uses a paravirtialized front-end/back-end interface, similar to 
> the traditional Xen PV network and disk protocols. In order to use 
> PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
> your USB driver domain). 
>  
> 2. Specifying a host USB device 
>  
> QEMU qmp commands allows USB devices to be specified either by their 
> bus address (in the form bus.device) or their device tag (in the form 
> vendorid:deviceid). 
>  
> Each way of specifying has its advantages: 
>  
> Specifying by device tag will always get the same device, 
> regardless of where the device ends up in the USB bus topology. 
> However, if there are two identical devices, it will not allow you to 
> specify which one. 
>  
> Specifying by bus address will always allow you to choose a 
> specific device, even if you have duplicates. However, the bus address 
> may change depending on which port you plugged the device into, and 
> possibly also after a reboot. 
>  
> To avoid duplication of vendorid:deviceid, we'll use bus address to 
> specify host USB device in xl toolstack. 
>  
> You can use lsusb to list the USB devices on the system: 
>  
> Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 003 Device 002: ID f617:0905 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
> Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra 
> Fast Media Reader 
> Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse 
>  
> To pass through the Logitec mouse, for instance, you could specify 
> 1.6 (remove leading zeroes). 
>  
> Note: USB hubs can not be assigned to guest. 
>  
> 3. PVUSB toolstack 
>  
> * Specify USB device in xl config file 
>  
> You can just specify usb devices, like: 
> usbdev=['1.6'] 
>  
> Then it will create a USB controller automatically and attach the USB 
> device to the first available USB controller:port. 
>  
> or, you can explicitly specify usb controllers and usb devices, like: 
> usbctrl=['verison=1, ports=4', 'version=2, ports=8', ] 
> usbdev=['1.6, controller=0, port=1'] 
>  
> Then it will create two USB controllers as you specified. 
> And if controller and port are specified in usb config, then it will 
> attach the USB device to that controller:port. About the controller 
> and port value: 
> Each USB controller has a index (or called devid) based on 0. The 1st 
> controller has index 0, the 2nd controller has index 1, ... 
> Under controller, each port has a port number based on 1. In above 
> configuration, the 1st controller will have port 1,2,3,4. 
>  
> * Hot-Plug USB device 
>  
> To attach a USB device, you should first create a USB controller. 
> e.g. 
> xl usb-ctrl-attach domain [version=1|2] [ports=value] 
> By default, it will create a USB2.0 controller with 8 ports. 
>  
> Then you 

Re: [Xen-devel] [RESEND][PATCH V9 3/7] libxl: add pvusb API

[Chun Yan Liu]

Any comments?

>>> On 11/25/2015 at 05:46 PM, in message
<1448444775-6974-4-git-send-email-cy...@suse.com>, 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: Chunyan Liu  
> Signed-off-by: Simon Cao  
>  
> --- 
> changes: 
>   - update naming, all places indicating usb controller named 
> as usbctrl, all places indicating usb device named as usbdev 
>   - update DEFINE_DEVICE_REMOVE instead of creating a new 
> DEFINE_DEVICE_REMOVE_EXT 
>   - use libxl__xs_read_checked instead of libxl__xs_read 
>   - update local READ_SUBPATH(_INT) macros to include more common codes 
>   - save drvpath before unbind 
>   - get_assigned_devices: call libxl__device_usbdev_list_for_ctrl 
> instead of doing all things from scratch 
>   - usb_interface_xenstore_encode: use special char to avoid confusion 
>   - usb readdir_r instead of readdir 
>   - check syscall errno 
>   - remove usbinfo definition 
>   - address other comments except: 
> libxl__device_usbdev_add/remove and do_usbdev_add/remove, in previous 
> discussion, we'd like to get usbctrlinfo once and pass usbctrlinfo to 
> do_usbdev_add/remove. However, during update, adding usbdev process 
> still needs to try twice to get usbctrlinfo. (Before set_default, 
> if usbctrl doesn't exist it doesn't doing getting usbctrlinfo actually; 
> after set_default, needs to get usbctrlinfo then). So, finally, just 
> change codes to make adding/removing process symmetrical. 
>  
>  tools/libxl/Makefile |2 +- 
>  tools/libxl/libxl.c  |   50 +- 
>  tools/libxl/libxl.h  |   77 ++ 
>  tools/libxl/libxl_device.c   |5 +- 
>  tools/libxl/libxl_internal.h |   18 + 
>  tools/libxl/libxl_osdeps.h   |   13 + 
>  tools/libxl/libxl_pvusb.c| 1534  
> ++ 
>  tools/libxl/libxl_types.idl  |   46 + 
>  tools/libxl/libxl_types_internal.idl |1 + 
>  tools/libxl/libxl_utils.c|   18 + 
>  tools/libxl/libxl_utils.h|5 + 
>  11 files changed, 1766 insertions(+), 3 deletions(-) 
>  create mode 100644 tools/libxl/libxl_pvusb.c 
>  
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile 
> index 6ff5bee..a36145a 100644 
> --- a/tools/libxl/Makefile 
> +++ b/tools/libxl/Makefile 
> @@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o  
> libxl_dm.o libxl_pci.o \ 
>   libxl_stream_read.o libxl_stream_write.o \ 
>   libxl_save_callout.o _libxl_save_msgs_callout.o \ 
>   libxl_qmp.o libxl_event.o libxl_fork.o \ 
> - libxl_dom_suspend.o $(LIBXL_OBJS-y) 
> + libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y) 
>  LIBXL_OBJS += libxl_genid.o 
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o 
>   
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> index eaa7d75..a479465 100644 
> --- a/tools/libxl/libxl.c 
> +++ b/tools/libxl/libxl.c 
> @@ -4144,6 +4144,36 @@ out: 
>  return rc; 
>  } 
>   
> +static void libxl__initiate_device_disk_remove(libxl__egc *egc, 
> +   libxl__ao_device *aodev) 
> +{ 
> +return libxl__initiate_device_remove(egc, aodev); 
> +} 
> + 
> +static void libxl__initiate_device_nic_remove(libxl__egc *egc, 
> +  libxl__ao_device *aodev) 
> +{ 
> +return libxl__initiate_device_remove(egc, aodev); 
> +} 
> + 
> +static void libxl__initiate_device_vtpm_remove(libxl__egc *egc, 
> +   libxl__ao_device *aodev) 
> +{ 
> +return libxl__initiate_device_remove(egc, aodev); 
> +} 
> + 
> +static void libxl__initiate_device_vkb_remove(libxl__egc *egc, 
> +  libxl__ao_device *aodev) 
> +{ 
> +return libxl__initiate_device_remove(egc, aodev); 
> +} 
> + 
> +static void libxl__initiate_device_vfb_remove(libxl__egc *egc, 
> +  libxl__ao_device *aodev) 
> +{ 
> +return libxl__initiate_device_remove(egc, aodev); 
> +} 
> + 
>   
> / 
> **/ 
>   
>  /* Macro for defining device remove/destroy functions in a compact way */ 
> @@ -4158,6 +4188,8 @@ out: 
>   * libxl_device_vkb_destroy 
>   * libxl_device_vfb_remove 
>   * libxl_device_vfb_destroy 
> + * libxl_device_usbctrl_remove 
> + * libxl_device_usbctrl_destroy 
>   */ 
>  #define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\ 
>  int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
> @@ -4179,7 +4211,7 @@ out: 
>

Re: [Xen-devel] [PATCH v2] libxl: Introduce a template for devices with a controller

[Chun Yan Liu]

>>> On 12/1/2015 at 08:09 PM, in message
<1448971798-3498-1-git-send-email-george.dun...@eu.citrix.com>, George Dunlap
<george.dun...@eu.citrix.com> wrote: 
> We have several outstanding patch series which add devices that have 
> two levels: a controller and individual devices attached to that 
> controller. 
>  
> In the interest of consistency, this patch introduces a section that 
> sketches out a template for interfaces for such devices. 

Acked.

>  
> Signed-off-by: George Dunlap <george.dun...@citrix.com> 
> Acked-by: Juergen Gross <jgr...@suse.com> 
> --- 
> CC: Ian Campbell <ian.campb...@citrix.com> 
> CC: Ian Jackson <ian.jack...@citrix.com> 
> CC: Wei Liu <wei.l...@citrix.com> 
> CC: Juergen Gross <jgr...@suse.com> 
> CC: Chun Yan Liu <cy...@suse.com> 
> CC: Olaf Hering <o...@aepfle.de> 
>  
> Changes in v2: 
> - Fixed typos 
>  
> Changes in v1 (since the RFC): 
>  
> - Use  rather than , and  rather than specifying 
>   controller and device.  The idea being to allow SCSI to use 
>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun) 
>   rather than naming things after USB (controller & device). 
>  
> - Do not require each  to have a deviceid, but just a unique 
>   naming schema. 
>  
> - Allow multiple levels. 
>  
> - Include the paragraph about domain configuration lists. 
> --- 
>  tools/libxl/libxl.h | 65  
> + 
>  1 file changed, 65 insertions(+) 
>  
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> index 6b73848..44e2951 100644 
> --- a/tools/libxl/libxl.h 
> +++ b/tools/libxl/libxl.h 
> @@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int  
> nr_vtpms); 
>   * 
>   *   This function does not interact with the guest and therefore 
>   *   cannot block on the guest. 
> + * 
> + * Controllers 
> + * --- 
> + * 
> + * Most devices are treated individually.  Some classes of device, 
> + * however, like USB or SCSI, inherently have the need to have a 
> + * hierarchy of different levels, with lower-level devices "attached" 
> + * to higher-level ones.  USB for instance has "controllers" at the 
> + * top, which have buses, on which are devices, which consist of 
> + * multiple interfaces.  SCSI has "hosts" at the top, then buses, 
> + * targets, and LUNs. 
> + * 
> + * In that case, for each , there will be a set of functions 
> + * and types for each .  For example, for =usb, there 
> + * may be  ctrl (controller) and dev (device), with ctrl being 
> + * level 0. 
> + * 
> + * libxl_device__ will act more or 
> + * less like top-level non-bus devices: they will either create or 
> + * accept a libxl_devid which will be unique within the 
> + *  libxl_devid namespace. 
> + * 
> + * Lower-level devices must have a unique way to be identified.  One 
> + * way to do this would be to name it via the name of the next level 
> + * up plus an index; for instance, .  Another 
> + * way would be to have another devid namespace for that level.  This 
> + * identifier will be used for queries and removals. 
> + * 
> + * Lower-level devices will include in their 
> + * libxl_device_ struct a field referring to the unique 
> + * index of the level above.  For instance, libxl_device_usbdev might 
> + * contain the controller devid. 
> + * 
> + * In the case where there are multiple different ways to implement a 
> + * given device -- for instance, one which is fully PV and one which 
> + * uses an emulator -- the controller will contain a field which 
> + * specifies what type of implementation is used.  The implementations 
> + * of individual devices will be known by the controller to which they 
> + * are attached. 
> + * 
> + * If libxl_device__add receives an empty reference to 
> + * the level above, it may return an error.  Or it may (but is not 
> + * required to) automatically choose a suitable device in the level 
> + * above to which to attach the new device at this level.  It may also 
> + * (but is not required to) automatically create a new device at the 
> + * level above if no suitable devices exist.  Each class should 
> + * document its behavior. 
> + * 
> + * libxl_device__list will list all devices of  
> + * at  in the domain.  For example, libxl_device_usbctrl_list 
> + * will list all usb controllers; libxl_class_usbdev_list will list 
> + * all usb devices across all controllers. 
> + * 
> + * For each class, the domain config file will contain a single list 
> + * for each level.  libxl will first iterate through the list of 
> + * top-level devices, th

Re: [Xen-devel] [PATCH V9 0/7] xen pvusb toolstack work

[Chun Yan Liu]

According to current active discussion:
libxl: Introduce a template for devices with a controller
https://www.mail-archive.com/xen-devel@lists.xen.org/msg46720.html

Will update naming and RESEND.

- Chunyan

>>> On 11/24/2015 at 04:35 PM, in message
<1448354134-21644-1-git-send-email-cy...@suse.com>, Chunyan Liu
 wrote: 
> This patch series is to add pvusb toolstack work, supporting hot add|remove 
> USB device to|from guest and specify USB device in domain configuration  
> file. 
>  
> Changes to V8: 
> * lots of changes in libxl pvusb API (patch 3/7) 
> * update 2/7 to write separate read_sysfs_file function 
> * address all other comments 
>  
> V8: 
> http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html 
>  
> V7: 
> http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html 
>  
> V6: 
> http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html 
>  
> V5: 
> http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html 
>  
> V4: 
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html 
>  
> Related Discussion Threads: 
> http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html 
> http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html 
>  
>   <<< pvusb work introduction >>> 
>  
> 1. Overview 
>  
> There are two general methods for passing through individual host 
> devices to a guest. The first is via an emulated USB device 
> controller; the second is PVUSB. 
>  
> Additionally, there are two ways to add USB devices to a guest: via 
> the config file at domain creation time, and via hot-plug while the VM 
> is running. 
>  
> * Emulated USB 
>  
> In emulated USB, the device model (qemu) presents an emulated USB 
> controller to the guest. The device model process then grabs control 
> of the device from domain 0 and and passes the USB commands between 
> the guest OS and the host USB device. 
>  
> This method is only available to HVM domains, and is not available for 
> domains running with device model stubdomains. 
>  
> * PVUSB 
>  
> PVUSB uses a paravirtialized front-end/back-end interface, similar to 
> the traditional Xen PV network and disk protocols. In order to use 
> PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
> your USB driver domain). 
>  
> 2. Specifying a host USB device 
>  
> QEMU qmp commands allows USB devices to be specified either by their 
> bus address (in the form bus.device) or their device tag (in the form 
> vendorid:deviceid). 
>  
> Each way of specifying has its advantages: 
>  
> Specifying by device tag will always get the same device, 
> regardless of where the device ends up in the USB bus topology. 
> However, if there are two identical devices, it will not allow you to 
> specify which one. 
>  
> Specifying by bus address will always allow you to choose a 
> specific device, even if you have duplicates. However, the bus address 
> may change depending on which port you plugged the device into, and 
> possibly also after a reboot. 
>  
> To avoid duplication of vendorid:deviceid, we'll use bus address to 
> specify host USB device in xl toolstack. 
>  
> You can use lsusb to list the USB devices on the system: 
>  
> Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 003 Device 002: ID f617:0905 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
> Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra 
> Fast Media Reader 
> Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse 
>  
> To pass through the Logitec mouse, for instance, you could specify 
> 1.6 (remove leading zeroes). 
>  
> Note: USB hubs can not be assigned to guest. 
>  
> 3. PVUSB toolstack 
>  
> * Specify USB device in xl config file 
>  
> You can just specify usb devices, like: 
> usbdev=['1.6'] 
>  
> Then it will create a USB controller automatically and attach the USB 
> device to the first available USB controller:port. 
>  
> or, you can explicitly specify usb controllers and usb devices, like: 
> usbctrl=['verison=1, ports=4', 'version=2, ports=8', ] 
> usbdev=['1.6, controller=0, port=1'] 
>  
> Then it will create two USB controllers as you specified. 
> And if controller and port are specified in usb config, then it will 
> attach the USB device to that controller:port. About the controller 
> and port value: 
> Each USB controller has a index (or called devid) based on 0. The 1st 
> controller has index 0, the 2nd controller has index 1, ... 
> Under controller, each port has a port number based on 1. In above 
> configuration, the 1st controller will have port 1,2,3,4. 
>  
> * Hot-Plug USB device 
>  
> To attach a USB device, you should first create a USB controller. 
> e.g. 
> xl usb-ctrl-attach domain [version=1|2] [ports=value] 
> By default, it will create a USB2.0 controller with 8 

Re: [Xen-devel] [PATCH] libxl: Introduce a template for devices with a controller

[Chun Yan Liu]

>>> On 11/24/2015 at 10:40 PM, in message
<1448376011-20217-1-git-send-email-george.dun...@eu.citrix.com>, George Dunlap
<george.dun...@eu.citrix.com> wrote: 
> We have several outstanding patch series which add devices that have 
> two levels: a controller and individual devices attached to that 
> controller. 
>  
> In the interest of consistency, this patch introduces a section that 
> sketches out a template for interfaces for such devices.

Some typos. Otherwise, agreed.

- Chunyan
 
>  
> Signed-off-by: George Dunlap <george.dun...@citrix.com> 
> --- 
> CC: Ian Campbell <ian.campb...@citrix.com> 
> CC: Ian Jackson <ian.jack...@citrix.com> 
> CC: Wei Liu <wei.l...@citrix.com> 
> CC: Juergen Gross <jgr...@suse.com> 
> CC: Chun Yan Liu <cy...@suse.com> 
> CC: Olaf Hering <o...@aepfle.de> 
>  
> Changes in v1 (since the RFC): 
>  
> - Use  rather than , and  rather than specifying 
>   controller and device.  The idea being to allow SCSI to use 
>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun) 
>   rather than naming things after USB (controller & device). 
>  
> - Do not require each  to have a deviceid, but just a unique 
>   naming schema. 
>  
> - Allow multiple levels. 
>  
> - Include the paragraph about domain configuration lists. 
> --- 
>  tools/libxl/libxl.h | 65  
> + 
>  1 file changed, 65 insertions(+) 
>  
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> index 6b73848..46bcfe8 100644 
> --- a/tools/libxl/libxl.h 
> +++ b/tools/libxl/libxl.h 
> @@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int  
> nr_vtpms); 
>   * 
>   *   This function does not interact with the guest and therefore 
>   *   cannot block on the guest. 
> + * 
> + * Controllers 
> + * --- 
> + * 
> + * Most devices are treated individually.  Some classes of device, 
> + * however, like USB or SCSI, inherently have the need to have a 
> + * heiarchy of different levels, with lower-level devices "attached" 
> + * to higher-level ones.  USB for instance has "controllers" at the 
> + * top, which have busses, on which are devices, which consist of 
> + * multiple interfaces.  SCSI has "hosts" at the top, then busses, 
> + * targets, and LUNs. 
> + * 
> + * In that case, for each , there will be a set of funcitons

^^^ functions
> + * and types for each .  For example, for =usb, there 
> + * may be  ctrl (controller) and dev (device), with ctrl being 
> + * level 0. 
> + * 
> + * libxl_device__ will act more or 
> + * less like top-level non-bus devices: they will either create or 
> + * accept a libxl_devid which will be unique within the 
> + *  libxl_devid namespace. 
  ?
> + * 
> + * Lower-level devices must have a unique way to be identified.  One 
> + * way to do this would be to name it via the name of the next level 
> + * up plus an index; for instance, .  Another 
> + * way would be to have another devid namespace for that level.  This 
> + * identifier will be used for queries and removals. 
> + * 
> + * Lower-level devices will will include in their 
  ^ s/will will/will/
> + * libxl_device_ struct a field referring to the unique 
> + * index of the level above.  For instance, libxl_device_usbdev might 
> + * contain the controller devid. 
> + * 
> + * In the case where there are multiple different ways to implement a 
> + * given device -- for instance, one which is fully PV and one which 
> + * uses an emulator -- the controller will contain a field which 
> + * specifies what type of implementation is used.  The implementations 
> + * of individual devices will be known by the controller to which they 
> + * are attached. 
> + * 
> + * If libxl_device__add receives an empty reference to 
> + * the level above, it may return an error.  Or it may (but is not 
> + * required to) automatically choose a suitable device in the level 
> + * above to which to attach the new device at this level.  It may also 
> + * (but is not required to) automatically create a new device at the 
> + * level above if no suitable devices exist.  Each class should 
> + * document its behavior. 
> + * 
> + * libxl_device__list will list all devices of  
> + * at  in the domain.  For example, libxl_class_usbctrl_list 
  
libxl_device_usbctrl_list
> + * will list all usb controllers; libxl_class_usbdev_list will list 
  

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/18/2015 at 05:44 PM, in message <20151118094410.gb21...@aepfle.de>, 
>>> Olaf
Hering <o...@aepfle.de> wrote: 
> On Tue, Nov 17, Chun Yan Liu wrote: 
>  
> > I think libxl_device_usb doesn't need to be changed into  
> libxl_device_usbdev?  
>  
> In case of vscsi the struct and functions names are odd. It was not 
> obvious which one belongs to a ctrl and which one belongs to a device. 
> In the meantime I have changed everything related to a scsi host, it 
> contains now 'vscsictrl'. The names related to devices will follow. 
>  
> I suggest to do apply the same also to usb and make it clear what 
> belongs to a ctrl and what to a device. Havent checked your patch what 
> places that actually would be. 

Currently in pvusb patches, all places using 'usbctrl' means usb controller,
'usb' means usb device.

- Chunyan

>  
> Olaf 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/19/2015 at 09:33 AM, in message
<564d9761026600085...@relay2.provo.novell.com>, "Chun Yan Liu"
<cy...@suse.com> wrote: 

>  
>>>> On 11/18/2015 at 05:44 PM, in message <20151118094410.gb21...@aepfle.de>, 
>>>> Olaf 
> Hering <o...@aepfle.de> wrote:  
> > On Tue, Nov 17, Chun Yan Liu wrote:  
> >   
> > > I think libxl_device_usb doesn't need to be changed into   
> > libxl_device_usbdev?   

George & Olaf,

About the naming, can we get to a decision?
e.g.
* usb controller and everything related, using "usbctrl"
* usb device and everything related, using "usbdev" (?)
Currently in pvusb, almost everywhere referring to a usb device, we use "usb".
Like: libxl_device_usb, libxl_device_usb_add/remove, etc.

If we decide, I can update all together.

- Chunyan

> >   
> > In case of vscsi the struct and functions names are odd. It was not  
> > obvious which one belongs to a ctrl and which one belongs to a device.  
> > In the meantime I have changed everything related to a scsi host, it  
> > contains now 'vscsictrl'. The names related to devices will follow.  
> >   
> > I suggest to do apply the same also to usb and make it clear what  
> > belongs to a ctrl and what to a device. Havent checked your patch what  
> > places that actually would be.  
>  
> Currently in pvusb patches, all places using 'usbctrl' means usb controller, 
> 'usb' means usb device. 
>  
> - Chunyan 
>  
> >   
> > Olaf  
> >   
> > ___  
> > Xen-devel mailing list  
> > Xen-devel@lists.xen.org  
> > http://lists.xen.org/xen-devel  
> >   
> >   
>  
>  
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/16/2015 at 06:01 PM, in message <5649a988.7010...@citrix.com>, George
Dunlap  wrote: 
> On 13/11/15 11:19, Olaf Hering wrote: 
> > On Wed, Oct 21, Chunyan Liu wrote: 
> >  
> >> Add pvusb APIs, including: 
> >  
> >> @@ -635,6 +664,8 @@ libxl_domain_config = Struct("domain_config", [ 
> >>  ("pcidevs", Array(libxl_device_pci, "num_pcidevs")), 
> >>  ("rdms", Array(libxl_device_rdm, "num_rdms")), 
> >>  ("dtdevs", Array(libxl_device_dtdev, "num_dtdevs")), 
> >> +("usbctrls", Array(libxl_device_usbctrl, "num_usbctrls")), 
> >> +("usbs", Array(libxl_device_usb, "num_usbs")), 
> >  
> > Should that perhaps be "usbctrls" + "usbdevs" if the latter really 
> > represents a device below one of the "usbctrls"? I dont know if it does, 
> > just wondering. 
>  
> That seems like a reasonable suggestion. 

OK. I'll update "usbs" to "usbdevs".
I think libxl_device_usb doesn't need to be changed into libxl_device_usbdev? 

>  
>  -George 
>  
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/17/2015 at 02:06 AM, in message
<22090.6954.35639.703...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Thanks for your attention to my earlier mail.  I'll delete all the 
> comments where we agree :-). 
>  
> > > > > > +/* bind/unbind usb device interface */   
> > > > > > +static int unbind_usb_intf(libxl__gc *gc, char *intf, char 
> > > > > > **drvpath)   
>  
> > > > > > +{   
> > > ...  
> > > > > > +dp = libxl__zalloc(gc, PATH_MAX);   
> > > > > > +dp = realpath(spath, dp);   
> > > > >
> > > > > Why is this call to realpath needed ?  
> > > >   
> > > > In sysfs, /driver sometimes is a link, since we need to save the 
> > > > original  
>  
> > > > driver to xenstore, so need to get the realpath of the driver.  
> > >   
> > > I mean, why is the path with all the symlinks in it not suitable for  
> > > storage and later use ?  
> >  
> > The symlink might be "../../../../../../bus/usb/drivers/btusb", we 
> > couldn't save that to xenstore for later usage. 
>  
> So the real reason is simply that it is a relative path and we need an 
> absolute one, because a relative path is not useful ? 
>  
> OK, thanks for the explanation.  (I'm not sure whether this is 
> unobvious enough to warrant a comment, perhaps 
>  /* sysfs can produce relative paths */ 
> or something.) 
>  
> > > > > I think you probably do things in the wrong order here.  You should   
> > > > > write the old driver info to xenstore first, so that if the bind to   
> > > > > usbback fails, you have the old driver info.   
> > > >   
> > > > Perhaps not. Once we finished adding entries to xenstore, pvusb  
> > > > frontend/backend drivers will detect the change and do probe work, if  
> > > > USB device is still not bound to USBBACK, there might be error.  
> > >   
> > > What I mean is this:  
> > >   
> > > Is it not possible to write the original path to xenstore before doing  
> > > the unbind ?  Otherwise it seems like there could be error paths where  
> > > the original path is not recorded, the xenstore write fails, and then  
> > > the information about how to rebind to the original driver has been  
> > > lost.  
> >  
> > I see.  
>  
> Right.  Do you think this warrants a change to the code ? 
>  
> > > Does writing USBBACK_INFO_PATH"/%s/%s/driver_path" really trigger  
> > > usbback ?  
> >  
> > No, writing driver_path info to xenstore won't trigger usbback. Writing 
> > frontend/backend info will. 
>  
> Jolly good. 
>  
> > > > If we merge libxl__device_usb_add and do_usb_add, then it's cleaner.  
> > >   
> > > See my comment below.  You've explained the distinction to my  
> > > satisfaction.  
> > >   
> > > But, to solve the duplication of the controller info acquisition,  
> > > perhaps you could have do_usb_add take the controller info as a  
> > > paramaeter ? 
> >  
> > Yes, could be. Only do_usb_add and do_usb_remove parameters are not 
> > symmetrical.  
>  
> I don't think that matters.  (If it did it would be better to add an 
> unused parameter to the remove function.) 

Take all. Will update codes.

>  
> Regards, 
> Ian. 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/13/2015 at 01:27 AM, in message
, George
Dunlap  wrote: 
> On Wed, Oct 21, 2015 at 10:08 AM, Chunyan Liu  wrote: 
> > +static int 
> > +get_assigned_devices(libxl__gc *gc, 
> > + libxl_device_usb **list, int *num) 
> > +{ 
> > +char **domlist; 
> > +unsigned int nd = 0, i, j, k; 
> > +int rc; 
> > + 
> > +*list = NULL; 
> > +*num = 0; 
> > + 
> > +domlist = libxl__xs_directory(gc, XBT_NULL, "/local/domain", ); 
> > +for (i = 0; i < nd; i++) { 
> > +char *path, **ctrl_list; 
> > +unsigned int nc = 0; 
> > + 
> > +path = GCSPRINTF("/local/domain/%s/device/vusb", domlist[i]); 
> > +ctrl_list = libxl__xs_directory(gc, XBT_NULL, path, ); 
> > + 
> > +for (j = 0; j < nc; j++) { 
> > +const char *be_path, *num_ports; 
> > +int nport; 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +  GCSPRINTF("%s/%s/backend", path, ctrl_list[j]), 
> > +  _path); 
> > +if (rc) goto out; 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +GCSPRINTF("%s/num-ports", 
> > be_path), 
> > +_ports); 
> > +if (rc) goto out; 
> > + 
> > +nport = atoi(num_ports); 
> > +for (k = 0; k < nport; k++) { 
> > +libxl_device_usb *usb; 
> > +const char *portpath, *busid; 
> > + 
> > +portpath = GCSPRINTF("%s/port/%d", be_path, k + 1); 
> > +busid = libxl__xs_read(gc, XBT_NULL, portpath); 
> > +/* If there is USB device attached, add it to list */ 
> > +if (busid && strcmp(busid, "")) { 
> > +GCREALLOC_ARRAY(*list, *num + 1); 
> > +usb = *list + *num; 
> > +(*num)++; 
> > +libxl_device_usb_init(usb); 
> > +usb->ctrl = atoi(ctrl_list[j]); 
> > +usb->port = k + 1; 
> > +rc = usb_busaddr_from_busid(gc, busid, 
> > +>u.hostdev.hostbus, 
> > +>u.hostdev.hostaddr); 
>  
> You should probably set usb->devtype to HOSTDEV here, even though this 
> function is internal. 
>  
> > +if (rc) goto out; 
> > +} 
> > +} 
> > +} 
> > +} 
> > + 
> > +rc = 0; 
> > + 
> > +out: 
> > +if (rc) { 
> > +*list = NULL; 
> > +*num = 0; 
> > +} 
> > +return rc; 
> > +} 
> > + 
> > +static bool is_usbdev_in_array(libxl_device_usb *usbs, int num, 
> > +   libxl_device_usb *usb) 
> > +{ 
> > +int i; 
> > + 
> > +for (i = 0; i < num; i++) { 
> > +if (usbs[i].u.hostdev.hostbus == usb->u.hostdev.hostbus && 
> > +usbs[i].u.hostdev.hostaddr == usb->u.hostdev.hostaddr) 
> > +return true; 
> > +} 
> > + 
> > +return false; 
> > +} 
> > + 
> > +/* check if USB device is already assigned to a domain */ 
> > +/* check if USB device type is assignable */ 
> > +static bool is_usb_assignable(libxl__gc *gc, libxl_device_usb *usb) 
> > +{ 
> > +int classcode; 
> > +char *filename; 
> > +void *buf = NULL; 
> > +char *busid = NULL; 
> > + 
> > +busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus, 
> > + usb->u.hostdev.hostaddr); 
> > +if (!busid) return false; 
> > + 
> > +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/bDeviceClass", busid); 
> > +if (libxl__read_sysfs_file_contents(gc, filename, , NULL)) 
> > +return false; 
> > + 
> > +classcode = atoi(buf); 
> > +return classcode != USBHUB_CLASS_CODE; 
> > +} 
> > + 
> > +/* get usb devices under certain usb controller */ 
> > +static int 
> > +libxl__device_usb_list_for_usbctrl(libxl__gc *gc, uint32_t domid, 
> > +   libxl_devid usbctrl, 
> > +   libxl_device_usb **usbs, int *num) 
> > +{ 
> > +const char *fe_path, *be_path, *num_devs; 
> > +int n, i, rc; 
> > + 
> > +*usbs = NULL; 
> > +*num = 0; 
> > + 
> > +fe_path = GCSPRINTF("%s/device/vusb/%d", 
> > +libxl__xs_get_dompath(gc, domid), usbctrl); 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +GCSPRINTF("%s/backend", fe_path), 
> > +_path); 
> > +if (rc) return rc; 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +GCSPRINTF("%s/num-ports", be_path), 
> > +_devs); 
> > +if (rc) return rc; 
> > + 
> > +

Re: [Xen-devel] [PATCH V8 7/7] domcreate: support pvusb in configuration file

[Chun Yan Liu]

>>> On 11/13/2015 at 12:10 AM, in message
, George
Dunlap  wrote: 
> On Wed, Oct 21, 2015 at 10:08 AM, Chunyan Liu  wrote: 
> > Add code to support pvusb in domain config file. One could specify 
> > usbctrl and usb in domain's configuration file and create domain, 
> > then usb controllers will be created and usb device would be attached 
> > to guest automatically. 
> > 
> > One could specify usb controllers and usb devices in config file 
> > like this: 
> > usbctrl=['version=2,ports=4', 'version=1, ports=4', ] 
> > usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ] 
> > 
> > Signed-off-by: Chunyan Liu  
> > Signed-off-by: Simon Cao  
> > 
> > --- 
> > changes: 
> >   - change parse_usb_config and parse_usbctrl_config, following 
> > parse_nic_config way, and move to previous patch 
> >   - update user interface to specify hostbus, hostaddr instead of 
> > hostbus.hostaddr for future extension 
> > 
> >  docs/man/xl.cfg.pod.5| 81  
>  
> >  tools/libxl/libxl_create.c   | 73 +-- 
> >  tools/libxl/libxl_device.c   |  4 +++ 
> >  tools/libxl/libxl_internal.h |  8 + 
> >  tools/libxl/xl_cmdimpl.c | 54 - 
> >  5 files changed, 216 insertions(+), 4 deletions(-) 
> > 
> > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 
> > index b63846a..f24c008 100644 
> > --- a/docs/man/xl.cfg.pod.5 
> > +++ b/docs/man/xl.cfg.pod.5 
> > @@ -722,6 +722,87 @@ Note this may be overridden by rdm_policy option in 
> > PCI  
> device configuration. 
> > 
> >  =back 
> > 
> > +=item 

Re: [Xen-devel] [PATCH V8 5/7] xl: add pvusb commands

[Chun Yan Liu]

>>> On 11/12/2015 at 07:38 PM, in message

Re: [Xen-devel] [PATCH V8 5/7] xl: add pvusb commands

[Chun Yan Liu]

>>> On 11/12/2015 at 10:42 PM, in message <20151112144211.ga5...@aepfle.de>, 
>>> Olaf
Hering  wrote: 
> On Wed, Oct 21, Chunyan Liu wrote: 
>  
> > Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list, 
> > usb-attach and usb-detach. 
>  
> How is this supposed to be handled in libvirt? It looks like libvirt has 
> to copy what is done here. If thats true the logic should be in libxlu 
> so that both xl and libvirt can call the same functions.

For usbctrl-attach/detach, usb-attach/detach, libxl has API, like
libxl_device_usbctrl_add/remove, libxl_device_usb_add/remove. That's
could be used for libvirt usage. The user interface processing things
are always do-by-itslef for xl and libvirt, what's libvirt needs to do is
preparing the usbctrl/usb device structure and call libxl API to do the
work.

- Chunyan 
 
>  
> Olaf 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/12/2015 at 07:32 PM, in message <20151112113200.ga...@aepfle.de>, Olaf
Hering  wrote: 
> On Wed, Oct 21, Chunyan Liu wrote: 
>  
> > Add pvusb APIs, including: 
>  
> Some comments below. 
>  
> After a quick look I miss the proposed ctrl/device separation for pvscsi 
> (what handles "state" changes?). But, I have to read all the other 
> dozen+ threads about that topic first. 
>  
>  
> > +flexarray_append_pair(back, "state", "1"); 
>  
> 4.6+ has macros for "state" values, like 
> flexarray_append_pair(back, "state", GCSPRINTF("%d",  
> XenbusStateInitialising)); 
>  
>  
> > +flexarray_append_pair(front, "state", "1"); 
>  
> 4.6+ has macros for "state" values. 
>  
> > +LOG(DEBUG, "Adding new usb device to xenstore"); 
>  
> Which one? Perhaps print also details. 
>  
> > +LOG(DEBUG, "Removing USB device from xenstore"); 
>  
> Which one? Perhaps print also details. 
>  
> > +/* check if the USB interface is already bound to "usbbcak" */ 
>  
> Typo. 

Take all. Thanks Olaf!

- Chunyan

>  
>  
> Olaf 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/13/2015 at 01:00 AM, in message
<22084.50631.506663.212...@mariner.uk.xensource.com>, Ian Jackson
<ian.jack...@eu.citrix.com> wrote: 
> Chun Yan Liu writes ("Re: [PATCH V8 3/7] libxl: add pvusb API"): 
> > On 11/10/2015 at 02:11 AM, in message 
> > <22080.57829.461049.37...@mariner.uk.xensource.com>, Ian Jackson 
> > <ian.jack...@eu.citrix.com> wrote:  
> > > Chunyan Liu writes ("[PATCH V8 3/7] libxl: add pvusb API"):  
> > > > +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid,  
> > > > +   libxl_device_usbctrl *usbctrl,  
> > > > +   libxl__ao_device *aodev)  
> > > > +{  
> > >   
> > > Thanks for adjusting the error-handling patterns in these functions.  
> > > The new way is good, except that:  
> > >   
> > > > +out:  
> > > > +aodev->rc = rc;  
> > > > +if (rc) aodev->callback(egc, aodev);  
> > >   
> > > Here, rc is always set, and indeed the code would be wrong if it were  
> > > not.  So can you remove the conditional please ?  Ie:  
> >  
> > Reading the codes, libxl__wait_device_connection will call 
> > aodev->callback properly. 
>  
> Indeed.  So you need to call aodev->callback() iff you don't call 
> libxl__wait_device_connection.  But libxl__wait_device_connection is 
> called only on the success exit path which ends in `return', not in 
> `goto out'.  So: 
>  
> > So here, only if (rc != 0), that means 
> > error happens, then we need to call aodev->callback to end the 
> > process. (Refer to current libxl__device_disk_add, all current code 
> > does similar work.) So I think the code is not wrong (?) 
>  
> In the `goto out' path, rc is always set.  Writing `if (rc)' implies 
> that it might not be (or is allowed not to be), which is misleading.

I'm convinced your suggestion is better :-). I'll adjust codes.
 
>  
>  
> > > > +static int usb_busaddr_from_busid(libxl__gc *gc, const char *busid,  
> > > > +  uint8_t *bus, uint8_t *addr)  
> > > > +{  
> > > > +char *filename;  
> > > > +void *buf;  
> > > > +  
> > > > +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/busnum", busid);  
> > > > +if (!libxl__read_sysfs_file_contents(gc, filename, , NULL))  
> > > > +*bus = atoi((char *)buf);  
> > >   
> > > I don't think this cast (and the one for addr) are necessary ?  
> >  
> > Which cast? Here, we want to get a uint_8 value, but buf is a string, 
> > we need to do atoi. 
>  
> I mean that I think 
>  
>  +*bus = atoi(buf);  
>  
> would compile and be correct.  buf would be automatically converted 
> from void* to const char*.  It's better to avoid casts where they are 
> not needed, because casts will suppress compiler warnings. 

Yes, you're right. Thanks very much!

>  
> For example if someone wanted to have the buffer be an updated 
> parameter they might do this: 
>  
>   static int usb_busaddr_from_busid(libxl__gc *gc, const char *busid,  
> +   void **buf, 
> uint8_t *bus, uint8_t *addr) 
> -void *buf;  
>  
> and hope or expect the compiler to notice places where they had failed 
> to update the usage of buf.  With void **buf, 
>   atoi((char*)buf) 
> would compile and do a wrong thing whereas 
>   atoi(buf) 
> would produce a fatal warning. 
>  
> > > > +/* bind/unbind usb device interface */  
> > > > +static int unbind_usb_intf(libxl__gc *gc, char *intf, char **drvpath)  
> > > > +{  
> ... 
> > > > +dp = libxl__zalloc(gc, PATH_MAX);  
> > > > +dp = realpath(spath, dp);  
> > >   
> > > Why is this call to realpath needed ? 
> >  
> > In sysfs, /driver sometimes is a link, since we need to save the original 
> > driver to xenstore, so need to get the realpath of the driver. 
>  
> I mean, why is the path with all the symlinks in it not suitable for 
> storage and later use ? 

The symlink might be "../../../../../../bus/usb/drivers/btusb", we couldn't save
that to xenstore for later usage.

>  
>  
> > > > +static int usbback_dev_unassign(libxl__gc *gc, libxl_device_usb *usb)  
> > > > +{  
> > > ...  
> > > > +/* bind interface to its originial driver */  
> > > > +drvpath = libxl__xs_read(gc, XBT_NULL,  
&

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/10/2015 at 02:11 AM, in message
<22080.57829.461049.37...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Chunyan Liu writes ("[PATCH V8 3/7] libxl: add pvusb API"): 
> > 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 
>  
> Thanks for this. 
>  
>  
> I have reviewed it in detail (not just the ao handling aspects) and 
> (I'm afraid) produced a large number of comments, relating to style, 
> error handling, etc., as well as ao handling. 
>  
> Please let me know if anything I've said is unclear.  I've been rather 
> brief in my comments, rather than writing a paragraph for each one. 
> Thanks. 
>  
>  
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> > index dacfaae..a050e8b 100644 
> > --- a/tools/libxl/libxl.c 
> > +++ b/tools/libxl/libxl.c 
> > @@ -4218,11 +4218,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
> ... 
> > +/* Macro for defining device remove/destroy functions for usbctrl */ 
> > +/* Following functions are defined: 
> > + * libxl_device_usbctrl_remove 
> > + * libxl_device_usbctrl_destroy 
> > + */ 
> > + 
> > +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
>  
> As George has said, I would prefer to avoid committing this 
> duplication in-tree, even with a promise to de-duplicated it later. 
>  
>  
> > +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid, 
> > +   libxl_device_usbctrl *usbctrl, 
> > +   libxl__ao_device *aodev) 
> > +{ 
>  
> Thanks for adjusting the error-handling patterns in these functions. 
> The new way is good, except that: 
>  
> > +out: 
> > +aodev->rc = rc; 
> > +if (rc) aodev->callback(egc, aodev); 
>  
> Here, rc is always set, and indeed the code would be wrong if it were 
> not.  So can you remove the conditional please ?  Ie: 

Reading the codes, libxl__wait_device_connection will call aodev->callback
properly. So here, only if (rc != 0), that means error happens, then we need to
call aodev->callback to end the process. (Refer to current 
libxl__device_disk_add,
all current code does similar work.) So I think the code is not wrong (?)

>  
>   +   aodev->callback(egc, aodev); 
>  
> The same goes for: 
>  
> > +static int 
> > +libxl__device_usb_remove(libxl__gc *gc, uint32_t domid, libxl_device_usb  
> *usb); 
> ... 
>  
> > +/* Remove usb devices first */ 
> > +rc  = libxl__device_usb_list_for_usbctrl(gc, domid, usbctrl_devid, 
> > + , ); 
>  ^^ 
> While you're fixing other things, you could remove one of these space.s 
>  
> > +libxl_device_usbctrl * 
> > +libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num) 
> > +{ 
> ... 
> > +for (usbctrl = usbctrls; usbctrl < end; 
> > + usbctrl++, entry++, (*num)++) { 
>  
> I think this would be clearer if there were a line break at the first 
> semicolon too.  Ie, I like 
> for (A; B; C) { 
> or 
> for (A; 
>  B; 
>  C) { 
>  
> But I don't like very much 
> for (A; B; 
>  C) { 
> or 
> for (A; 
>  B; C) { 
>  
> > +#define READ_SUBPATH(path, subpath) ({  \ 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL,   \ 
> > +GCSPRINTF("%s/" subpath, path), \ 
> > +);  \ 
> > +if (rc) goto outerr;\ 
> > +(char *)tmp;\ 
> > +}) 
>  
> Thanks, I'm pleased with how you have done this. 
>  
> > +be_path = READ_SUBPATH(fe_path, "backend"); 
> > +usbctrl->backend_domid = atoi(READ_SUBPATH(fe_path,  
> "backend-id")); 
> > +usbctrl->version = atoi(READ_SUBPATH(be_path, "usb-ver")); 
> > +usbctrl->ports = atoi(READ_SUBPATH(be_path, "num-ports")); 
>  
> However, I have a question: 
>  
> Why do you use atoi here, but strtoul in libxl_device_usbctrl_getinfo ? 

Didn't care much about that. atoi and strtoul both work. Previously use aoti,
in libxl_device_usbctrl_getinfo, to keep consistent with other functions (like
libxl_device_disk_getinfo), use strtoul.

Will update and use the same.

>  
> > +int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t domid, 
> > +libxl_device_usbctrl *usbctrl, 
> > +libxl_usbctrlinfo *usbctrlinfo) 
> > +{ 
> ... 
> > +tmp = READ_SUBPATH(fe_path, "backend-id"); 
> > +usbctrlinfo->backend_id = tmp ? strtoul(tmp, NULL, 10) : -1; 
>  
> There are ten copies of this pattern with tmp and strtoul.  I really 
> think this needs to be refactored somehow.  Can you 

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/11/2015 at 01:57 AM, in message
<caflbxzzu9o7jhm6flvkzuvd4lnt1aecybsbs_eo__fr0yw_...@mail.gmail.com>, George
Dunlap <george.dun...@eu.citrix.com> wrote: 
> On Tue, Nov 10, 2015 at 8:41 AM, Chun Yan Liu <cy...@suse.com> wrote: 
> >> > +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid, 
> >> > +   libxl_device_usbctrl *usbctrl, 
> >> > +   libxl__ao_device *aodev) 
> >> > +{ 
> >> 
> >> Thanks for adjusting the error-handling patterns in these functions. 
> >> The new way is good, except that: 
> >> 
> >> > +out: 
> >> > +aodev->rc = rc; 
> >> > +if (rc) aodev->callback(egc, aodev); 
> >> 
> >> Here, rc is always set, and indeed the code would be wrong if it were 
> >> not.  So can you remove the conditional please ?  Ie: 
> > 
> > Reading the codes, libxl__wait_device_connection will call aodev->callback 
> > properly. So here, only if (rc != 0), that means error happens, then we  
> need to 
> > call aodev->callback to end the process. (Refer to current  
> libxl__device_disk_add, 
> > all current code does similar work.) So I think the code is not wrong (?) 
>  
> >> > +static int usb_busaddr_from_busid(libxl__gc *gc, const char *busid, 
> >> > +  uint8_t *bus, uint8_t *addr) 
> >> > +{ 
> >> > +char *filename; 
> >> > +void *buf; 
> >> > + 
> >> > +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/busnum", busid); 
> >> > +if (!libxl__read_sysfs_file_contents(gc, filename, , NULL)) 
> >> > +*bus = atoi((char *)buf); 
> >> 
> >> I don't think this cast (and the one for addr) are necessary ? 
> > 
> > Which cast? Here, we want to get a uint_8 value, but buf is a string, 
> > we need to do atoi. 
>  
> atoi() isn't a cast, it's a function call.  The cast is the (char *) bit. 
>  
> I think probably you could get away with declaring buf as (char *). 
>  should be converted to void** automatically without any warnings, 
> I think. 

It will report warning if declaring char *buf.

>  
> >> > +/* Encode usb interface so that it could be written to xenstore as a 
> >> > key. 
> >> > + * 
> >> > + * Since xenstore key cannot include '.' or ':', we'll change '.' to 
> >> > '_', 
> >> > + * change ':' to '-'. For example, 3-1:2.1 will be encoded to 3-1-2_1. 
> >> > + * This will be used to save original driver of USB device to xenstore. 
> >> > + */ 
> >> 
> >> What is the syntax of the incoming busid ?  Could it contain _ or - ? 
> >> You should perhaps spot them and reject if it does. 
> > 
> > The busid is in syntax like 3-1:2.1. It does contain '-'. But since we only 
> >  
> use 
> > the single direction, never decode back, so it won't harm. 
>  
> So the only potential problem is that 3-1:2, 3-1-2, 3:1-2, and 3:1:2 
> all collapse down to 3-1-2.  Is there any risk of something like that 
> happening?  (Ian: NB these are all read from sysfs.) 
>  
> Since this isn't really being read by anyone,  maybe it would be 
> better to replace ':' with another character, just to be safe.  It 
> could even be something like 'c' if no other punctuation is available.

OK. Will update.
 
>  
> >> > +/* Bind USB device to "usbback" driver. 
> >> > + * 
> >> > + * If there are many interfaces under USB device, check each interface, 
> >> > + * unbind from original driver and bind to "usbback" driver. 
> >> > + */ 
> >> > +static int usbback_dev_assign(libxl__gc *gc, libxl_device_usb *usb) 
> >> > +{ 
> >> ... 
> >> > +if (libxl__xs_write_checked(gc, XBT_NULL, path, drvpath) < 
> >> > 0)  
> { 
> >> > +LOG(WARN, "Write of %s to node %s failed", drvpath,  
> path); 
> >> > +} 
> >> 
> >> One of the advantages of libxl__xs_write_checked is that it logs 
> >> errors.  So you can leave that log message out. 
> >> 
> >> However, if the xs write fails, you should presumably stop, rather 
> >> than carrying on. 
> >> 
> >> I think you probably do things in the wrong order here.  You should 
> >> write the old driver info to xenstore first, so that if the bind to 
> >> usbback fails, you have the old driver info. 
>  
&

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/11/2015 at 02:11 AM, in message
<22082.13115.276320.572...@mariner.uk.xensource.com>, Ian Jackson
<ian.jack...@eu.citrix.com> wrote: 
> George Dunlap writes ("Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API"): 
> > On Tue, Nov 10, 2015 at 8:41 AM, Chun Yan Liu <cy...@suse.com> wrote: 
> > > Which cast? Here, we want to get a uint_8 value, but buf is a string, 
> > > we need to do atoi. 
> >  
> > atoi() isn't a cast, it's a function call.  The cast is the (char *) bit. 
> >  
> > I think probably you could get away with declaring buf as (char *). 
> >  should be converted to void** automatically without any warnings, 
> > I think. 
>  
> No, char** won't be automatically converted to void**.  But void* will 
> be automatically converted to char*. 

Yes, that's right.

>  
> (Will read the rest of this thread later, probably tomorrow.) 
>  
> Ian. 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

Ian & George, any comments?

>>> On 10/21/2015 at 05:08 PM, in message
<1445418510-19614-4-git-send-email-cy...@suse.com>, 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: Chunyan Liu  
> Signed-off-by: Simon Cao  
>  
> --- 
> changes: 
>   - update COMPARE_USB to compare ctrl and port 
>   - add check in usb_add/remove to disable non-Dom0 backend so that 
> not worring about codes which are effective on Dom0 but not 
> compatible on non-Dom0 backend. 
>   - define READ_SUBPATH macro within functions 
>   - do not initialize rc but give it value in each return case 
>   - libxl__strdup gc or NOGC update, internal function using gc, 
> external using NOGC. 
>   - address other comments from George and Ian J. 
>  
>  tools/libxl/Makefile |2 +- 
>  tools/libxl/libxl.c  |   53 ++ 
>  tools/libxl/libxl.h  |   74 ++ 
>  tools/libxl/libxl_device.c   |5 +- 
>  tools/libxl/libxl_internal.h |   18 + 
>  tools/libxl/libxl_osdeps.h   |   13 + 
>  tools/libxl/libxl_pvusb.c| 1451  
> ++ 
>  tools/libxl/libxl_types.idl  |   57 ++ 
>  tools/libxl/libxl_types_internal.idl |1 + 
>  tools/libxl/libxl_utils.c|   16 + 
>  tools/libxl/libxl_utils.h|5 + 
>  11 files changed, 1693 insertions(+), 2 deletions(-) 
>  create mode 100644 tools/libxl/libxl_pvusb.c 
>  
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile 
> index c5ecec1..ef9ccd3 100644 
> --- a/tools/libxl/Makefile 
> +++ b/tools/libxl/Makefile 
> @@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o  
> libxl_dm.o libxl_pci.o \ 
>   libxl_stream_read.o libxl_stream_write.o \ 
>   libxl_save_callout.o _libxl_save_msgs_callout.o \ 
>   libxl_qmp.o libxl_event.o libxl_fork.o \ 
> - libxl_dom_suspend.o $(LIBXL_OBJS-y) 
> + libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y) 
>  LIBXL_OBJS += libxl_genid.o 
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o 
>   
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> index dacfaae..a050e8b 100644 
> --- a/tools/libxl/libxl.c 
> +++ b/tools/libxl/libxl.c 
> @@ -4218,11 +4218,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
>   
>   
> / 
> **/ 
>   
> +/* Macro for defining device remove/destroy functions for usbctrl */ 
> +/* Follo:wing functions are defined: 
> + * libxl_device_usbctrl_remove 
> + * libxl_device_usbctrl_destroy 
> + */ 
> + 
> +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
> +int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
> +uint32_t domid, libxl_device_##type *type,  \ 
> +const libxl_asyncop_how *ao_how)\ 
> +{   \ 
> +AO_CREATE(ctx, domid, ao_how);  \ 
> +libxl__device *device;  \ 
> +libxl__ao_device *aodev;\ 
> +int rc; \ 
> +\ 
> +GCNEW(device);  \ 
> +rc = libxl__device_from_##type(gc, domid, type, device);\ 
> +if (rc != 0) goto out;  \ 
> +\ 
> +GCNEW(aodev);   \ 
> +libxl__prepare_ao_device(ao, aodev);\ 
> +aodev->action = LIBXL__DEVICE_ACTION_REMOVE;\ 
> +aodev->dev = device;\ 
> +aodev->callback = device_addrm_aocomplete;  \ 
> +aodev->force = f;   \ 
> +libxl__initiate_device_##type##_remove(egc, aodev); \ 
> +\ 
> +out:\ 
> +if (rc) return AO_CREATE_FAIL(rc);  \ 
> +return AO_INPROGRESS;   \ 
> +} 
> + 
> + 
> +DEFINE_DEVICE_REMOVE_EXT(usbctrl, remove, 0) 
> +DEFINE_DEVICE_REMOVE_EXT(usbctrl, destroy, 1) 
> + 
> +#undef 

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Chun Yan Liu]

On 10/13/2015 09:15 PM, George Dunlap wrote:

On 13/10/15 02:46, Chun Yan Liu wrote:


On 10/12/2015 09:46 PM, George Dunlap wrote:

On 12/10/15 08:19, Chun Yan Liu wrote:

+
+usbinfo->devnum = usb->u.hostdev.hostaddr;
+usbinfo->busnum = usb->u.hostdev.hostbus;
+
+busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus,
+ usb->u.hostdev.hostaddr);
+if (!busid) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idVendor", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
+sscanf(buf, "%" SCNx16, >idVendor);
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idProduct", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
+sscanf(buf, "%" SCNx16, >idProduct);
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/manufacturer", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, ,
) &&
+buflen > 0) {
+/* replace \n to \0 */
+if (((char *)buf)[buflen - 1] == '\n')
+((char *)buf)[buflen - 1] = '\0';
+usbinfo->manuf = libxl__strdup(NOGC, buf);
+   }
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/product", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, ,
) &&
+buflen > 0) {
+/* replace \n to \0 */
+if (((char *)buf)[buflen - 1] == '\n')
+((char *)buf)[buflen - 1] = '\0';
+usbinfo->prod = libxl__strdup(NOGC, buf);
+}

   Basically, starting here, we have information which won't be
available
if we're using a pvusb driver domain.
   This information is nice-to-have, but I don't think this
information is
directly relevant to libxl or xl; the funcitonality to get this
information is available from other libraries like libusb.  I'm
inclined
to say that if we want to have pvusb driver domains (and I think we
do),
we should just get rid of this information.

For command 'xl usb-list', those information should be reported to user.
Do you mean we could call libusb to get thoes information directly in
xl toolstack and get rid of this function?

I think we can keep the function, since every other device type has the
function XXX_getinfo. But here we could check backend_domid, for
backend=dom0, doing above work; for backend!=dom0 (e.g. pvusb
driver domain, no matter how, it should also be able to let users
getting
those information. Can add code  in future.)

Does xl need that information?  Can't the user get that information from
lsusb?

In any case, I can see why it would be *useful* to have in xl.  But
about having it in libxl, I think this question sort of goes along with
the question about the next patch -- whether libxl should be in the
business of providing general information about the USB devices it's
handling, or whether it should limit itself to doing what is absolutely
necessary to talk to usbback.

There's a part of me that sees the point of it: it's not actually that
much extra code (at least for Linux), and it makes it easy to add some
very useful features to xl.

On the other hand, it's not portable to other OSes.  At the moment of
course pvusb isn't portable either, but once we have qemu USB (providing
either emulated or PV usb) then I *think* most of the other
functionality will Just Work on any platform that can compile qemu
(incl. FreeBSD, NetBSD, ), won't it?  The code you're introducing here
would have to be re-implented for those platforms, and for every new
platform that wanted to include this functionality, wouldn't it?

So, about the portability problem, I think it's back to: do need to
update code to call libusb instead of reading sysfs now? Except
for this function, still have places reading sysfs to get hostbus,
hostaddr, vendorId, deviceId. Those are not portable for other
platform.

I realize I didn't give you very clear guidance; I guess I was hoping to
get an opinion from the tools maintainers.  Or perhaps, I was hoping to
let them be the "bad guys" and say, "You can't have this feature in
libxl", so I wouldn't have to. :-)

In the absence of guidance to the contrary, I suggest that patch series
should focus on getting the core pvusb functionality in, without the
extra usb-querying bits.  Then we can discuss a further series which
either adds the usb querying functionality to libxl, or implement it in
xl using libusb.

OK. Got it. Thanks.

-Chunyan



  -George




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 10/1/2015 at 01:55 AM, in message <560c2204.9030...@citrix.com>, George
Dunlap  wrote: 
> On 25/09/15 03:11, Chunyan Liu wrote: 
> > Add pvusb APIs, including: 
> >  - attach/detach (create/destroy) virtual usb controller. 
> >  - attach/detach usb device 
> >  - list usb controllers and usb devices 
> >  - get information of usb controller and usb device 
> >  - some other helper functions 
> >  
> > Signed-off-by: Chunyan Liu  
> > Signed-off-by: Simon Cao  
>  
> Hey Chunyan!  This looks pretty close to being ready to check in to me. 
>  
> There are four basic comments I have.  I'm keen to get this series in so 
> that we can start doing more collaborative improvement; so I'll give my 
> comments, and then talk about timing and a plan to get this in as 
> quikcly as possible at the bottom. 
>  
>  
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> > index aea4887..1e2c63e 100644 
> > --- a/tools/libxl/libxl.c 
> > +++ b/tools/libxl/libxl.c 
> > @@ -4192,11 +4192,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
> >   
> >   
> / 
> **/ 
> >   
> > +/* Macro for defining device remove/destroy functions for usbctrl */ 
> > +/* Following functions are defined: 
> > + * libxl_device_usbctrl_remove 
> > + * libxl_device_usbctrl_destroy 
> > + */ 
> > + 
> > +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
> > +int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
> > +uint32_t domid, libxl_device_##type *type,  \ 
> > +const libxl_asyncop_how *ao_how)\ 
> > +{   \ 
> > +AO_CREATE(ctx, domid, ao_how);  \ 
> > +libxl__device *device;  \ 
> > +libxl__ao_device *aodev;\ 
> > +int rc; \ 
> > +\ 
> > +GCNEW(device);  \ 
> > +rc = libxl__device_from_##type(gc, domid, type, device);\ 
> > +if (rc != 0) goto out;  \ 
> > +\ 
> > +GCNEW(aodev);   \ 
> > +libxl__prepare_ao_device(ao, aodev);\ 
> > +aodev->action = LIBXL__DEVICE_ACTION_REMOVE;\ 
> > +aodev->dev = device;\ 
> > +aodev->callback = device_addrm_aocomplete;  \ 
> > +aodev->force = f;   \ 
> > +libxl__initiate_device_##type##_remove(egc, aodev); \ 
>  
> So this seems to be exactly the same as DEFINE_DEVICE_REMOVE(), except 
> that you call libxl__initiate_device_usbctrl_remove() here rather than 
> libxl__initiate_device_remove(). 
>  
> It seems like it might be better to have a separate patch renaming 
> libxl__initiate_device_remove to libxl__initiate_device_generic_remove 
> (or something like that), and then add a parameter to the definition 
> above making it so that the definitions above pass in "generic". 
>  
> > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c 
> > index bee5ed5..935f25b 100644 
> > --- a/tools/libxl/libxl_device.c 
> > +++ b/tools/libxl/libxl_device.c 
> > @@ -676,6 +676,10 @@ 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) { 
> > +libxl__initiate_device_usbctrl_remove(egc, aodev); 
> > +continue; 
> > +} 
> >  libxl__initiate_device_remove(egc, aodev); 
>  
> I think this would probably be more clear if you did: 
>  
> if(dev->backend_kind == LIBXL__DEVICE_KIND_VUSB) 
>   libxl__initiate_device_usbctl_remove() 
> else 
>   libxl__initiate_device_remove() 
>  
> > @@ -3951,7 +3966,10 @@ static inline void  
> libxl__update_config_vtpm(libxl__gc *gc, 
> >  #define COMPARE_PCI(a, b) ((a)->func == (b)->func &&\ 
> > (a)->bus == (b)->bus &&  \ 
> > (a)->dev == (b)->dev) 
> > - 
> > +#define COMPARE_USB(a, b) ((a)->u.hostdev.hostbus == 
> > (b)->u.hostdev.hostbus && \ 
> > +   (a)->u.hostdev.hostaddr == 
> > (b)->u.hostdev.hostaddr) 
>  
> 

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 10/8/2015 at 10:41 PM, in message
<22038.32910.375958.407...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Chunyan Liu writes ("[PATCH V7 3/7] libxl: add pvusb API"): 
> > Add pvusb APIs, including: 
> ... 
>  
> > +/* Utility to read backend xenstore keys */ 
> > +#define READ_BACKEND(tgc, subpath)\ 
> > +libxl__xs_read(tgc, XBT_NULL, GCSPRINTF("%s/" subpath,  
> be_path)) 
> > + 
> > +/* Utility to read frontend xenstore keys */ 
> > +#define READ_FRONTEND(tgc, subpath)   \ 
> > +libxl__xs_read(tgc, XBT_NULL, GCSPRINTF("%s/" subpath,  
> fe_path)) 
> > + 
>  
> Thanks for trying to reduce repetition.  But I think these macros need 
> to be improved.  I'm am not particularly keen on them in this form, 
> for a number of reasons. 
>  
>  * They implicitly rely on variables (be_path and fe_path) being in 
>scope but there is no associated doc comment.  That would be OK if 
>they were macros defined within a single function and #undef'd 
>before the function end. 
>  
>  * Their functionality is not really usb-specific.  If this is a good 
>thing to do they should be in libxl_internal.h. 
>  
>  * They should use libxl__xs_read_checked.  That means they should 
>probably also implicitly assume that rc is in scope, and `goto out' 
>on error.  (There are many calls to libxl__xs_read here to which 
>the same observation applies.) 
>  
>  * I think there is no reason for these to take a `tgc' parameter. 
>All of the call sites pass exactly `gc'.  If these macros are going 
>to make assumptions about what's in their scope, `gc' is a very 
>good candidate (which many existing macros rely on). 
>  
> You can go two routes with this: make much more local macros, and 
> #undef them.  Or formalise these macros and widen their scope to the 
> whole of libxl.  I think the latter would probably be best. 

Sorry for replying late, the mail server were exchanged and had some
issues these days.

For the macro, I think maybe it's better to use local macros within function.
The macro itself doesn't do much work but a libxl__xs_read. Local macro
can have more flexibility, like can adding extra 'goto out' or error handling
or other repeated codes to the macro according to specific function.

> 
>
> Perhaps something like: 
>  
> /* 
>  * const char *READ_SUBPATH(const char *febe_path, const char *subpath); 
>  * 
>  * Expects in scope: 
>  *int rc; 
>  *libxl__gc *gc; 
>  *out: 
>  * 
>  * Reads febe_path/subpath from xenstore.  Does not use a transaction. 
>  * On xenstore errors, sets rc and does `goto out'. 
>  * If the path does not exist, returns NULL. 
>  */ 
> #define READ_SUBPATH(febe_path, subpath) ... 
>  
> What do you think ? 
>  
>  
> > +/* AO operation to add a usb controller. 
> > + * 
> > + * Generally, it does: 
> > + * 1) fill in necessary usb controler information with default value 
> > + * 2) write usb controller frontend/backend info to xenstore, update json 
> > + *config file if necessary. 
> > + * 3) wait for device connection. PVUSB frontend and backend driver will 
> > + *probe xenstore paths and build connection between frontend and  i
> backend. 
> > + */ 
> > +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid, 
> > +   libxl_device_usbctrl *usbctrl, 
> > +   libxl__ao_device *aodev) 
> > +{ 
> > +STATE_AO_GC(aodev->ao); 
> > +libxl__device *device; 
> > +int rc; 
> > + 
> > +rc = libxl__device_usbctrl_setdefault(gc, domid, usbctrl); 
> > +if (rc < 0) goto out; 
> > + 
> > +if (usbctrl->devid == -1) { 
> > +usbctrl->devid = libxl__device_nextid(gc, domid, "vusb"); 
> > +if (usbctrl->devid < 0) { 
> > +rc = ERROR_FAIL; 
> > +goto out; 
> > +} 
> > +} 
> > + 
> > +if (usbctrl->type != LIBXL_USBCTRL_TYPE_PV) { 
> > +LOG(ERROR, "Unsupported USB controller type"); 
> > +rc = ERROR_FAIL; 
> > +goto out; 
> > +} 
> > + 
> > +rc = libxl__device_usbctrl_add_xenstore(gc, domid, usbctrl, 
> > +aodev->update_json); 
> > +if (rc) goto out; 
> > + 
> > +GCNEW(device); 
> > +rc = libxl__device_from_usbctrl(gc, domid, usbctrl, device); 
> > +if (rc) goto out; 
> > + 
> > +aodev->dev = device; 
> > +aodev->action = LIBXL__DEVICE_ACTION_ADD; 
> > +libxl__wait_device_connection(egc, aodev); 
> > +rc = 0; 
> > + 
> > +out: 
> > +aodev->rc = rc; 
> > +if (rc) aodev->callback(egc, aodev); 
>  
> This is wrong (even though it works with the remaining code as it 
> stands), I'm afraid. 
>  
> The right pattern is to `return 0' after 
> libxl__wait_device_connection, because libxl__wait_device_connection 
> will always make a callback.

It's OK to 'return 0' directly fater 

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Chun Yan Liu]

On 10/12/2015 09:46 PM, George Dunlap wrote:

On 12/10/15 08:19, Chun Yan Liu wrote:

+
+usbinfo->devnum = usb->u.hostdev.hostaddr;
+usbinfo->busnum = usb->u.hostdev.hostbus;
+
+busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus,
+ usb->u.hostdev.hostaddr);
+if (!busid) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idVendor", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
+sscanf(buf, "%" SCNx16, >idVendor);
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/idProduct", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , NULL))
+sscanf(buf, "%" SCNx16, >idProduct);
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/manufacturer", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , ) &&
+buflen > 0) {
+/* replace \n to \0 */
+if (((char *)buf)[buflen - 1] == '\n')
+((char *)buf)[buflen - 1] = '\0';
+usbinfo->manuf = libxl__strdup(NOGC, buf);
+   }
+
+filename = GCSPRINTF(SYSFS_USB_DEV"/%s/product", busid);
+if (!libxl_read_sysfs_file_contents(ctx, filename, , ) &&
+buflen > 0) {
+/* replace \n to \0 */
+if (((char *)buf)[buflen - 1] == '\n')
+((char *)buf)[buflen - 1] = '\0';
+usbinfo->prod = libxl__strdup(NOGC, buf);
+}
  
Basically, starting here, we have information which won't be available

if we're using a pvusb driver domain.
  
This information is nice-to-have, but I don't think this information is

directly relevant to libxl or xl; the funcitonality to get this
information is available from other libraries like libusb.  I'm inclined
to say that if we want to have pvusb driver domains (and I think we do),
we should just get rid of this information.

For command 'xl usb-list', those information should be reported to user.
Do you mean we could call libusb to get thoes information directly in
xl toolstack and get rid of this function?

I think we can keep the function, since every other device type has the
function XXX_getinfo. But here we could check backend_domid, for
backend=dom0, doing above work; for backend!=dom0 (e.g. pvusb
driver domain, no matter how, it should also be able to let users getting
those information. Can add code  in future.)

Does xl need that information?  Can't the user get that information from
lsusb?

In any case, I can see why it would be *useful* to have in xl.  But
about having it in libxl, I think this question sort of goes along with
the question about the next patch -- whether libxl should be in the
business of providing general information about the USB devices it's
handling, or whether it should limit itself to doing what is absolutely
necessary to talk to usbback.

There's a part of me that sees the point of it: it's not actually that
much extra code (at least for Linux), and it makes it easy to add some
very useful features to xl.

On the other hand, it's not portable to other OSes.  At the moment of
course pvusb isn't portable either, but once we have qemu USB (providing
either emulated or PV usb) then I *think* most of the other
functionality will Just Work on any platform that can compile qemu
(incl. FreeBSD, NetBSD, ), won't it?  The code you're introducing here
would have to be re-implented for those platforms, and for every new
platform that wanted to include this functionality, wouldn't it?

So, about the portability problem, I think it's back to: do need to
update code to call libusb instead of reading sysfs now? Except
for this function, still have places reading sysfs to get hostbus,
hostaddr, vendorId, deviceId. Those are not portable for other
platform.

And about getting rid of the function, currently it's only needed in
'xl usb-list' and 'xl usb-assignable-list', if not providing general
information, yes, we can remove it.

-Chunyan



The libusb interface does look a bit clunky; it would certainly be more
convenient for developers to use the interface you've provided here.

  -George




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V7 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 10/1/2015 at 01:55 AM, in message <560c2204.9030...@citrix.com>, George
Dunlap  wrote: 
> On 25/09/15 03:11, Chunyan Liu wrote: 
> > Add pvusb APIs, including: 
> >  - attach/detach (create/destroy) virtual usb controller. 
> >  - attach/detach usb device 
> >  - list usb controllers and usb devices 
> >  - get information of usb controller and usb device 
> >  - some other helper functions 
> >  
> > Signed-off-by: Chunyan Liu  
> > Signed-off-by: Simon Cao  
>  
> Hey Chunyan!  This looks pretty close to being ready to check in to me. 
>  
> There are four basic comments I have.  I'm keen to get this series in so 
> that we can start doing more collaborative improvement; so I'll give my 
> comments, and then talk about timing and a plan to get this in as 
> quikcly as possible at the bottom. 
>  
>  
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> > index aea4887..1e2c63e 100644 
> > --- a/tools/libxl/libxl.c 
> > +++ b/tools/libxl/libxl.c 
> > @@ -4192,11 +4192,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
> >   
> >   
> / 
> **/ 
> >   
> > +/* Macro for defining device remove/destroy functions for usbctrl */ 
> > +/* Following functions are defined: 
> > + * libxl_device_usbctrl_remove 
> > + * libxl_device_usbctrl_destroy 
> > + */ 
> > + 
> > +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
> > +int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
> > +uint32_t domid, libxl_device_##type *type,  \ 
> > +const libxl_asyncop_how *ao_how)\ 
> > +{   \ 
> > +AO_CREATE(ctx, domid, ao_how);  \ 
> > +libxl__device *device;  \ 
> > +libxl__ao_device *aodev;\ 
> > +int rc; \ 
> > +\ 
> > +GCNEW(device);  \ 
> > +rc = libxl__device_from_##type(gc, domid, type, device);\ 
> > +if (rc != 0) goto out;  \ 
> > +\ 
> > +GCNEW(aodev);   \ 
> > +libxl__prepare_ao_device(ao, aodev);\ 
> > +aodev->action = LIBXL__DEVICE_ACTION_REMOVE;\ 
> > +aodev->dev = device;\ 
> > +aodev->callback = device_addrm_aocomplete;  \ 
> > +aodev->force = f;   \ 
> > +libxl__initiate_device_##type##_remove(egc, aodev); \ 
>  
> So this seems to be exactly the same as DEFINE_DEVICE_REMOVE(), except 
> that you call libxl__initiate_device_usbctrl_remove() here rather than 
> libxl__initiate_device_remove(). 
>  
> It seems like it might be better to have a separate patch renaming 
> libxl__initiate_device_remove to libxl__initiate_device_generic_remove 
> (or something like that), and then add a parameter to the definition 
> above making it so that the definitions above pass in "generic". 
>  
> > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c 
> > index bee5ed5..935f25b 100644 
> > --- a/tools/libxl/libxl_device.c 
> > +++ b/tools/libxl/libxl_device.c 
> > @@ -676,6 +676,10 @@ 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) { 
> > +libxl__initiate_device_usbctrl_remove(egc, aodev); 
> > +continue; 
> > +} 
> >  libxl__initiate_device_remove(egc, aodev); 
>  
> I think this would probably be more clear if you did: 
>  
> if(dev->backend_kind == LIBXL__DEVICE_KIND_VUSB) 
>   libxl__initiate_device_usbctl_remove() 
> else 
>   libxl__initiate_device_remove() 
>  
> > @@ -3951,7 +3966,10 @@ static inline void  
> libxl__update_config_vtpm(libxl__gc *gc, 
> >  #define COMPARE_PCI(a, b) ((a)->func == (b)->func &&\ 
> > (a)->bus == (b)->bus &&  \ 
> > (a)->dev == (b)->dev) 
> > - 
> > +#define COMPARE_USB(a, b) ((a)->u.hostdev.hostbus == 
> > (b)->u.hostdev.hostbus && \ 
> > +   (a)->u.hostdev.hostaddr == 
> > (b)->u.hostdev.hostaddr) 
>  
> 

Re: [Xen-devel] [PATCH V7 5/7] xl: add pvusb commands

[Chun Yan Liu]

>>> On 10/2/2015 at 01:02 AM, in message <560d6733.4030...@citrix.com>, George
Dunlap  wrote: 
> On 25/09/15 03:11, Chunyan Liu wrote: 
> > Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list, 
> > usb-attach and usb-detach. 
> >  
> > To attach a usb device to guest through pvusb, one could follow 
> > following example: 
> >  
> >  #xl usb-ctrl-attach test_vm version=1 num_ports=8 
>  
> So all the way back in v2 of this series, I suggested making the 
> arguments for usb-ctrl-attach and usb-attach mirror the format that is 
> found in the config file[1], at which point you replied "That could be, 
> I can update".  But you didn't change the interface in v3, so I 
> suggested it again[2], and there was no argument or discussion about it. 
>  
> (There was a long back-and-forth with Juergen at that point about 
> usb-assignable-list, so [2] may have gotten lost in the noise.) 
>  
> I still think that's the best interface to use.  Do you have reasons to 
> favor the interface you propose here?

Sorry for replying late, just back from holiday.

It's my fault not updating it, missing that after a lot of other changes, not
favor this or that. Thanks for reminding again.

- Chunyan

>  
>  -George 
>  
> [1] 
> marc.info/?i=  
>om> 
>  
> [2] 
> marc.info/?i= com> 
>  
> >  
> >  #xl usb-list test_vm 
> >  will show the usb controllers and port usage under the domain. 
> >  
> >  #xl usb-attach test_vm 1.6 
> >  will find the first usable controller:port, and attach usb 
> >  device whose bus address is 1.6 (busnum is 1, devnum is 6) 
> >  to it. One could also specify which  and which . 
> >  
> >  #xl usb-detach test_vm 0 1 
> >  will detach USB device under controller 0 port 1. 
> >  
> >  #xl usb-ctrl-detach test_vm dev_id 
> >  will destroy the controller with specified dev_id. Dev_id 
> >  can be traced in usb-list info. 
> >  
> > Signed-off-by: Chunyan Liu  
> > Signed-off-by: Simon Cao  
> > --- 
> >  docs/man/xl.pod.1 |  40  
> >  tools/libxl/xl.h  |   5 + 
> >  tools/libxl/xl_cmdimpl.c  | 232  
> ++ 
> >  tools/libxl/xl_cmdtable.c |  25 + 
> >  4 files changed, 302 insertions(+) 
> >  
> > diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 
> > index f22c3f3..4c92c78 100644 
> > --- a/docs/man/xl.pod.1 
> > +++ b/docs/man/xl.pod.1 
> > @@ -1345,6 +1345,46 @@ List pass-through pci devices for a domain. 
> >   
> >  =back 
> >   
> > +=head1 USB PASS-THROUGH 
> > + 
> > +=over 4 
> > + 
> > +=item B I 

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 9/9/2015 at 12:52 AM, in message <55ef1244@citrix.com>, George Dunlap
 wrote: 
> On 09/08/2015 03:17 PM, Ian Campbell wrote: 
> > On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: 
> >  
> > Sorry for the delay, between 4.6 freeze crunch, conference and vacation 
> > I've been a bit swamped. 
> >  
> > I'm just going to comment on the APIs (mainly public libxl.h and .idl) in 
> > this pass. 
> >  
> >> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> >> index 5f9047c..05b6331 100644 
> >> --- a/tools/libxl/libxl.h 
> >> +++ b/tools/libxl/libxl.h 
> >> @@ -123,6 +123,23 @@ 
> >>  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1 
> >>   
> >>  /* 
> >> + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of 
> >  
> > And cold-plug, no? 
>  
> So you should probably say something like "indicates functions for 
> plugging in USB devices through pvusb -- both hotplug and at domain 
> creation time." 
>  
> >> +libxl_usbctrl_type = Enumeration("usbctrl_type", [ 
> >> +(0, "AUTO"), 
> >  
> > What are the proposed semantics of using LIBXL_USBCTRL_TYPE_AUTO? 
>  
> Generally "DTRT".  Meaning: 
> 1. If your domain has no devicemodel, use PV. 
> 2. If your device has a devicemodel, and no PV drivers have peen 
> detected, use the devicemodel. 
> 3. If your device has a devicemodel, but PV drivers have been detected, 
> use PV. 
>  
> At the moment we don't have a way to check for PV drivers, so this just 
> collapses down to "PV for domains without a DM and DM for domains with a 
> DM." 
>  
> >  
> >> +(1, "PV"), 
> >> +(2, "QEMU"), 
> >  
> > Is "QEMU" what we want here, as opposed to, say, "EMU" (similar to NICs)? 
>  
> I had this as "DEVICEMODEL", since what we mean is that we want the 
> device model to provide access (and in theory in the future we may use a 
> different device model).  But "EMU" works for me too. 
>  
> > I think we probably don't want to go as fine grained as "XHCI" and "EHCI" 
> > etc, do we? I see we have a version field below, is it intended that there 
> > be some way to select between e.g. UHCI and OHCI (which IIRC are different 
> > USB 1.0 controllers). 
> >  
> > Maybe these questions should all be left aside for when QMEU support is 
> > actually added (AFAICT this field is just a placeholder)? In fact I glanced 
> > at the code and was surprised to find nothing checking for 
> > LIBXL_USBCTRL_TYPE at all, did I miss something? 
> >  
> > I think the two choices are: 
> >  
> > We can decide quickly and easily what the option(s) other than PV should be 
> > here and you include it in the IDL, but you would then need to check 
> > usbctrl->type == PV at various points, not silently treat all options as 
> > PV. 
> >  
> > Or this becomes a long conversation in which case I think your best bet 
> > would be to leave the enum with just the PV (and maybe AUTO) entries and 
> > leave the decision on the name for the emulated option to the series which 
> > implements that. 
>  
> I think the idea was to simply offer 1, 2, and 3 as options, and for the 
> devicemodel version, choose a suitable controller (or set of 
> controllers) for each option; similar to what usbversion= does now.

 
Hi, George,

I'm still confused about the expected look concerning PV/EMU type handling in
this patch series.

In earlier version, we tried to extract common things in libxl_usb.c and put
pvusb specific thing in libxl_pvusb.c, prefixed with pvusb_xxx. As you
suggested, we can leave that when EMU USB patch series added.

Now, about how to handle PV/EMU type in this patch series, I can think of 3 
ways:

1. We define the enumeration (contains PV/AUTO only, user interface only allows
'pv' or 'not specified', so we handle everything in 'pv' way without further 
check. Leave check and other adjusting things when EMU USB patch series added.

2. We check domain type and set proper type if not specified (i.e. 'pv' for PV 
guest, 'emu' for HVM guest). In add/remove function, check if type='emu', 
report  
'not supported' directly; otherwise, continue do following things. When EMU USB
patch serires added, need to extract common things and adjust the check place.

3. Same as 2, but extract common things, only in PV/EMU USB specific part, check
type, if type='emu', report 'not supported'; otherwise, do pvusb work. When 
adding EMU USB patch series, only need to add EMU USB specific things in the
type='emu' branch.

Which one is expected? Or none?

- Chunyan

>  
> >  
> >> +]) 
> >> + 
> >> +libxl_usbdev_type = Enumeration("usbdev_type", [ 
> >> +(0, "invalid"), 
> >> +(1, "hostdev"), 
> >> +]) 
> >> + 
> >> +libxl_device_usbctrl = Struct("device_usbctrl", [ 
> >> +("type", libxl_usbctrl_type), 
> >> +("devid", libxl_devid), 
> >> +("version", integer), 
> >> +("ports", integer), 
> >> +("backend_domid", libxl_domid), 
> >> +("backend_domname", string), 
> >> +   ]) 
> >> + 
> >> +libxl_device_usb = 

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 9/9/2015 at 12:52 AM, in message <55ef1244@citrix.com>, George Dunlap
 wrote: 
> On 09/08/2015 03:17 PM, Ian Campbell wrote: 
> > On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: 
> >  
> > Sorry for the delay, between 4.6 freeze crunch, conference and vacation 
> > I've been a bit swamped. 
> >  
> > I'm just going to comment on the APIs (mainly public libxl.h and .idl) in 
> > this pass. 
> >  
> >> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> >> index 5f9047c..05b6331 100644 
> >> --- a/tools/libxl/libxl.h 
> >> +++ b/tools/libxl/libxl.h 
> >> @@ -123,6 +123,23 @@ 
> >>  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1 
> >>   
> >>  /* 
> >> + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of 
> >  
> > And cold-plug, no? 
>  
> So you should probably say something like "indicates functions for 
> plugging in USB devices through pvusb -- both hotplug and at domain 
> creation time." 
>  
> >> +libxl_usbctrl_type = Enumeration("usbctrl_type", [ 
> >> +(0, "AUTO"), 
> >  
> > What are the proposed semantics of using LIBXL_USBCTRL_TYPE_AUTO? 
>  
> Generally "DTRT".  Meaning: 
> 1. If your domain has no devicemodel, use PV. 
> 2. If your device has a devicemodel, and no PV drivers have peen 
> detected, use the devicemodel. 
> 3. If your device has a devicemodel, but PV drivers have been detected, 
> use PV. 
>  
> At the moment we don't have a way to check for PV drivers, so this just 
> collapses down to "PV for domains without a DM and DM for domains with a 
> DM." 
>  
> >  
> >> +(1, "PV"), 
> >> +(2, "QEMU"), 
> >  
> > Is "QEMU" what we want here, as opposed to, say, "EMU" (similar to NICs)? 
>  
> I had this as "DEVICEMODEL", since what we mean is that we want the 
> device model to provide access (and in theory in the future we may use a 
> different device model).  But "EMU" works for me too. 
>  
> > I think we probably don't want to go as fine grained as "XHCI" and "EHCI" 
> > etc, do we? I see we have a version field below, is it intended that there 
> > be some way to select between e.g. UHCI and OHCI (which IIRC are different 
> > USB 1.0 controllers). 
> >  
> > Maybe these questions should all be left aside for when QMEU support is 
> > actually added (AFAICT this field is just a placeholder)? In fact I glanced 
> > at the code and was surprised to find nothing checking for 
> > LIBXL_USBCTRL_TYPE at all, did I miss something? 
> >  
> > I think the two choices are: 
> >  
> > We can decide quickly and easily what the option(s) other than PV should be 
> > here and you include it in the IDL, but you would then need to check 
> > usbctrl->type == PV at various points, not silently treat all options as 
> > PV. 
> >  
> > Or this becomes a long conversation in which case I think your best bet 
> > would be to leave the enum with just the PV (and maybe AUTO) entries and 
> > leave the decision on the name for the emulated option to the series which 
> > implements that. 
>  
> I think the idea was to simply offer 1, 2, and 3 as options, and for the 
> devicemodel version, choose a suitable controller (or set of 
> controllers) for each option; similar to what usbversion= does now.

 
Hi, George,

I'm still confused about the expected look concerning PV/EMU type handling in
this patch series.

In earlier version, we tried to extract common things in libxl_usb.c and put
pvusb specific thing in libxl_pvusb.c, prefixed with pvusb_xxx. As you
suggested, we can leave that when EMU USB patch series added.

Now, about how to handle PV/EMU type in this patch series, I can think of 3 
ways:

1. We define the enumeration (contains PV/AUTO only, user interface only allows
'pv' or 'not specified', so we handle everything in 'pv' way without further 
check. Leave check and other adjusting things when EMU USB patch series added.

2. We check domain type and set proper type if not specified (i.e. 'pv' for PV 
guest, 'emu' for HVM guest). In add/remove function, check if type='emu', 
report  
'not supported' directly; otherwise, continue do following things. When EMU USB
patch serires added, need to extract common things and adjust the check place.

3. Same as 2, but extract common things, only in PV/EMU USB specific part, check
type, if type='emu', report 'not supported'; otherwise, do pvusb work. When 
adding EMU USB patch series, only need to add EMU USB specific things in the
type='emu' branch.

Which one is expected? Or none?

- Chunyan

>  
> >  
> >> +]) 
> >> + 
> >> +libxl_usbdev_type = Enumeration("usbdev_type", [ 
> >> +(0, "invalid"), 
> >> +(1, "hostdev"), 
> >> +]) 
> >> + 
> >> +libxl_device_usbctrl = Struct("device_usbctrl", [ 
> >> +("type", libxl_usbctrl_type), 
> >> +("devid", libxl_devid), 
> >> +("version", integer), 
> >> +("ports", integer), 
> >> +("backend_domid", libxl_domid), 
> >> +("backend_domname", string), 
> >> +   ]) 
> >> + 
> >> +libxl_device_usb = 

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 9/14/2015 at 10:03 PM, in message
, George
Dunlap  wrote: 
> On Mon, Sep 14, 2015 at 12:12 PM, Ian Jackson   
> wrote: 
> > Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb  
> API"): 
> >> On 09/14/2015 12:36 PM, George Dunlap wrote: 
> >> > Anyone want to look into the Linux source code to find out how big it 
> >> > will allow busnum / devnum to grow? 
> >> 
> >> drivers/usb/core/hcd.c is using a bitmap to find the next bus number 
> >> currently not in use. It's size is USB_MAXBUS which in turn has the 
> >> value 64. 
> >> 
> >> choose_devnum() in drivers/usb/core/hub.c is doing a similar job for 
> >> device numbers. Here the highest number supported is 127. 
> > 
> > We are defining an API, which shouldn't involve this kind of 
> > implementation-grobbling. 
> > 
> > At an API level, it seems that this Linux busnum is not documented to 
> > have any particular number or behaviour or range or anything.  We 
> > should use the biggest type we can use conveniently 
> > 
> > Do we need to worry that some bus might have 2^24 unplugs/plugs 
> > (perhaps in some kind of software emulation) and that we need to use a 
> > type which can hold a uint32_t or maybe even a uint64_t ? 
>  
> libusb is already a published API that supports uint8, or up to 255. 
> Following their lead seems like a reasonable thing to do.  If ever 
> that number goes above 255, basically every Linux program that touches 
> a USB device will need to be recompiled with a new version of libusb. 
>  
> Is there any reason for Linux to go above 255?  Things I can think of: 
>  
> 1. Users have more than 255 devices plugged into the same bus. 
>  
> 2. A security / confusion issue due to devnum reuse when users plug 
> and unplug devices hundreds of times. 
>  
> Both of these seem pretty unlikely. 
>  
> I would personally go with uint8, but int16 or int32 certainly won't hurt. 

So can we agree to use uint8 for hostbus and hostaddr as libusb does?

>  
>  -George 
>  
> ___ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 9/11/2015 at 09:26 PM, in message <1441978018.3549.33.ca...@citrix.com>, 
>>> Ian
Campbell <ian.campb...@citrix.com> wrote: 
> On Thu, 2015-09-10 at 23:42 -0600, Chun Yan Liu wrote: 
> >  
> > > Do these fields have any particular size requirements arising from e.g.  
> the  
> > > USB spec or from possible dom0 implementations?  
> > >   
> > > If they have a well defined fixed size from a USB spec then maybe we 
> > > could  
> > > use the appropriate fixed size types?  
> >  
> > Di> dn't see the size limitation. In Linux kernel code, busnum and devnum  
> (here 
> > 'hostbus, hostaddr') are both 'int' type. 
>  
> Is that a Linux-specific implementation detail or a fundamental property of 
> USB? We should be designing the interface around Linux implementation 
> details. It seems like something in the USB spec ought to define precisely 
> the number of bits in both a bus number and a device address within that 
> bus. 

Have a look at USB 2.0 Spec, it has some description on Device Address: a 
seven-bit
value representing the address of the debvice on USB. (up to 127 devices). So 
 int8 is appropriate.
No description to Bus Num.

-Chunyan
>  
> >  And idProduct and idVendor are 'u16'. 
>  
> That's a USB spec thing, I think, so int16 in the IDL seems appropriate. 
>  
> Ian. 
>  
>  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 9/8/2015 at 10:17 PM, in message <1441721852.24450.120.ca...@citrix.com>,
Ian Campbell  wrote: 
> On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: 
>  
> Sorry for the delay, between 4.6 freeze crunch, conference and vacation 
> I've been a bit swamped. 
>  
> I'm just going to comment on the APIs (mainly public libxl.h and .idl) in 
> this pass. 
>  
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> > index 5f9047c..05b6331 100644 
> > --- a/tools/libxl/libxl.h 
> > +++ b/tools/libxl/libxl.h 
> > @@ -123,6 +123,23 @@ 
> >  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1 
> >   
> >  /* 
> > + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of 
>  
> And cold-plug, no? 
>  
> > + * USB devices through pvusb. 
> > + * 
> > + * With this functionality, one can add/remove USB controllers to/from 
> > + * guest, and attach/detach USB devices to/from USB controllers. To add 
> > + * USB controllers and USB devices, one can either adding USB controllers 
> > + * first and then attaching USB devices to some USB controller, or adding 
> > + * USB devices to guest directly, it will automatically create a USB 
> > + * controller for USB devices to attach. To remove USB controllers or USB 
> > + * devices, one can either remove USB devices under USB controller one by 
> > + * one and then remove USB controller, or remove USB controller directly, 
> > + * it will remove all USB devices under it automatically. 
>  
> I think this API documentation belongs alongside the API declarations (i.e 
> the prototypes) rather than hidden away next to the feature flag. 
>  
> > + * 
> > + */ 
> > +#define LIBXL_HAVE_PVUSB 1 
> > + 
> > +/* 
> >   * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the 
> >   * libxl_vendor_device field is present in the hvm sections of 
> >   * libxl_domain_build_info. This field tells libxl which 
> > @@ -1389,6 +1406,54 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t 
> > domid, libxl_device_disk *disk, 
> > const libxl_asyncop_how *ao_how) 
> > LIBXL_EXTERNAL_CALLERS_ONLY; 
> >   
> > +/* USB Controllers*/ 
> >  
> [] 
>  
> Seem fine. 
>  
> > + 
> > +/* USB Devices */ 
> > +int libxl_device_usb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_usb  
> *usb, 
> > + const libxl_asyncop_how *ao_how) 
> > + LIBXL_EXTERNAL_CALLERS_ONLY; 
> > + 
> > +int libxl_device_usb_remove(libxl_ctx *ctx, uint32_t domid,  
> libxl_device_usb *usb, 
> > +const libxl_asyncop_how *ao_how) 
> > +LIBXL_EXTERNAL_CALLERS_ONLY; 
> > + 
> > +libxl_device_usb * 
> > +libxl_device_usb_list(libxl_ctx *ctx, uint32_t domid, int *num); 
> > + 
> > +libxl_device_usb * 
> > +libxl_device_usb_list_per_usbctrl(libxl_ctx *ctx, uint32_t domid, 
> > +  libxl_devid usbctrl, int *num); 
>  
> I'd probably say "..._for_usbctrl" or "..._by_usbctrl", but that's just 
> nitpicking. 
>  
> > + 
> > +void libxl_device_usb_list_free(libxl_device_usb *list, int nr); 
> > + 
> > +int libxl_device_usb_getinfo(libxl_ctx *ctx, uint32_t domid, 
> > + libxl_device_usb *usb, 
> > + libxl_usbinfo *usbinfo); 
> > + 
> >  /* Network Interfaces */ 
> >  int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, 
> > libxl_device_nic *nic, 
> >   const libxl_asyncop_how *ao_how) 
> [...] 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl 
> > index ef346e7..ef10484 100644 
> > --- a/tools/libxl/libxl_types.idl 
> > +++ b/tools/libxl/libxl_types.idl 
> > @@ -594,6 +594,37 @@ libxl_device_rdm = Struct("device_rdm", [ 
> >  ("policy", libxl_rdm_reserve_policy), 
> >  ]) 
> >   
> > +libxl_usbctrl_type = Enumeration("usbctrl_type", [ 
> > +(0, "AUTO"), 
>  
> What are the proposed semantics of using LIBXL_USBCTRL_TYPE_AUTO? 
>  
> > +(1, "PV"), 
> > +(2, "QEMU"), 
>  
> Is "QEMU" what we want here, as opposed to, say, "EMU" (similar to NICs)? 
>  
> I think we probably don't want to go as fine grained as "XHCI" and "EHCI" 
> etc, do we? I see we have a version field below, is it intended that there 
> be some way to select between e.g. UHCI and OHCI (which IIRC are different 
> USB 1.0 controllers). 
>  
> Maybe these questions should all be left aside for when QMEU support is 
> actually added (AFAICT this field is just a placeholder)? In fact I glanced 
> at the code and was surprised to find nothing checking for 
> LIBXL_USBCTRL_TYPE at all, did I miss something? 
>  
> I think the two choices are: 
>  
> We can decide quickly and easily what the option(s) other than PV should be 
> here and you include it in the IDL, but you would then need to check 
> usbctrl->type == PV at various points, not silently treat all options as 
> PV. 
>  
> Or this becomes a long conversation in which 

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 9/9/2015 at 12:52 AM, in message <55ef1244@citrix.com>, George Dunlap
 wrote: 
> On 09/08/2015 03:17 PM, Ian Campbell wrote: 
> > On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: 
> >  
> > Sorry for the delay, between 4.6 freeze crunch, conference and vacation 
> > I've been a bit swamped. 
> >  
> > I'm just going to comment on the APIs (mainly public libxl.h and .idl) in 
> > this pass. 
> >  
> >> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> >> index 5f9047c..05b6331 100644 
> >> --- a/tools/libxl/libxl.h 
> >> +++ b/tools/libxl/libxl.h 
> >> @@ -123,6 +123,23 @@ 
> >>  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1 
> >>   
> >>  /* 
> >> + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of 
> >  
> > And cold-plug, no? 
>  
> So you should probably say something like "indicates functions for 
> plugging in USB devices through pvusb -- both hotplug and at domain 
> creation time." 

Thanks. Will clarify.

>  
> >> +libxl_usbctrl_type = Enumeration("usbctrl_type", [ 
> >> +(0, "AUTO"), 
> >  
> > What are the proposed semantics of using LIBXL_USBCTRL_TYPE_AUTO? 
>  
> Generally "DTRT".  Meaning: 
> 1. If your domain has no devicemodel, use PV. 
> 2. If your device has a devicemodel, and no PV drivers have peen 
> detected, use the devicemodel. 
> 3. If your device has a devicemodel, but PV drivers have been detected, 
> use PV. 
>  
> At the moment we don't have a way to check for PV drivers, so this just 
> collapses down to "PV for domains without a DM and DM for domains with a 
> DM." 

Better to be: by default, PV for PV guest and DM for HVM guest.

Thanks,
Chunyan

>  
> >  
> >> +(1, "PV"), 
> >> +(2, "QEMU"), 
> >  
> > Is "QEMU" what we want here, as opposed to, say, "EMU" (similar to NICs)? 
>  
> I had this as "DEVICEMODEL", since what we mean is that we want the 
> device model to provide access (and in theory in the future we may use a 
> different device model).  But "EMU" works for me too. 
>  
> > I think we probably don't want to go as fine grained as "XHCI" and "EHCI" 
> > etc, do we? I see we have a version field below, is it intended that there 
> > be some way to select between e.g. UHCI and OHCI (which IIRC are different 
> > USB 1.0 controllers). 
> >  
> > Maybe these questions should all be left aside for when QMEU support is 
> > actually added (AFAICT this field is just a placeholder)? In fact I glanced 
> > at the code and was surprised to find nothing checking for 
> > LIBXL_USBCTRL_TYPE at all, did I miss something? 
> >  
> > I think the two choices are: 
> >  
> > We can decide quickly and easily what the option(s) other than PV should be 
> > here and you include it in the IDL, but you would then need to check 
> > usbctrl->type == PV at various points, not silently treat all options as 
> > PV. 
> >  
> > Or this becomes a long conversation in which case I think your best bet 
> > would be to leave the enum with just the PV (and maybe AUTO) entries and 
> > leave the decision on the name for the emulated option to the series which 
> > implements that. 
>  
> I think the idea was to simply offer 1, 2, and 3 as options, and for the 
> devicemodel version, choose a suitable controller (or set of 
> controllers) for each option; similar to what usbversion= does now. 
>  
> >  
> >> +]) 
> >> + 
> >> +libxl_usbdev_type = Enumeration("usbdev_type", [ 
> >> +(0, "invalid"), 
> >> +(1, "hostdev"), 
> >> +]) 
> >> + 
> >> +libxl_device_usbctrl = Struct("device_usbctrl", [ 
> >> +("type", libxl_usbctrl_type), 
> >> +("devid", libxl_devid), 
> >> +("version", integer), 
> >> +("ports", integer), 
> >> +("backend_domid", libxl_domid), 
> >> +("backend_domname", string), 
> >> +   ]) 
> >> + 
> >> +libxl_device_usb = Struct("device_usb", [ 
> >> +("ctrl", libxl_devid), 
> >> +("port", integer), 
> >> +("u", KeyedUnion(None, libxl_usbdev_type, "devtype", 
> >> +   [("hostdev", Struct(None, [ 
> >> + ("hostbus",   integer), 
> >> + ("hostaddr",  integer)])), 
> >> +("invalid", None), 
> >  
> > AIUI this is what was agreed to, i.e. an enum with only one real option, in 
> > order to leave a space for new devtypes without major API overhaul. 
> >  
> > Please can you confirm that hostbus and hostaddr are both flat integer 
> > namespaces (i.e. there is no structure to the bits within either, they are 
> > just a number). 
>  
> I can confirm this. 
>  
>  -George 
>  
>  
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 8/13/2015 at 05:09 PM, in message
20150813090938.gi7...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote: 
 On Tue, Aug 11, 2015 at 08:24:01PM -0600, Chun Yan Liu wrote: 
   
   
   On 8/11/2015 at 07:27 PM, in message 
  2015082702.gf7...@zion.uk.xensource.com, Wei Liu 
  wei.l...@citrix.com 
  wrote:  
   On Mon, Aug 10, 2015 at 06:35:24PM +0800, 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: Chunyan Liu cy...@suse.com  
Signed-off-by: Simon Cao caobosi...@gmail.com  
  
---  
changes:  
  - Address George's comments:  
  * Update libxl_device_usb_getinfo to read ctrl/port only and  
get other information.  
  * Update backend path according to xenstore frontend 'xxx/backend'  
entry instead of using TOOLSTACK_DOMID.  
  * Use 'type' to indicate qemu/pv instead of previous naming 
'protocol'.  
  
  * Add USB 'devtype' union, currently only includes hostdev  
  
 
   I will leave this to Ian and George since they had strong opinions on  
   this.  
 
   I only skimmed this patch. Some comments below.  
 
   [...]  
+  
+int libxl_device_usb_getinfo(libxl_ctx *ctx, uint32_t domid,  
+ libxl_device_usb *usb,  
+ libxl_usbinfo *usbinfo);  
+  
 /* Network Interfaces */  
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid,  
 libxl_device_nic   
   *nic,  
  const libxl_asyncop_how *ao_how)  
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c  
index bee5ed5..935f25b 100644  
--- a/tools/libxl/libxl_device.c  
+++ b/tools/libxl/libxl_device.c  
@@ -676,6 +676,10 @@ 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) {  
+libxl__initiate_device_usbctrl_remove(egc, aodev); 
 
+continue;  
+}  
 
   Is there a risk that this races with individual device removal? I think  
   you get away with it because removal of individual device is idempotent?  
   
  You mean races with other device removal (like 'vbd') ? Yes, it is  
 idempotent. 
  Only for 'vusb' (corresponding to USB controller), before removing USB  
 controller 
  it will first removing all USB devices under it.  
   
  
 No. What I mean is, the removal of usbctrl triggers removal of all 
 assigned usb devices. And then this function initiates removal of 
 assigned usb devices again. Is this a possible scenario? 
  
 
 libxl__initiate_device_remove(egc, aodev);  
 }  
 }  
diff --git a/tools/libxl/libxl_internal.h 
b/tools/libxl/libxl_internal.h  
index f98f089..5be3b3a 100644  
--- a/tools/libxl/libxl_internal.h  
+++ b/tools/libxl/libxl_internal.h  
@@ -2553,6 +2553,14 @@ _hidden void libxl__device_vtpm_add(libxl__egc  
 *egc,   
   uint32_t domid,  
libxl_device_vtpm *vtpm,  
libxl__ao_device *aodev);  
   
+_hidden void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t 
domid,  
+   libxl_device_usbctrl *usbctrl,  
+   libxl__ao_device *aodev);  
+  
+_hidden void libxl__device_usb_add(libxl__egc *egc, uint32_t domid,  
+   libxl_device_usb *usb,  
+   libxl__ao_device *aodev);  
+  
 /* Internal function to connect a vkb device */  
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,  
   libxl_device_vkb *vkb);  
@@ -2585,6 +2593,13 @@ _hidden void   
   libxl__wait_device_connection(libxl__egc*,  
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,  
libxl__ao_device *aodev);  
   
+_hidden int libxl__device_from_usbctrl(libxl__gc *gc, uint32_t domid,  
   [...]  
+void libxl__device_usb_add(libxl__egc *egc, uint32_t domid,  
+   libxl_device_usb *usb,  
+   libxl__ao_device *aodev)  
+{  
+STATE_AO_GC(aodev-ao);  
+int rc = -1;  
+char *busid = NULL;  
+  
+assert(usb-u.hostdev.hostbus  0  usb-u.hostdev.hostaddr  0); 
 
+  
+busid = usb_busaddr_to_busid(gc, usb-u.hostdev.hostbus

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 8/13/2015 at 05:09 PM, in message
20150813090938.gi7...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote: 
 On Tue, Aug 11, 2015 at 08:24:01PM -0600, Chun Yan Liu wrote: 
   
   
   On 8/11/2015 at 07:27 PM, in message 
  2015082702.gf7...@zion.uk.xensource.com, Wei Liu 
  wei.l...@citrix.com 
  wrote:  
   On Mon, Aug 10, 2015 at 06:35:24PM +0800, 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: Chunyan Liu cy...@suse.com  
Signed-off-by: Simon Cao caobosi...@gmail.com  
  
---  
changes:  
  - Address George's comments:  
  * Update libxl_device_usb_getinfo to read ctrl/port only and  
get other information.  
  * Update backend path according to xenstore frontend 'xxx/backend'  
entry instead of using TOOLSTACK_DOMID.  
  * Use 'type' to indicate qemu/pv instead of previous naming 
'protocol'.  
  
  * Add USB 'devtype' union, currently only includes hostdev  
  
 
   I will leave this to Ian and George since they had strong opinions on  
   this.  
 
   I only skimmed this patch. Some comments below.  
 
   [...]  
+  
+int libxl_device_usb_getinfo(libxl_ctx *ctx, uint32_t domid,  
+ libxl_device_usb *usb,  
+ libxl_usbinfo *usbinfo);  
+  
 /* Network Interfaces */  
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid,  
 libxl_device_nic   
   *nic,  
  const libxl_asyncop_how *ao_how)  
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c  
index bee5ed5..935f25b 100644  
--- a/tools/libxl/libxl_device.c  
+++ b/tools/libxl/libxl_device.c  
@@ -676,6 +676,10 @@ 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) {  
+libxl__initiate_device_usbctrl_remove(egc, aodev); 
 
+continue;  
+}  
 
   Is there a risk that this races with individual device removal? I think  
   you get away with it because removal of individual device is idempotent?  
   
  You mean races with other device removal (like 'vbd') ? Yes, it is  
 idempotent. 
  Only for 'vusb' (corresponding to USB controller), before removing USB  
 controller 
  it will first removing all USB devices under it.
h   
  
 No. What I mean is, the removal of usbctrl triggers removal of all 
 assigned usb devices. And then this function initiates removal of 
 assigned usb devices again. Is this a possible scenario? 

No, it's not possible. libxl__devices_destroy is used in domain destroy, it's
trying to scan each device type in xenstore and destroy them. Since USB device
is NOT presented as a separate device type but inside USB controller (which is
represented by a 'vusb' device in xenstore), so when scanning 'vusb' type, it
tries to destroy USB controller, within that it will destroy all USB devices 
under
that controller. No entry to remove USB device alone. 

Thanks,
Chunyan

  
 
 libxl__initiate_device_remove(egc, aodev);  
 }  
 }  
diff --git a/tools/libxl/libxl_internal.h 
b/tools/libxl/libxl_internal.h  
index f98f089..5be3b3a 100644  
--- a/tools/libxl/libxl_internal.h  
+++ b/tools/libxl/libxl_internal.h  
@@ -2553,6 +2553,14 @@ _hidden void libxl__device_vtpm_add(libxl__egc  
 *egc,   
   uint32_t domid,  
libxl_device_vtpm *vtpm,  
libxl__ao_device *aodev);  
   
+_hidden void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t 
domid,  
+   libxl_device_usbctrl *usbctrl,  
+   libxl__ao_device *aodev);  
+  
+_hidden void libxl__device_usb_add(libxl__egc *egc, uint32_t domid,  
+   libxl_device_usb *usb,  
+   libxl__ao_device *aodev);  
+  
 /* Internal function to connect a vkb device */  
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,  
   libxl_device_vkb *vkb);  
@@ -2585,6 +2593,13 @@ _hidden void   
   libxl__wait_device_connection(libxl__egc*,  
 _hidden void libxl__initiate_device_remove(libxl__egc *egc,  
libxl__ao_device *aodev);  
   
+_hidden int libxl__device_from_usbctrl(libxl__gc *gc, uint32_t

Re: [Xen-devel] [PATCH V6 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Chun Yan Liu]

 On 8/11/2015 at 07:26 PM, in message
2015082655.ge7...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote: 
 On Mon, Aug 10, 2015 at 06:35:23PM +0800, Chunyan Liu wrote: 
  Sysfs file has size=4096 but actual file content is less than that. 
  Current libxl_read_file_contents will treat it as error when file size 
  and actual file content differs, so reading sysfs file content with 
  this function always fails. 
   
  Add a new entry libxl_read_sysfs_file_contents to handle sysfs file 
  specially. It would be used in later pvusb work. 
   
  Signed-off-by: Chunyan Liu cy...@suse.com 
   
  --- 
  Changes: 
- read one more byte to check bigger size problem. 
   
   tools/libxl/libxl_internal.h |  2 ++ 
   tools/libxl/libxl_utils.c| 51 
  ++-- 
   2 files changed, 42 insertions(+), 11 deletions(-) 
   
  diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h 
  index 6013628..f98f089 100644 
  --- a/tools/libxl/libxl_internal.h 
  +++ b/tools/libxl/libxl_internal.h 
  @@ -4001,6 +4001,8 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc,  
 libxl_bitmap *dptr, 

   int libxl__count_physical_sockets(libxl__gc *gc, int *sockets); 
   #endif 
  +_hidden int libxl_read_sysfs_file_contents(libxl_ctx *ctx, const char  
 *filename, 
  +   void **data_r, int *datalen_r); 
  
 Indentation looks wrong. 
  

   /* 
* Local variables: 
  diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c 
  index bfc9699..9234efb 100644 
  --- a/tools/libxl/libxl_utils.c 
  +++ b/tools/libxl/libxl_utils.c 
  @@ -322,8 +322,10 @@ out: 
   return rc; 
   } 

  -int libxl_read_file_contents(libxl_ctx *ctx, const char *filename, 
  - void **data_r, int *datalen_r) { 
  +static int libxl_read_file_contents_core(libxl_ctx *ctx, const char  
 *filename, 
  + void **data_r, int *datalen_r, 
  + bool tolerate_shrinking_file) 
  +{ 
   GC_INIT(ctx); 
   FILE *f = 0; 
   uint8_t *data = 0; 
  @@ -359,20 +361,34 @@ int libxl_read_file_contents(libxl_ctx *ctx, const  
 char *filename, 
   datalen = stab.st_size; 

   if (stab.st_size  data_r) { 
  -data = malloc(datalen); 
  +data = malloc(datalen + 1); 
   if (!data) goto xe; 

  -rs = fread(data, 1, datalen, f); 
  -if (rs != datalen) { 
  -if (ferror(f)) 
  +rs = fread(data, 1, datalen + 1, f); 
  +if (rs  datalen) { 
  +LOG(ERROR, %s increased size while we were reading it, 
  +filename); 
  +goto xe; 
  +} 
  + 
  +if (rs  datalen) { 
  +if (ferror(f)) { 
   LOGE(ERROR, failed to read %s, filename); 
  -else if (feof(f)) 
  -LOG(ERROR, %s changed size while we were reading it, 
  -   filename); 
  -else 
  +goto xe; 
  +} else if (feof(f)) { 
  +if (tolerate_shrinking_file) { 
  +datalen = rs; 
  +} else { 
  +LOG(ERROR, %s shrunk size while we were reading it, 
  +filename); 
  +goto xe; 
  +} 
  +} else { 
   abort(); 
  -goto xe; 
  +} 
  
 This is a bit bikeshedding, but you can leave goto xe out of two `if' 
 to reduce patch size. 

I guess you mean if (ferror(f)) and if (feof(f)) ? We can't leave 'goto xe' 
outside,
since in if (feof(f))  if (tolerate_shrinking_file), it's not error but an 
expected
result in sysfs case.   

   } 
  + 
  +data = realloc(data, datalen); 
  
 Should check return value of realloc.

Will add a check:
if (!data) goto xe; 

Thanks,
Chunyan
  
 The logic of this function reflects what has been discussed so far. 
  
 Wei. 
  
   } 

   if (fclose(f)) { 
  @@ -396,6 +412,19 @@ int libxl_read_file_contents(libxl_ctx *ctx, const 
  char  
 *filename, 
   return e; 
   } 

  +int libxl_read_file_contents(libxl_ctx *ctx, const char *filename, 
  + void **data_r, int *datalen_r) 
  +{ 
  +return libxl_read_file_contents_core(ctx, filename, data_r, datalen_r, 
   
 0); 
  +} 
  + 
  +int libxl_read_sysfs_file_contents(libxl_ctx *ctx, const char *filename, 
  +   void **data_r, int *datalen_r) 
  +{ 
  +return libxl_read_file_contents_core(ctx, filename, data_r, datalen_r, 
   
 1); 
  +} 
  + 
  + 
   #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata) 
 \ 
  
 \ 
 int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \ 
  --  
  2.1.4 
  
  

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 8/11/2015 at 07:27 PM, in message
2015082702.gf7...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote: 
 On Mon, Aug 10, 2015 at 06:35:24PM +0800, 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: Chunyan Liu cy...@suse.com 
  Signed-off-by: Simon Cao caobosi...@gmail.com 
   
  --- 
  changes: 
- Address George's comments: 
* Update libxl_device_usb_getinfo to read ctrl/port only and 
  get other information. 
* Update backend path according to xenstore frontend 'xxx/backend' 
  entry instead of using TOOLSTACK_DOMID. 
* Use 'type' to indicate qemu/pv instead of previous naming 'protocol'. 
* Add USB 'devtype' union, currently only includes hostdev 
   
  
 I will leave this to Ian and George since they had strong opinions on 
 this. 
  
 I only skimmed this patch. Some comments below. 
  
 [...] 
  + 
  +int libxl_device_usb_getinfo(libxl_ctx *ctx, uint32_t domid, 
  + libxl_device_usb *usb, 
  + libxl_usbinfo *usbinfo); 
  + 
   /* Network Interfaces */ 
   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic  
 *nic, 
const libxl_asyncop_how *ao_how) 
  diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c 
  index bee5ed5..935f25b 100644 
  --- a/tools/libxl/libxl_device.c 
  +++ b/tools/libxl/libxl_device.c 
  @@ -676,6 +676,10 @@ 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) { 
  +libxl__initiate_device_usbctrl_remove(egc, aodev); 
  +continue; 
  +} 
  
 Is there a risk that this races with individual device removal? I think 
 you get away with it because removal of individual device is idempotent? 

You mean races with other device removal (like 'vbd') ? Yes, it is idempotent.
Only for 'vusb' (corresponding to USB controller), before removing USB 
controller
it will first removing all USB devices under it. 

  
   libxl__initiate_device_remove(egc, aodev); 
   } 
   } 
  diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h 
  index f98f089..5be3b3a 100644 
  --- a/tools/libxl/libxl_internal.h 
  +++ b/tools/libxl/libxl_internal.h 
  @@ -2553,6 +2553,14 @@ _hidden void libxl__device_vtpm_add(libxl__egc *egc, 
   
 uint32_t domid, 
  libxl_device_vtpm *vtpm, 
  libxl__ao_device *aodev); 

  +_hidden void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid, 
  +   libxl_device_usbctrl *usbctrl, 
  +   libxl__ao_device *aodev); 
  + 
  +_hidden void libxl__device_usb_add(libxl__egc *egc, uint32_t domid, 
  +   libxl_device_usb *usb, 
  +   libxl__ao_device *aodev); 
  + 
   /* Internal function to connect a vkb device */ 
   _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, 
 libxl_device_vkb *vkb); 
  @@ -2585,6 +2593,13 @@ _hidden void  
 libxl__wait_device_connection(libxl__egc*, 
   _hidden void libxl__initiate_device_remove(libxl__egc *egc, 
  libxl__ao_device *aodev); 

  +_hidden int libxl__device_from_usbctrl(libxl__gc *gc, uint32_t domid, 
 [...] 
  +void libxl__device_usb_add(libxl__egc *egc, uint32_t domid, 
  +   libxl_device_usb *usb, 
  +   libxl__ao_device *aodev) 
  +{ 
  +STATE_AO_GC(aodev-ao); 
  +int rc = -1; 
  +char *busid = NULL; 
  + 
  +assert(usb-u.hostdev.hostbus  0  usb-u.hostdev.hostaddr  0); 
  + 
  +busid = usb_busaddr_to_busid(gc, usb-u.hostdev.hostbus, 
  + usb-u.hostdev.hostaddr); 
  +if (!busid) { 
  +LOG(ERROR, USB device doesn't exist in sysfs); 
  +goto out; 
  +} 
  + 
  +if (!is_usb_assignable(gc, usb)) { 
  +LOG(ERROR, USB device is not assignable.); 
  +goto out; 
  +} 
  + 
  +/* check usb device is already assigned */ 
  +if (is_usb_assigned(gc, usb)) { 
  +LOG(ERROR, USB device is already attached to a domain.); 
  +goto out; 
  +} 
  + 
  +rc = libxl__device_usb_setdefault(gc, domid, usb, aodev-update_json); 
  +if (rc) goto out; 
  + 
  +rc = libxl__device_usb_add_xenstore(gc, domid, usb, 
  aodev-update_json); 
  +if (rc) goto out; 
  + 
  +rc = 

Re: [Xen-devel] [PATCH V5 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 8/7/2015 at 01:21 AM, in message 55c39796.8000...@citrix.com, George
Dunlap george.dun...@citrix.com wrote: 
 On 08/06/2015 04:11 AM, Chun Yan Liu wrote: 
  As 4.6 goes to bug fixing stage, maybe we can pick up this thread? :-) 
   
  Beside to call for your precious review comments and suggestions so that we 
   
 can 
  make progress, I also want to confirm about the previous discussed two TODO 
  things: 
  1) use UDEV name rule to specify usb device uniquely even across reboot.  
 That 
  got consensus. Next thing is exposing that name to some sysfs entry,  
 right? 
  
 So just to be clear, my understanding of the plan was that we try to fix 
 up the current patch series and check it in once the 4.7 window opens; 
 and that having the utility library to convert other names (including 
 this udev-style naming) into something libxl can use would be a separate 
 series. 
  
 I wasn't necessarily expecting you to work on it (since it wasn't your 
 idea), but if you're keen, I'm sure we'd be grateful. :-) 
  
  2) use libusb instead of reading sysfs by ourselves. As George mentioned,  
 using 
  libusb is not simpler than reading sysfs; and if UDEV name is stored to 
   
 some 
  sysfs entry for us to retrieve, then we still need reading sysfs  
 things. Could we 
  get to a final decision? 
  If these are settled down, I can update related code. 
  
 I don't think that libusb would be particularly useful for the current 
 pvusb code, since 
 1. It's already Linux-specific, 
 2. We need to mess around with sysfs anyway. 
  
 The same thing can't be said of the HVM path: I think it fairly likely 
 that the emulated pass-through will Just Work (or nearly so) on BSDs 
 (assuming that qemu itself works on the BSDs). 
  
 I think it we write our utility library for converting 
 vendorid:productid[:serialno], bus-port, c, then it might make sense to 
 use libusb if it makes it more portable. 
  
 Regarding the code: 
  
 Things are looking pretty close.  A couple of comments in-line: 
  
  diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c   
  index 93bb41e..9869a21 100644   
  --- a/tools/libxl/libxl_device.c   
  +++ b/tools/libxl/libxl_device.c   
  @@ -676,6 +676,10 @@ 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) {   
  +libxl__initiate_device_usbctrl_remove(egc, aodev);  
   
  +continue;   
  +} 
  
 I take it the reason we need to special-case this is that we need to go 
 through and un-assign all of the devices inside the controller first? 
  
 At some point we probably want to generalize this a bit, so that usb 
 controllers and vscsi controllers look the same (rather than both being 
 special-cased). 
  
 But since this is internal, maybe we can wait for that design until we 
 actually have both types available. 
  
  +static int   
  +libxl__device_usb_assigned_list(libxl__gc *gc,   
  +libxl_device_usb **list, int *num)   
  +{   
  +char **domlist;   
  +unsigned int nd = 0, i, j;   
  +char *be_path;   
  +libxl_device_usb *usb;   
  +   
  +*list = NULL;   
  +*num = 0;   
  +   
  +domlist = libxl__xs_directory(gc, XBT_NULL, /local/domain, nd);  
   
  +be_path = GCSPRINTF(/local/domain/%d/backend/vusb,
  LIBXL_TOOLSTACK_DOMID);   
  
 Hmm, so this had made me realize that I don't think we're doing quite 
 the right thing for non-dom0 backends.  

For non-dom0 backends, here 'be_path' should be replaced with the right backend.

  
 First of all, things are a bit interesting for driver domain backends, 
 because the namespace of hostbus.hostaddr depends on the backend of 
 the virtual controller.  Which wouldn't be particularly interesting, 
 *except* that because the USB space is so dynamic, you normally have to 
 query the devices to find the hostbus.hostaddr; and you can't do any 
 queries from dom0 at the moment (except, for example, by ssh'ing into 
 the other vm).  So to even assign a hostbus.hostaddr device you have to 
 somehow learn, out-of-band, what those numbers are within the domain.

I think you are right. As for the network driver domain, when specifying vif,
we also need to know the bridge name in that driver domain, then we can use:
vif = [ 'bridge=xenbr0, mac=00:16:3E:0d:13:00, model=e1000, backend=domnet' ]

  
 Secondly, if the backend is in another domain, then all the stuff re 
 assigning a usb device to usbback can't be done by libxl in the 
 toolstack domain either.

Yes. I think so. Should be done in driver domain then.

  Which means I'm pretty sure this stuff will 
 fail at the moment for USB driver domains trying to assign a 
 non-existent

Re: [Xen-devel] [PATCH V5 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 8/7/2015 at 01:21 AM, in message 55c39796.8000...@citrix.com, George
Dunlap george.dun...@citrix.com wrote: 
 On 08/06/2015 04:11 AM, Chun Yan Liu wrote: 
  As 4.6 goes to bug fixing stage, maybe we can pick up this thread? :-) 
   
  Beside to call for your precious review comments and suggestions so that we 
   
 can 
  make progress, I also want to confirm about the previous discussed two TODO 
  things: 
  1) use UDEV name rule to specify usb device uniquely even across reboot.  
 That 
  got consensus. Next thing is exposing that name to some sysfs entry,  
 right? 
  
 So just to be clear, my understanding of the plan was that we try to fix 
 up the current patch series and check it in once the 4.7 window opens; 
 and that having the utility library to convert other names (including 
 this udev-style naming) into something libxl can use would be a separate 
 series. 

Got it.

  
 I wasn't necessarily expecting you to work on it (since it wasn't your 
 idea), but if you're keen, I'm sure we'd be grateful. :-) 
  
  2) use libusb instead of reading sysfs by ourselves. As George mentioned,  
 using 
  libusb is not simpler than reading sysfs; and if UDEV name is stored to 
   
 some 
  sysfs entry for us to retrieve, then we still need reading sysfs  
 things. Could we 
  get to a final decision? 
  If these are settled down, I can update related code. 
  
 I don't think that libusb would be particularly useful for the current 
 pvusb code, since 
 1. It's already Linux-specific, 
 2. We need to mess around with sysfs anyway. 
  
 The same thing can't be said of the HVM path: I think it fairly likely 
 that the emulated pass-through will Just Work (or nearly so) on BSDs 
 (assuming that qemu itself works on the BSDs). 
  
 I think it we write our utility library for converting 
 vendorid:productid[:serialno], bus-port, c, then it might make sense to 
 use libusb if it makes it more portable. 
  
 Regarding the code: 
  
 Things are looking pretty close.  A couple of comments in-line: 
  
  diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c   
  index 93bb41e..9869a21 100644   
  --- a/tools/libxl/libxl_device.c   
  +++ b/tools/libxl/libxl_device.c   
  @@ -676,6 +676,10 @@ 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) {   
  +libxl__initiate_device_usbctrl_remove(egc, aodev);  
   
  +continue;   
  +} 
  
 I take it the reason we need to special-case this is that we need to go 
 through and un-assign all of the devices inside the controller first? 

Yes.

  
 At some point we probably want to generalize this a bit, so that usb 
 controllers and vscsi controllers look the same (rather than both being 
 special-cased). 
  
 But since this is internal, maybe we can wait for that design until we 
 actually have both types available. 
  
  +static int   
  +libxl__device_usb_assigned_list(libxl__gc *gc,   
  +libxl_device_usb **list, int *num)   
  +{   
  +char **domlist;   
  +unsigned int nd = 0, i, j;   
  +char *be_path;   
  +libxl_device_usb *usb;   
  +   
  +*list = NULL;   
  +*num = 0;   
  +   
  +domlist = libxl__xs_directory(gc, XBT_NULL, /local/domain, nd);  
   
  +be_path = GCSPRINTF(/local/domain/%d/backend/vusb,
  LIBXL_TOOLSTACK_DOMID);   
  
 Hmm, so this had made me realize that I don't think we're doing quite 
 the right thing for non-dom0 backends. 
  
 First of all, things are a bit interesting for driver domain backends, 
 because the namespace of hostbus.hostaddr depends on the backend of 
 the virtual controller.  Which wouldn't be particularly interesting, 
 *except* that because the USB space is so dynamic, you normally have to 
 query the devices to find the hostbus.hostaddr; and you can't do any 
 queries from dom0 at the moment (except, for example, by ssh'ing into 
 the other vm).  So to even assign a hostbus.hostaddr device you have to 
 somehow learn, out-of-band, what those numbers are within the domain. 
  
 Secondly, if the backend is in another domain, then all the stuff re 
 assigning a usb device to usbback can't be done by libxl in the 
 toolstack domain either.  Which means I'm pretty sure this stuff will 
 fail at the moment for USB driver domains trying to assign a 
 non-existent hostbus.hostaddr to the (possibly non-existent) dom0 usbback. 
  
 A couple of ways forward: 
  
 1. Delete backend_domid and backend_name; add them back later when we 
 decide to implement proper USB driver domain support 
  
 2. Leave backend_domid and backend_name, but return an error if they are 
 not 0 and NULL respectively. 
  
 3. If backend_domid

Re: [Xen-devel] [PATCH V5 3/7] libxl: add pvusb API

[Chun Yan Liu]

As 4.6 goes to bug fixing stage, maybe we can pick up this thread? :-)

Beside to call for your precious review comments and suggestions so that we can
make progress, I also want to confirm about the previous discussed two TODO
things:
1) use UDEV name rule to specify usb device uniquely even across reboot. That
got consensus. Next thing is exposing that name to some sysfs entry, right?
2) use libusb instead of reading sysfs by ourselves. As George mentioned, using
libusb is not simpler than reading sysfs; and if UDEV name is stored to some
sysfs entry for us to retrieve, then we still need reading sysfs things. 
Could we
get to a final decision?
If these are settled down, I can update related code.

Thanks,
Chunyan

 On 7/7/2015 at 05:57 PM, in message 559ba270.4000...@eu.citrix.com, George
Dunlap george.dun...@eu.citrix.com wrote: 
 On 07/07/2015 02:25 AM, Chun Yan Liu wrote: 
  Any comments on the implementation? If there is anything improper, I can  
 update. 
  
 Since we decided to wait until the next release, I've been prioritizing 
 reviewing patch series which might make it into 4.6.  I'll come back to 
 it once the freeze starts. 
  
 Believe me, I'd much rather be working on the USB stuff. :-) 
  
  -George 
  
   
  Thanks, 
  Chunyan 
   
  On 6/25/2015 at 06:07 PM, in message 
  1435226838-3067-4-git-send-email-cy...@suse.com, Chunyan Liu 
  cy...@suse.com 
  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: Chunyan Liu cy...@suse.com  
  Signed-off-by: Simon Cao caobosi...@gmail.com  
  ---  
  changes:  
- Use macros DEFINE_DEVICE_ADD and DEFINE_DEVICES_ADD for adding  
  usbctrl and usb, update all related codes.  
- Use an extend macro DEFINE_DEVICE_REMOVE_EXT for removimg usbctrl 
  update all related codes.  
- Remove busid from libxl_device_usb definition, keep bus.addr only,  
  update all related codes.  
- Remove documentation since it's mostly about design, move to  
  cover-letter. Some parts are moved to code comments.  
- Address some other comments  

   tools/libxl/Makefile |2 +-  
   tools/libxl/libxl.c  |   53 ++  
   tools/libxl/libxl.h  |   64 ++  
   tools/libxl/libxl_device.c   |4 +  
   tools/libxl/libxl_internal.h |   20 +-  
   tools/libxl/libxl_osdeps.h   |   13 +  
   tools/libxl/libxl_pvusb.c| 1305   
  ++  
   tools/libxl/libxl_types.idl  |   50 ++  
   tools/libxl/libxl_types_internal.idl |1 +  
   tools/libxl/libxl_utils.c|   16 +  
   tools/libxl/libxl_utils.h|5 +  
   11 files changed, 1531 insertions(+), 2 deletions(-)  
   create mode 100644 tools/libxl/libxl_pvusb.c  

  diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile  
  index cc9c152..b820105 100644  
  --- a/tools/libxl/Makefile  
  +++ b/tools/libxl/Makefile  
  @@ -95,7 +95,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
  libxl_dm.o  
   
  libxl_pci.o \  
 libxl_internal.o libxl_utils.o libxl_uuid.o \  
 libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o 
  \  
 libxl_save_callout.o _libxl_save_msgs_callout.o \  
  -  libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)  
  +  libxl_qmp.o libxl_event.o libxl_fork.o libxl_pvusb.o 
  $(LIBXL_OBJS-y)  
   LIBXL_OBJS += libxl_genid.o  
   LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o  
 
  diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c  
  index 6570476..6542127 100644  
  --- a/tools/libxl/libxl.c  
  +++ b/tools/libxl/libxl.c  
  @@ -4233,11 +4233,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)  
 
 
   
 / 
  
  
  **/  
 
  +/* Macro for defining device remove/destroy functions for usbctrl */  
  +/* Following functions are defined:  
  + * libxl_device_usbctrl_remove  
  + * libxl_device_usbctrl_destroy  
  + */  
  +  
  +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
   
  +int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
   
  +uint32_t domid, libxl_device_##type *type,  \ 
   
  +const libxl_asyncop_how *ao_how)\ 
   
  +{   \ 
   
  +AO_CREATE(ctx, domid, ao_how);  \ 
   
  +libxl__device *device;  \ 
   
  +libxl__ao_device *aodev;\ 
   
  +int rc

Re: [Xen-devel] [PATCH V5 3/7] libxl: add pvusb API

[Chun Yan Liu]

Any comments on the implementation? If there is anything improper, I can update.

Thanks,
Chunyan

 On 6/25/2015 at 06:07 PM, in message
1435226838-3067-4-git-send-email-cy...@suse.com, Chunyan Liu cy...@suse.com
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: Chunyan Liu cy...@suse.com 
 Signed-off-by: Simon Cao caobosi...@gmail.com 
 --- 
 changes: 
   - Use macros DEFINE_DEVICE_ADD and DEFINE_DEVICES_ADD for adding 
 usbctrl and usb, update all related codes. 
   - Use an extend macro DEFINE_DEVICE_REMOVE_EXT for removimg usbctrl
 update all related codes. 
   - Remove busid from libxl_device_usb definition, keep bus.addr only, 
 update all related codes. 
   - Remove documentation since it's mostly about design, move to 
 cover-letter. Some parts are moved to code comments. 
   - Address some other comments 
  
  tools/libxl/Makefile |2 +- 
  tools/libxl/libxl.c  |   53 ++ 
  tools/libxl/libxl.h  |   64 ++ 
  tools/libxl/libxl_device.c   |4 + 
  tools/libxl/libxl_internal.h |   20 +- 
  tools/libxl/libxl_osdeps.h   |   13 + 
  tools/libxl/libxl_pvusb.c| 1305  
 ++ 
  tools/libxl/libxl_types.idl  |   50 ++ 
  tools/libxl/libxl_types_internal.idl |1 + 
  tools/libxl/libxl_utils.c|   16 + 
  tools/libxl/libxl_utils.h|5 + 
  11 files changed, 1531 insertions(+), 2 deletions(-) 
  create mode 100644 tools/libxl/libxl_pvusb.c 
  
 diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile 
 index cc9c152..b820105 100644 
 --- a/tools/libxl/Makefile 
 +++ b/tools/libxl/Makefile 
 @@ -95,7 +95,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o  
 libxl_pci.o \ 
   libxl_internal.o libxl_utils.o libxl_uuid.o \ 
   libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o 
 \ 
   libxl_save_callout.o _libxl_save_msgs_callout.o \ 
 - libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y) 
 + libxl_qmp.o libxl_event.o libxl_fork.o libxl_pvusb.o 
 $(LIBXL_OBJS-y) 
  LIBXL_OBJS += libxl_genid.o 
  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o 
   
 diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
 index 6570476..6542127 100644 
 --- a/tools/libxl/libxl.c 
 +++ b/tools/libxl/libxl.c 
 @@ -4233,11 +4233,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
   
   
 / 
 **/ 
   
 +/* Macro for defining device remove/destroy functions for usbctrl */ 
 +/* Following functions are defined: 
 + * libxl_device_usbctrl_remove 
 + * libxl_device_usbctrl_destroy 
 + */ 
 + 
 +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
 +int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
 +uint32_t domid, libxl_device_##type *type,  \ 
 +const libxl_asyncop_how *ao_how)\ 
 +{   \ 
 +AO_CREATE(ctx, domid, ao_how);  \ 
 +libxl__device *device;  \ 
 +libxl__ao_device *aodev;\ 
 +int rc; \ 
 +\ 
 +GCNEW(device);  \ 
 +rc = libxl__device_from_##type(gc, domid, type, device);\ 
 +if (rc != 0) goto out;  \ 
 +\ 
 +GCNEW(aodev);   \ 
 +libxl__prepare_ao_device(ao, aodev);\ 
 +aodev-action = LIBXL__DEVICE_ACTION_REMOVE;\ 
 +aodev-dev = device;\ 
 +aodev-callback = device_addrm_aocomplete;  \ 
 +aodev-force = f;   \ 
 +libxl__initiate_device_##type##_remove(egc, aodev); \ 
 +\ 
 +out:\ 
 +if (rc) return AO_ABORT(rc);\ 
 +return AO_INPROGRESS;   \ 
 +} 
 + 
 + 
 +DEFINE_DEVICE_REMOVE_EXT(usbctrl, remove, 0) 
 +DEFINE_DEVICE_REMOVE_EXT(usbctrl, destroy, 1) 
 + 
 

Re: [Xen-devel] [PATCH V5 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Chun Yan Liu]

 On 6/30/2015 at 05:08 PM, in message
21906.23698.778991.627...@mariner.uk.xensource.com, Ian Jackson
ian.jack...@eu.citrix.com wrote: 
 Chun Yan Liu writes (Re: [PATCH V5 2/7] libxl_read_file_contents: add new  
 entry to read sysfs file): 
   On 6/29/2015 at 06:52 PM, in message 
  21905.9050.452111.208...@mariner.uk.xensource.com, Ian Jackson 
  ian.jack...@eu.citrix.com wrote:  
   Chun Yan Liu writes (Re: [PATCH V5 2/7] libxl_read_file_contents: add 
   new  
   But if we are intending to use this with sysfs files, where the  
   reported size is known to be wrong, it seems to me that we should be  
   more proactive. 
   
  If only for sysfs files, the bigger size problem should never 
  happens, since sysfs system is not like normal file system, user 
  won't be able to change the size. 
   
  Reference from following link: 
  http://www.makelinux.net/books/lkd2/ch17lev1sec8 
  
 I don't think that can be relied on as a guide to the future API. 
 Maybe sysfs will grow support for bigger files in the future.  (Also, 
 that is actually a description of the kernel internals, not of the 
 syscall API). 

Yes, that's about kernel internals. But syscall API will finally call
kernel implementation. From those description, we knows why
fstat always return size 4096 (on x86_64, although actual file
content length is less). And it's not possible the file is changed
into a bigger size during we are reading it. About whether it'll
be changed in future, really don't know.

As to adding a check, it's certainly OK. I can update.

Thanks,
Chunyan
 
  
 Thanks, 
 Ian. 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V5 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Chun Yan Liu]

 On 6/26/2015 at 09:05 PM, in message
21901.20009.85407.581...@mariner.uk.xensource.com, Ian Jackson
ian.jack...@eu.citrix.com wrote: 
 Chun Yan Liu writes (Re: [PATCH V5 2/7] libxl_read_file_contents: add new  
 entry to read sysfs file): 
   On 6/25/2015 at 07:09 PM, in message 
  21899.57676.368102.982...@mariner.uk.xensource.com, Ian Jackson 
  ian.jack...@eu.citrix.com wrote:  
   Chunyan Liu writes ([PATCH V5 2/7] libxl_read_file_contents: add new  
 entry   Add a new entry libxl_read_sysfs_file_contents to handle sysfs 
 file  
specially. It would be used in later pvusb work.  
 
   I think this still fails to detect a situation where the file is  
   unexpectedly longer than the requested size ?  
   
  +} else if (feof(f)) { 
  +if (rs  datalen  tolerate_shrinking_file) { 
  +datalen = rs; 
  +} else { 
   
  If the file is bigger than the requested size, it will fall to this 
  branch and report error. 
  
 I don't think this is true.  I just applied your patch to my copy of 
 staging to see what the code looks like and saw this: 
  
 if (stab.st_size  data_r) { 
 data = malloc(datalen); 
 if (!data) goto xe; 
  
 rs = fread(data, 1, datalen, f); 
 if (rs != datalen) { 
 if (ferror(f)) { 
 LOGE(ERROR, failed to read %s, filename); 
 goto xe; 
 } else if (feof(f)) { 
 if (rs  datalen  tolerate_shrinking_file) { 
 datalen = rs; 
 } else { 
 LOG(ERROR, %s changed size while we were reading it, 
 filename); 
 goto xe; 
 } 
 } else { 
 abort(); 
 } 
 } 
 } 
  
 So I think in the case of a sysfs file which is 4096 bytes: 
  
  - stat will succeed and give st_size == 4096 
  - fread(,,4096,) will read the first 4096 bytes and return 4096 
  - rs == datalen, so we don't take the `errors and special 
  cases' branch 
  - we return success having read 4096 bytes 
  
 But please feel free to explain why I'm wrong. 

You are right. I'm confused about the original logic. The original code
doesn't consider this case (size bigger than requested) at all. So, we need
to add a check if (rs == datalen  read end of file), if not, means bigger
than requested, report error.

- Chunyan

  
 Thanks, 
 Ian. 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V5 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Chun Yan Liu]

 On 6/29/2015 at 06:52 PM, in message
21905.9050.452111.208...@mariner.uk.xensource.com, Ian Jackson
ian.jack...@eu.citrix.com wrote: 
 Chun Yan Liu writes (Re: [PATCH V5 2/7] libxl_read_file_contents: add new  
 entry to read sysfs file): 
  On 6/26/2015 at 09:05 PM, in message 
  21901.20009.85407.581...@mariner.uk.xensource.com, Ian Jackson 
  ian.jack...@eu.citrix.com wrote:  
   But please feel free to explain why I'm wrong.  
   
  You are right. I'm confused about the original logic. The original code 
  doesn't consider this case (size bigger than requested) at all. 
  
 Indeed.  The original code assumes that files don't change size, and 
 only detects them shrinking because that causes a short read which it 
 has deal with somehow. 
  
 But if we are intending to use this with sysfs files, where the 
 reported size is known to be wrong, it seems to me that we should be 
 more proactive.

If only for sysfs files, the bigger size problem should never happens, since 
sysfs
system is not like normal file system, user won't be able to change the size.

Reference from following link:
http://www.makelinux.net/books/lkd2/ch17lev1sec8

[ The sysfs filesystem is an in-memory virtual filesystem that provides a view
of the kobject object hierarchy. It enables users to view the device topology of
their system as a simple filesystem. Using attributes, kobjects can export files
that allow kernel variables to be read from and optionally written to.
..

The show() method is invoked on read. It must copy the value of the attribute
given by attr into the buffer provided by buffer. The buffer is PAGE_SIZE bytes
in length; on x86, PAGE_SIZE is 4096 bytes. The function should return the size
in bytes of data actually written into buffer on success or a negative error
code on failure.

The store() method is invoked on write. It must read the size bytes from buffer
into the variable represented by the attribute attr. The size of the buffer is
always PAGE_SIZE or smaller. The function should return the size in bytes of
data read from buffer on success or a negative error code on failure.]

- Chunyan

  
  So, we need to add a check if (rs == datalen  read end of file), 
  if not, means bigger than requested, report error. 
  
 To detect a growing file it will be necessary to actually attempt to 
 read at least one byte more than expected.  This is probably done most 
 conveniently by making the buffer one byte bigger, too. 
  
 Ian. 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V5 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Chun Yan Liu]

 On 6/25/2015 at 07:09 PM, in message
21899.57676.368102.982...@mariner.uk.xensource.com, Ian Jackson
ian.jack...@eu.citrix.com wrote: 
 Chunyan Liu writes ([PATCH V5 2/7] libxl_read_file_contents: add new entry  
 to read sysfs file): 
  Sysfs file has size=4096 but actual file content is less than that. 
  Current libxl_read_file_contents will treat it as error when file size 
  and actual file content differs, so reading sysfs file content with 
  this function always fails. 
   
  Add a new entry libxl_read_sysfs_file_contents to handle sysfs file 
  specially. It would be used in later pvusb work. 
  
 I think this still fails to detect a situation where the file is 
 unexpectedly longer than the requested size ? 


+} else if (feof(f)) {
+if (rs  datalen  tolerate_shrinking_file) {
+datalen = rs;
+} else {

If the file is bigger than the requested size, it will fall to this branch and 
report error.
Do you mean I should report another error message separately?

- Chunyan

+LOG(ERROR, %s changed size while we were reading it,
+filename);
+goto xe;
+}
+} else {

  
 As we wrote earlier: 
  
Is there any risk that the file is actually bigger than advertised,  
rather than smaller ?  

   For sysfs file, couldn't be bigger. 
   
  Then you should detect the condition that the file is bigger, and call 
  it an error. 
  
 Thanks, 
 Ian. 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V5 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Chun Yan Liu]

 On 6/25/2015 at 07:09 PM, in message
21899.57676.368102.982...@mariner.uk.xensource.com, Ian Jackson
ian.jack...@eu.citrix.com wrote: 
 Chunyan Liu writes ([PATCH V5 2/7] libxl_read_file_contents: add new entry  
 to read sysfs file): 
  Sysfs file has size=4096 but actual file content is less than that. 
  Current libxl_read_file_contents will treat it as error when file size 
  and actual file content differs, so reading sysfs file content with 
  this function always fails. 
   
  Add a new entry libxl_read_sysfs_file_contents to handle sysfs file 
  specially. It would be used in later pvusb work. 
  
 I think this still fails to detect a situation where the file is 
 unexpectedly longer than the requested size ? 


+} else if (feof(f)) {
+if (rs  datalen  tolerate_shrinking_file) {
+datalen = rs;
+} else {

If the file is bigger than the requested size, it will fall to this branch and 
report error.
Do you mean I should report another error message separately?

- Chunyan

+LOG(ERROR, %s changed size while we were reading it,
+filename);
+goto xe;
+}
+} else {

  
 As we wrote earlier: 
  
Is there any risk that the file is actually bigger than advertised,  
rather than smaller ?  

   For sysfs file, couldn't be bigger. 
   
  Then you should detect the condition that the file is bigger, and call 
  it an error. 
  
 Thanks, 
 Ian. 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 6/16/2015 at 01:47 AM, in message 557f0fa7.2060...@eu.citrix.com, 
 George
Dunlap george.dun...@eu.citrix.com wrote: 
 On 06/10/2015 04:20 AM, 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: Chunyan Liu cy...@suse.com 
  Signed-off-by: Simon Cao caobosi...@gmail.com 
   
  --- 
  changes: 
- make libxl_device_usbctrl_add async, to be consistent with 
  libxl_device_usbctrl_remove, using MACROs DEFINE_DEVICE_ADD 
  and DEFINE_DEVICES_ADD, adjusting related codes. 
- correct update_json related processing. 
- use libxl__* helper functions instead of calloc, realloc 
  and strdup, etc. whereever possible. 
- merge protocol definition pv|qemu in this patch 
- treat it as warning at rebind failure instead of error in usb_remove 
- add documentation docs/misc/pvusb.txt to describe pvusb 
  details (toolstack design, libxl design, xenstore info, etc.) 
- other fixes addring Wei and George's comments 
   
   docs/misc/pvusb.txt  |  243 +++ 
   tools/libxl/Makefile |2 +- 
   tools/libxl/libxl.c  |6 + 
   tools/libxl/libxl.h  |   65 ++ 
   tools/libxl/libxl_internal.h |   16 +- 
   tools/libxl/libxl_osdeps.h   |   13 + 
   tools/libxl/libxl_pvusb.c| 1249  
 ++ 
   tools/libxl/libxl_types.idl  |   52 ++ 
   tools/libxl/libxl_types_internal.idl |1 + 
   tools/libxl/libxl_utils.c|   16 + 
   10 files changed, 1661 insertions(+), 2 deletions(-) 
   create mode 100644 docs/misc/pvusb.txt 
   create mode 100644 tools/libxl/libxl_pvusb.c 
   
  diff --git a/docs/misc/pvusb.txt b/docs/misc/pvusb.txt 
  new file mode 100644 
  index 000..4cdf965 
  --- /dev/null 
  +++ b/docs/misc/pvusb.txt 
  @@ -0,0 +1,243 @@ 
  +1. Overview 
  + 
  +There are two general methods for passing through individual host 
  +devices to a guest. The first is via an emulated USB device 
  +controller; the second is PVUSB. 
  + 
  +Additionally, there are two ways to add USB devices to a guest: via 
  +the config file at domain creation time, and via hot-plug while the VM 
  +is running. 
  + 
  +* Emulated USB 
  + 
  +In emulated USB, the device model (qemu) presents an emulated USB 
  +controller to the guest. The device model process then grabs control 
  +of the device from domain 0 and and passes the USB commands between 
  +the guest OS and the host USB device. 
  + 
  +This method is only available to HVM domains, and is not available for 
  +domains running with device model stubdomains. 
  + 
  +* PVUSB 
  + 
  +PVUSB uses a paravirtialized front-end/back-end interface, similar to 
  +the traditional Xen PV network and disk protocols. In order to use 
  +PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
  +your USB driver domain). 
  + 
  +Additionally, for easy use of PVUSB, you need support in the toolstack 
  +to get the two sides to talk to each other. 
  
 I think this paragraph is probably unnecessary.  By the time this is 
 checked in, the toolstack will have the necessary support. 
  
  +2. Specifying a host USB device 
  + 
  +QEMU hmp commands allows USB devices to be specified either by their 
  
 s/hmp/qmp/; ? 
  
  +bus address (in the form bus.device) or their device tag (in the form 
  +vendorid:deviceid). 
  + 
  +Each way of specifying has its advantages: 
  + 
  +Specifying by device tag will always get the same device, 
  +regardless of where the device ends up in the USB bus topology. 
  +However, if there are two identical devices, it will not allow you to 
  +specify which one. 
  + 
  +Specifying by bus address will always allow you to choose a 
  +specific device, even if you have duplicates. However, the bus address 
  +may change depending on which port you plugged the device into, and 
  +possibly also after a reboot. 
  + 
  +To avoid duplication of vendorid:deviceid, we'll use bus address to 
  +specify host USB device in xl toolstack. 
  
 This paragraph comparing the different ways of specifying devices makes 
 sense to include in the 0/N series summary, but not so much in a file 
 we're checking in. 
  
  + 
  +You can use lsusb to list the USB devices on the system: 
  + 
  +Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 
  +Hub 
  +Bus 003 Device 002: ID f617:0905 
  +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
  +Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0 
  +Hub 
  +Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra 
  +Fast Media Reader 
  +Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse 
  + 
  +To pass through the Logitec mouse, for instance, you could specify 
  +1.6 

Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 6/23/2015 at 07:29 PM, in message 558942ff.5060...@eu.citrix.com, 
 George
Dunlap george.dun...@eu.citrix.com wrote: 
 On 06/23/2015 11:18 AM, Chun Yan Liu wrote: 
 On 6/16/2015 at 01:47 AM, in message 557f0fa7.2060...@eu.citrix.com, 
 George 
  Dunlap george.dun...@eu.citrix.com wrote:  
  +static int libxl__device_usb_setdefault(libxl__gc *gc, uint32_t domid,  
  +libxl_device_usb *usb,  
  +bool update_json)  
  +{  
  +char *be_path, *tmp;  
  +  
  +if (usb-ctrl == -1) {  
  +int ret = libxl__device_usb_set_default_usbctrl(gc, domid, usb); 
   
  +/* If no existing ctrl to host this usb device, setup a new one 
  */  
  
  +if (ret) {  
  +libxl_device_usbctrl usbctrl;  
  +libxl_device_usbctrl_init(usbctrl);  
  +if (libxl_device_usbctrl_add_common(CTX, domid, usbctrl,  
  +0, update_json)) {  
  +LOG(ERROR, Failed to create usb controller);  
  +return ERROR_INVAL;  
  +}  
  +usb-ctrl = usbctrl.devid;  
  +usb-port = 1;  
  +libxl_device_usbctrl_dispose(usbctrl);  
  +}  
  +}  

  Sorry for not noticing this before -- it  looks like if you set  
  usb-ctrl to -1, it will automatically choose both a controller and a  
  port number.  But what if you want to specify that you want a particular  
  controller (for example, if you want to specify the PV controller rather  
  than the emulated one, or vice versa), but didn't want to have to  
  manually keep track of which ports were free? 
   
  That is libxl__device_usb_set_default_usbctrl's work, it will try to find 
  an available port for USB device. If there is no available port, then it  
 will 
  create a new USB controller and by default uses its first port. 

  It seems like it would be better to have the code treat port 0 as  
  automatically choose a port for me.  
   
  Here we set port=1 because port number is starting from 1. Like, if there 
  are 4 ports, port number will be 1, 2, 3, 4 (not 0,1 ,2, 3). Since xend, it 
  behaves like this. I think that's what pvusb driver needs. Juergen, right? 
  
 I think you misunderstood what I was saying. 
  
 There are three cases I think we want to consider: 
  
 1. The caller knows both the controller and the port number they want to 
 assign it to. 
  
 2. The caller knows what controller they want to assign it to, but they 
 want libxl to choose the port number automatically. 
  
 3. The caller wants libxl to choose both the controller and the port 
 automatically. 
   3a. A controller already exists with a free port 
   3b. No controllers with free ports exist. 
  
 Your code handles #1 properly -- if both controller and port number are 
 set, it will try to add the USB device to that specific controller and 
 port number. 
  
 Your code also handles #3a properly -- if the controller is not set, it 
 will automatically choose a controller and a port number.  It also 
 handles #3b properly -- if there are no controllers, or if the 
 controllers have no ports available, then it will create a new one and 
 assign it to port 1. 
  
 Your code does not, however, handle the second case -- where the user 
 knows they want to plug it into a specific controller (for instance, the 
 PVUSB one rather than the emulated one), but don't want to keep track of 
 which ports are available. 
  
 Since ports start as 1, then '0' is an invalid number for a port (just 
 as -1 is an invalid id for a controller).  I was suggesting that you 
 could use '0' as a magic number meaning, Please choose a port for me. 

Oh, I see. Thanks for explanation. This IS what we didn't cover, currently only
support either specifying both controller and port, or both not. If user 
specifies
controller and port, then we will use that controller and port, if it's not 
available,
we just report error, but won't choose a default available one for it. Choosing
a port or creating a new controller only happens when use doesn't specify
controller and port.

I think case 2 is very useful. I will update code to cover.

  
 However, after our discussion here about providing helpers to 
 translate stuff for the libxl interface, if the other maintainers will 
 like the automatically create a controller functionality at all; or if 
 they would rather we (again) provide helper functions so that the 
 toolstack can do this work. 
  
  +static int libxl__device_usb_remove(libxl__gc *gc, uint32_t domid,  
  +libxl_device_usb *usb)  
  +{  
  +libxl_device_usb *usbs = NULL;  
  +libxl_device_usb *usb_find = NULL;  
  +int i, num = 0, rc;  
  +  
  +assert(usb-busid || (usb-hostbus  0  usb-hostaddr  0));  
  +  
  +if (!usb-busid) {  
  +usb-busid = usb_busaddr_to_busid(gc, usb-hostbus, 
  usb

[Xen-devel] Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API)

[Chun Yan Liu]

 On 6/22/2015 at 09:29 PM, in message 55880dcc.6070...@eu.citrix.com, 
 George
Dunlap george.dun...@eu.citrix.com wrote: 
 On 06/18/2015 01:08 PM, George Dunlap wrote: 
  This usb interface stuff is really becoming a morass.  The core 
  functionality is fairly independent of the interface.  I'm inclined to 
  say that we should start with a simple specification (only bus.addr), 
  and try to get both pvusb and hvmusb in.  Then we can talk about where 
  to add additional specifications (including cross-boot stable 
  specifcations). 
  
 So Ian J, Ian C, Wei and I chatted face-to-face about what to do going 
 forward; below are some key points we discussed and the conclusion we 
 came to.  Decisions are only official when they've been discussed on the 
 list, so please consider this a proposal and give your feedback. :-) 
  
 (Also, Ian/Ian/Wei, let me know if I've misremembered or forgotten 
 something.) 
  
 Points of discussion: 
  
 * We would ideally like to be able to have the released interface work 
 both for both PV and HVM; for one so that we don't have to have separate 
 #defines for that functionality; but also to make sure that the 
 interface is suitable for both functionalities. 
  
 * It's difficult at the moment to actually do collaborative development 
 on the libxl USB feature, because the code is not yet in the tree. 
  
 * Regarding user-facing interfaces (like xl, as opposed to libxl): the 
 interface cannot be half-baked; it should not provide functionality 
 which works most of the time but sometimes will fail. 
  
 Having only bus-ports or vendorid:deviceid is not sufficient, 
 because it will lure the user into thinking that they can put those 
 numbers into a config file and get repeatable results every time.  But 
 since bus numbers change, and vendorid:deviceid is not unique, either of 
 these would be a false promise. 
  
 Udevs ID_PATH naming scheme seems like a sensible thing to adopt, at 
 least for Linux.  We could consider making an OS-specific string for 
 identifying the same device across reboots. 
  
 On the other hand, bus.address is very obviously unstable; nobody in 
 their right mind would use it for anything they wanted to persist across 
 reboots.  So including bus.address as a temporary measure to be able to 
 test the underlying library until we get a more reliable naming scheme 
 in place would be OK, as long as the UI interface could be extended 
 going forward. 
  
 * We should avoid adding complexity to the libxl interface until it's 
 needed; accepting one way of specifying USB devices, and letting the 
 toolstack do translation into that way of specifying it (perhaps 
 providing helper libraries to do so), should be enough for now.  The way 
 of specifying USB devices does not need to be stable across reboots, as 
 long as it won't change between the time the toolstack does the 
 translation and the time the device is plugged in. 
  
 bus.address is the best specification from that point of view: it's 
 unique (unlike device:vendorid), and if a device is unplugged and 
 another one plugged in between the time the translation happens and the 
 time libxl gets around to doing something, the old bus.address won't 
 exist anymore and the command will fail. 
  
 * There may be a point in the future when we want to be able provide 
 device auto-plug functionality at the libxl layer.  (i.e., When device 
 X shows up, please plug it into VM Y.)  For this we will need a 
 reliable way of specifying devices; bus.address will not do. 
  
 But that functionality doesn't exist yet; so for now we should stick 
 with bus.address, but design the interface such that it can be extended 
 with more options for specifying a device when such functionality is neede. 
  
 With all that in mind, here is a proposal: 
  
 1. For the moment, only use bus.address at the libxl layer to specify a 
 device. 
  
 2. Let's check in the libxl part of Chunyan's PVUSB series as soon as 
 the 4.7 development window opens (assuming the coding style issues have 
 all been addressed).  We can also check in the xl functionality with 
 minimal bus.address support for testing. 
  
 3. I will the port the HVM USB series and submit them as soon as possible. 
  
 4. We work on a set of helper functions that a toolstack can use to 
 translate other ways of specifying a device, much like the disk 
 specification helper functions that we provide.  One of these should be 
 something which is reliably stable over reboots, such as the udev 
 ID_PATH specification. 
  
 Thoughts? 

Fine to me.

  
  -George 
  
  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API)

[Chun Yan Liu]

 On 6/22/2015 at 09:29 PM, in message 55880dcc.6070...@eu.citrix.com, 
 George
Dunlap george.dun...@eu.citrix.com wrote: 
 On 06/18/2015 01:08 PM, George Dunlap wrote: 
  This usb interface stuff is really becoming a morass.  The core 
  functionality is fairly independent of the interface.  I'm inclined to 
  say that we should start with a simple specification (only bus.addr), 
  and try to get both pvusb and hvmusb in.  Then we can talk about where 
  to add additional specifications (including cross-boot stable 
  specifcations). 
  
 So Ian J, Ian C, Wei and I chatted face-to-face about what to do going 
 forward; below are some key points we discussed and the conclusion we 
 came to.  Decisions are only official when they've been discussed on the 
 list, so please consider this a proposal and give your feedback. :-) 
  
 (Also, Ian/Ian/Wei, let me know if I've misremembered or forgotten 
 something.) 
  
 Points of discussion: 
  
 * We would ideally like to be able to have the released interface work 
 both for both PV and HVM; for one so that we don't have to have separate 
 #defines for that functionality; but also to make sure that the 
 interface is suitable for both functionalities. 
  
 * It's difficult at the moment to actually do collaborative development 
 on the libxl USB feature, because the code is not yet in the tree. 
  
 * Regarding user-facing interfaces (like xl, as opposed to libxl): the 
 interface cannot be half-baked; it should not provide functionality 
 which works most of the time but sometimes will fail. 
  
 Having only bus-ports or vendorid:deviceid is not sufficient, 
 because it will lure the user into thinking that they can put those 
 numbers into a config file and get repeatable results every time.  But 
 since bus numbers change, and vendorid:deviceid is not unique, either of 
 these would be a false promise. 
  
 Udevs ID_PATH naming scheme seems like a sensible thing to adopt, at 
 least for Linux.  We could consider making an OS-specific string for 
 identifying the same device across reboots. 
  
 On the other hand, bus.address is very obviously unstable; nobody in 
 their right mind would use it for anything they wanted to persist across 
 reboots.  So including bus.address as a temporary measure to be able to 
 test the underlying library until we get a more reliable naming scheme 
 in place would be OK, as long as the UI interface could be extended 
 going forward. 
  
 * We should avoid adding complexity to the libxl interface until it's 
 needed; accepting one way of specifying USB devices, and letting the 
 toolstack do translation into that way of specifying it (perhaps 
 providing helper libraries to do so), should be enough for now.  The way 
 of specifying USB devices does not need to be stable across reboots, as 
 long as it won't change between the time the toolstack does the 
 translation and the time the device is plugged in. 
  
 bus.address is the best specification from that point of view: it's 
 unique (unlike device:vendorid), and if a device is unplugged and 
 another one plugged in between the time the translation happens and the 
 time libxl gets around to doing something, the old bus.address won't 
 exist anymore and the command will fail. 
  
 * There may be a point in the future when we want to be able provide 
 device auto-plug functionality at the libxl layer.  (i.e., When device 
 X shows up, please plug it into VM Y.)  For this we will need a 
 reliable way of specifying devices; bus.address will not do. 
  
 But that functionality doesn't exist yet; so for now we should stick 
 with bus.address, but design the interface such that it can be extended 
 with more options for specifying a device when such functionality is neede. 
  
 With all that in mind, here is a proposal: 
  
 1. For the moment, only use bus.address at the libxl layer to specify a 
 device. 
  
 2. Let's check in the libxl part of Chunyan's PVUSB series as soon as 
 the 4.7 development window opens (assuming the coding style issues have 
 all been addressed).  We can also check in the xl functionality with 
 minimal bus.address support for testing. 
  
 3. I will the port the HVM USB series and submit them as soon as possible. 
  
 4. We work on a set of helper functions that a toolstack can use to 
 translate other ways of specifying a device, much like the disk 
 specification helper functions that we provide.  One of these should be 
 something which is reliably stable over reboots, such as the udev 
 ID_PATH specification. 
  
 Thoughts? 

Fine to me.

  
  -George 
  
  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 6/17/2015 at 07:34 PM, in message 
 1434540857.13744.334.ca...@citrix.com,
Ian Campbell ian.campb...@citrix.com wrote: 
 On Tue, 2015-06-16 at 16:20 +0200, Juergen Gross wrote: 
  My point was to avoid the sysfs accesses in libxl in order to support 
  BSD as well and to reduce the complexity. 
  
 As a slight aside to this, can't libxl use libusb for a lot of this 
 stuff and therefore avoid being Linux specific? 
  
 http://libusb.info/ claims to support Linux, OS X, Windows, Windows CE, 
 Android, OpenBSD/NetBSD, Haiku.. Interestingly FreeBSD is missing there 
 but I don't think that need to be a blocker. 
  
 I don't see a problem with adding libusb to our set of dependencies, and 
 it's certainly got to be better than (re)implementing a bunch of sysfs 
 stuff (which I presume is what libusb does under the hood anyway). 

Using libusb is certainly good and can save effort to implement things by
ourself. Only one concern: some functions require newer version of libusb.
For example, functions to get port (quite like busid) information
libusb_get_port_numbers or libusb_get_port_path need
libusb version = 1.0.12. If libusb version is not satisfied, the whole pvusb
work might be blocked.

- Chunyan


  
 Ian. 
  
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages]

[Chun Yan Liu]

 On 6/17/2015 at 06:27 PM, in message 55814b9f.6070...@eu.citrix.com, 
 George
Dunlap george.dun...@eu.citrix.com wrote: 
 On 06/17/2015 04:59 AM, Juergen Gross wrote: 
  On 06/16/2015 06:34 PM, George Dunlap wrote: 
  On Tue, Jun 16, 2015 at 4:59 PM, Ian Jackson 
  ian.jack...@eu.citrix.com wrote: 
  George Dunlap writes (Re: [Xen-devel] [PATCH V4 3/7] libxl: add 
  pvusb API [and 1 more messages]): 
  Yes.  The whole point of paths like this is that they are stable if 
  the physical topology doesn't change.  So on my netbook 
  
 /dev/disk/by-path/pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1 
  
  always refers to the 1st MBR partition on logical device 0 on the USB 
  storage device plugged into the USB port physically on the front left 
  of the computer. 
  
  That would be great if it were true, but I'm not convinced that the 
  above path doesn't include a globally-enumerated bus number, which 
  might 
  change across reboots if it's enumerated in a different order. 
  
  It may be that the format above is *not* based on the sysfs path of the 
  device; that the '0' immediately after the USB means the first (and 
  perhaps only) controller at this PCI address.  In which case, yes, 
  having a string like this might be a unique identifier for a particular 
  port that would be stable across reboots.  That needs some 
  investigation. 
  
  That does seem to be the case: 
  
  What seems to be the case -- that it contains the global bus, or not? 
  
  Looking at the output of udevadm monitor --property for sdc1 (on 
  another plug): 
  
   
 DEVPATH=/devices/pci:00/:00:1d.7/usb1/1-1/1-1:1.0/host22/target22:0:0 
 /22:0:0:0/block/sdc/sdc1 
  
  ID_PATH=pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0 
  ID_PATH_TAG=pci-_00_1d_7-usb-0_1_1_0-scsi-0_0_0_0 
  
  I don't know where that ID_PATH comes from. 
  
  It looks like that's constructed in udev: 
  
   
 http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-path_i 
 d.c 
  
  
  See handle_usb() (line 542) in particular. 
  
  If I'm reading it right, what it basically does it take the 
  [bus]-[port], and replace it with usb-0:[port].  (IOW, the '0' is 
  hard-coded.) 
  
  Also, if I'm reading it right, this won't work properly for Juergen's 
  system that has two USB devices at the same pci address -- they'll 
  both end up resolving to [pciaddr]-usb-0:[whatever]. 
  
  Juergen -- can you give this a try?  Run udevadm info on the two USB 
  busses that share the same PCI slot, and see if the ID_PATH is the 
  same for both? 
   
  This was the correct question. :-) 
   
  The ID_PATH is the same, but: 
   
  It turns out that the two busses are for one physical hcd. One is the 
  bus for USB 3.0, the other one for USB 2.0. I guess the bus is just 
  selected by the capability of the plugged in device. 
   
  So the [port] in usb-0:[port] is unique across the two logical 
  busses. 
  
 Right -- I think I had come to the conclusion that would probably be the 
 case later yesterday evening.  Glad to  have it confirmed. 
  
 So in addition to our other identifiers, stealing udev's naming scheme 
 should work, and would be useful. 
  
 The next challenge would be how to implement it effectively.  It's 
 already udev's job to make sure that a string is unique -- as much as 
 possible we want to leverage their efforts, rather than re-implementing 
 our own. 
  
 One thing that Ian suggested was that we could add a udev rule that 
 would create links from the ID_PATH of the usb device into the sysfs 
 device node.  (Both seem to be available in the udev rule environment.) 
  That would allow us to easily translate the ID_PATH into the other 
 things we might want (bus-port, bus.addr, c) and vice versa. 
  
 But I think all that will certainly not be done by the feature freeze. 
  
 The core functionality of Chunyan's series, wrt the pvusb functionality 
 is complete; as with my HVM series before, it's mainly the interface 
 that is being discussed. 
  
 There are two options here: Chunyan could try to implement the interface 
 we've been discussing here (assuming that she doesn't have any 
 objections to what we've described);

No, I don't have any objections. I can do that.

- Chunyan

 or, I could take Chunyan's series, 
 try to implement what we've been talking about, and then add in the HVM 
 functionality as well. 
  
 What does everyone think? 
  
  -George 
  
  
  
  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller

[Chun Yan Liu]

 On 6/17/2015 at 07:06 PM, in message 
 1434539195.13744.321.ca...@citrix.com,
Ian Campbell ian.campb...@citrix.com wrote: 
 On Thu, 2015-05-21 at 18:07 +0100, George Dunlap wrote: 
  We have several outstanding patch series which add devices that have 
  two levels: a controller and individual devices attached to that 
  controller. 
   
  In the interest of consistency, this patch introduces a section that 
  sketches out a template for interfaces for such devices. 
  
 Chun Yan and Jeurgen: 
  
 I was hoping we could come to some sort of agreement on this such that 
 it can be used as the basis for both the pvusb and pvscsi interfaces. As 
 such your feedback here is important... 
  
   
  Signed-off-by: George Dunlap george.dun...@eu.citrix.com 
  --- 
  CC: Ian Campbell ian.campb...@citrix.com 
  CC: Ian Jackson ian.jack...@citrix.com 
  CC: Wei Liu wei.l...@citrix.com 
  CC: Juergen Gross jgr...@suse.com 
  CC: Chun Yan Liu cy...@suse.com 
  CC: Olaf Hering o...@aepfle.de 
   
  So, this is definitely RFC -- I tried to spec things out in a way that 
  made sense, but I often just chose something that I thought would be a 
  sensible starting point for discussion. 
   
  This spec looks a lot more like the PVUSB spec than the PVSCSI spec, 
  in part because I think the PVUSB spec has already had a lot more 
  thought that's gone into it. 
   
  A couple of random points to discuss: 
   
  * Calling things controllers, using typectrl for the device name, 
and using ctrl as the field name for the devid of the controller 
in the individual devices. 
   
  * I've said that having an index (port, lun, whatever) is optional. 
Do we want to make that requred?  Do we want it to have a consistent 
name?  In the case of emulated USB, we can't really specify to qemu 
what port the device gets attached to, so I'm tempted to say it's 
not required; but even there we could always give it a port number 
just for name's sake. 
   
  * Naming sub-devices.  We need to have a way to uniquely name both 
controllers and subdevices.  Here I've said that we will have both 
typectrl and type devid namespaces, mainly because in the 
previous point I opted not to require an index.  Another option 
would be not to have another devid namespace, but to use 
ctrl,index as the unique identifier.  (This would mean requiring 
the index/port/lun specification above.) 
   
  * libxl_device_type_list listing devices across all controllers.  I 
think this is the most practical thing to do, but one could imagine 
wanting to query by controller ID instead. 
   
  Feedback welcome. 
  --- 
   tools/libxl/libxl.h | 46 ++ 
   1 file changed, 46 insertions(+) 
   
  diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
  index 2ed7194..d757845 100644 
  --- a/tools/libxl/libxl.h 
  +++ b/tools/libxl/libxl.h 
  @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int  
 nr_vtpms); 
* 
*   This function does not interact with the guest and therefore 
*   cannot block on the guest. 
  + * 
  + * Controllers 
  + * --- 
  + * 
  + * Most devices are treated individually.  Some devices however, like 
  + * USB or SCSI, inherently have the need to have busses or 
  + * controllers to which individual devices can be attached. 
  + * 
  + * In that case, for each type, there will be two sets of the 
  + * functions, types, and devid namespaces outlined above: one based on 
  + * 'type', and one based on 'typectrl'. 
  + * 
  + * In those cases, libxl_device_typectrl_function will act more or 
  + * less like top-level non-bus devices: they will either create or 
  + * accept a libxl_devid which will be unique within the 
  + * typectrl libxl_devid namespace. 
  + * 
  + * Second-level devices which will be attached to a controller will 
  + * include in their libxl_device_type a field called ctrl, which 
  + * will be the libxl_devid of the corresponding controller.  It may also 
  + * include an index onto that bus, that represents (for example) a USB 
  + * port or a SCSI LUN. 
  + * 
  + * These second-level devices will also have their own devid which 
  + * will be unique within the type devid namespace, and will be used 
  + * for queries or removals.

All other description is agreed except here:
For pvusb, currently we uses ctrl, port instead of devid. It seems to be
more straightforward. To add a USB device info to xenstore, it only writes
the USB busid to controller/port. To remove a USB device, just remove
USB busid from xenstore controller/port.

- Chunyan
 
  + * 
  + * In the case where there are multiple different ways to implement a 
  + * given device -- for instance, one which is fully PV and one which 
  + * uses an emulator -- the controller will contain a field which 
  + * specifies what type of implementation is used.  The implementations 
  + * of individual devices will be known

Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 6/12/2015 at 03:39 PM, in message
557afd2f0266000d4...@relay2.provo.novell.com, Chun Yan Liu
cy...@suse.com wrote: 

  
 On 6/12/2015 at 12:42 AM, in message 
 21881.47707.526863.158...@mariner.uk.xensource.com, Ian Jackson 
 ian.jack...@eu.citrix.com wrote:  
  Chunyan Liu writes ([Xen-devel] [PATCH V4 3/7] libxl: add pvusb API):  
   Add pvusb APIs, including:  
  ...  

  Thanks for your contribution.  I'm afraid I haven't had time to  
  completely finish my review this, but here's what I have:  

   --- /dev/null  
   +++ b/docs/misc/pvusb.txt  
   @@ -0,0 +1,243 @@  
   +1. Overview  

  It's good that you have provided documentation.  But I think this  
  document is a bit confused about its audience.  

  Information about design choices should be removed from this user- and  
  application-facing document, and put in comments in the code, or  
  commit messages, I think.  
  
 Thanks. Will update. 
  


   +int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t domid,  
   +libxl_device_usbctrl *usbctrl,  
   +libxl_usbctrlinfo *usbctrlinfo)  
   +LIBXL_EXTERNAL_CALLERS_ONLY;  

  Why is this function marked LIBXL_EXTERNAL_CALLERS_ONLY ?  
  
 Currently libxl itself won't call it. Exposed for toolstack usage. Will 
 remove that if it's not proper. 
  

   diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h  
   index ef7aa1d..89a9f07 100644  
   --- a/tools/libxl/libxl_internal.h  
   +++ b/tools/libxl/libxl_internal.h  
   @@ -2439,6 +2439,18 @@ _hidden void libxl__device_vtpm_add(libxl__egc 
   *egc,  
   
  uint32_t domid,  
  ...  
   +/* AO operation to connect a PVUSB controller.  
   + * Adding a PVUSB controller will add a 'vusb' device entry in xenstore, 

   + * and will wait for device connection.  

  In this context I think will wait for device connection is  
  misleading.  What you mean is that the vusb is available for adding  
  devices to, but won't have any yet.  Nothing in libxl is waiting.  
  
 Here I mean libxl_wait_for_device_connection. Since it adds a new device  
 entry 
 to xenstore, it needs to wait for a moment for frontend/backend connection. 
  

   diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c  
   new file mode 100644  
   index 000..a6e1aa1  
   --- /dev/null  
   +++ b/tools/libxl/libxl_pvusb.c  
   @@ -0,0 +1,1249 @@  
  ...  
   +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid,  
   +   libxl_device_usbctrl *usbctrl,  
   +   libxl__ao_device *aodev)  
   +{  
   +STATE_AO_GC(aodev-ao);  
  ...  
   +libxl_domain_config_init(d_config);  
   +libxl_device_usbctrl_init(usbctrl_saved);  
   +libxl_device_usbctrl_copy(CTX, usbctrl_saved, usbctrl);  

  Wei will need to review the saved/live saved device info handling, and  
  the json, etc.  

   +static int  
   +libxl_device_usbctrl_remove_common(libxl_ctx *ctx, uint32_t domid,  
   +   libxl_device_usbctrl *usbctrl,  
   +   const libxl_asyncop_how *ao_how,  
   +   int force)  

  As discussed, you mustn't call this within libxl. 
 I don't quite understand why. I guess it's the same as usb_add problem, 
 something related to embedded ao? 
 As in usb_add: 
 libxl_device_usb_add() 
AO_CREATE(ctx, domid, ao_how) 
libxl__device_usb_add() 
  libxl__device_usb_setdefault() 
libxl_device_usbctrl_add_common() 
  AO_CREATE(ctx, domid, NULL) 
 if this is not allowed, what is the correct way? 

Saw the discussion thread and got it. Will update the codes.

  
  If you need to, you  
  need to break it out into an internal function  
  (libxl__initiate_device_usbctrl_remove, maybe) which makes a callback  
  when done. 

   +libxl_device_usbctrl *  
   +libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num)  
   +{  
   +GC_INIT(ctx);  
   +libxl_device_usbctrl *usbctrls = NULL;  
   +char *fe_path = NULL;  
   +char **dir = NULL;  
   +unsigned int ndirs = 0;  
   +  
   +*num = 0;  
   +  
   +fe_path = GCSPRINTF(%s/device/vusb,  
   +libxl__xs_get_dompath(gc, domid));  
   +dir = libxl__xs_directory(gc, XBT_NULL, fe_path, ndirs);  
   +  
   +if (dir  ndirs) {  
   +usbctrls = malloc(sizeof(*usbctrls) * ndirs);  

  Please use libxl__calloc with NOGC.  
  
 Thanks. Missing this one. 
  

   +libxl_device_usbctrl* usbctrl;  
   +libxl_device_usbctrl* end = usbctrls + ndirs;  
   +for (usbctrl = usbctrls; usbctrl  end; usbctrl++, dir++,  
 (*num)++)   
  {  
   +char *tmp;  
   +const char *be_path = libxl__xs_read(gc, XBT_NULL

Re: [Xen-devel] [PATCH V4 5/7] xl: add pvusb commands

[Chun Yan Liu]

 On 6/12/2015 at 03:37 PM, in message 557a8c57.1040...@suse.com, Juergen 
 Gross
jgr...@suse.com wrote: 
 On 06/10/2015 05:20 AM, Chunyan Liu wrote: 
  Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list, 
  usb-attach and usb-detach. 
  
  To attach a usb device to guest through pvusb, one could follow 
  following example: 
  
#xl usb-ctrl-attach test_vm version=1 num_ports=8 
  
#xl usb-list test_vm 
will show the usb controllers and port usage under the domain. 
  
#xl usb-assignable-list 
will list assignable USB devices 
  
 xl usb-assignable-list is not part of this patch. Either merge this 
 patch and the following one, or describe the command in the next patch. 

Oh, yes, I forget to split.

  
  
#xl usb-attach test_vm 1.6 
will find the first usable controller:port, and attach usb 
device whose bus address is 1.6 (busnum is 1, devnum is 6) 
to it. One could also specify which controller and which port. 
  
#xl usb-detach test_vm 1.6 
  
#xl usb-ctrl-detach test_vm dev_id 
will destroy the controller with specified dev_id. Dev_id 
can be traced in usb-list info. 
  
  Signed-off-by: Chunyan Liu cy...@suse.com 
  Signed-off-by: Simon Cao caobosi...@gmail.com 
  --- 
docs/man/xl.pod.1 |  38 +++ 
tools/libxl/xl.h  |   5 + 
tools/libxl/xl_cmdimpl.c  | 251  
 ++ 
tools/libxl/xl_cmdtable.c |  25 + 
4 files changed, 319 insertions(+) 
  
  
 ... 
  
  diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c 
  index c858068..b29d0fc 100644 
  --- a/tools/libxl/xl_cmdimpl.c 
  +++ b/tools/libxl/xl_cmdimpl.c 
  @@ -3219,6 +3219,257 @@ int main_cd_insert(int argc, char **argv) 
return 0; 
} 
  
  +static void usbinfo_print(libxl_device_usb *usbs, int num) { 
  +int i; 
  
 Blank line missing. 
  
  +if (usbs == NULL) 
  + return; 
  +for (i = 0; i  num; i++) { 
  +libxl_usbinfo usbinfo; 
  
 Blank line missing. 
  
  +libxl_usbinfo_init(usbinfo); 
  + 
  +if (usbs[i].port) 
  +printf(  Port %d:, usbs[i].port); 
  +if (!libxl_device_usb_getinfo(ctx, usbs[i], usbinfo)) { 
  +printf( Bus %03x Device %03x: ID %04x:%04x %s %s\n, 
  +usbinfo.busnum, usbinfo.devnum, 
  +usbinfo.idVendor, usbinfo.idProduct, 
  +usbinfo.manuf ?: , usbinfo.prod ?: ); 
  
 Is it really possible for a device to be assigned but without a port 
 number? 

For assigned usb device, it's not possible. But this function will be called
in two places, one is to list assigned usb devices in 'xl usb-list'; another
is to list assignable usb devices in 'xl usb-assignable-list'. If
'usb-assignable-list' is not taken, this could be improved.

  
 I'd rather combine the two if's and printf statements. This would avoid 
 the case where   Port 1: Port 2: ... is printed due to a failing 
 libxl_device_usb_getinfo() for port 1. 
  
  +} 
  +libxl_usbinfo_dispose(usbinfo); 
  +} 
  +} 
  + 
  +int main_usbctrl_attach(int argc, char **argv) 
  +{ 
  +uint32_t domid; 
  +int opt; 
  +char *oparg; 
  +libxl_device_usbctrl usbctrl; 
  + 
  +SWITCH_FOREACH_OPT(opt, , NULL, usb-ctrl-attach, 1) { 
  +/* No options */ 
  +} 
  + 
  +domid = find_domain(argv[optind++]); 
  + 
  +libxl_device_usbctrl_init(usbctrl); 
  + 
  +while (argc  optind) { 
  +if (MATCH_OPTION(type, argv[optind], oparg)) { 
  +if (!strcmp(oparg, pv)) { 
  +   usbctrl.protocol = LIBXL_USB_PROTOCOL_PV; 
  +} else { 
  +   fprintf(stderr, unsupported type `%s'\n, oparg); 
  +   exit(-1); 
  +} 
  +} else if (MATCH_OPTION(version, argv[optind], oparg)) { 
  +usbctrl.version = atoi(oparg); 
  
 Shouldn't you check for valid versions? 

OK. Will check.

  
  +} else if (MATCH_OPTION(ports, argv[optind], oparg)) { 
  +usbctrl.ports = atoi(oparg); 
  
 Same here for number of ports. Otherwise you could blow up xenstore by 
 e.g. specifying 2 billion ports here. 

Will add check. What's the supported max ports? 

  
  +} else { 
  +fprintf(stderr, unrecognized argument `%s'\n, argv[optind]); 
  +exit(-1); 
  +} 
  +optind++; 
  +} 
  + 
  +if (usbctrl.protocol == LIBXL_USB_PROTOCOL_AUTO) 
  +usbctrl.protocol = LIBXL_USB_PROTOCOL_PV; 
  
 Is this really necessary? You do it in libxl, too. 
Yes, seems not necessary. Anyway (from config file or hotplug), it will
call libxl_device_usbctrl_setdefault and do that.

Thanks,
Chunyan
  
  
 Juergen 
  
 ___ 
 Xen-devel mailing list 
 Xen-devel@lists.xen.org 
 http://lists.xen.org/xen-devel 
  
  


___
Xen-devel mailing list

Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[Chun Yan Liu]

 On 6/12/2015 at 12:42 AM, in message
21881.47707.526863.158...@mariner.uk.xensource.com, Ian Jackson
ian.jack...@eu.citrix.com wrote: 
 Chunyan Liu writes ([Xen-devel] [PATCH V4 3/7] libxl: add pvusb API): 
  Add pvusb APIs, including: 
 ... 
  
 Thanks for your contribution.  I'm afraid I haven't had time to 
 completely finish my review this, but here's what I have: 
  
  --- /dev/null 
  +++ b/docs/misc/pvusb.txt 
  @@ -0,0 +1,243 @@ 
  +1. Overview 
  
 It's good that you have provided documentation.  But I think this 
 document is a bit confused about its audience. 
  
 Information about design choices should be removed from this user- and 
 application-facing document, and put in comments in the code, or 
 commit messages, I think. 

Thanks. Will update.

  
  
  +int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t domid, 
  +libxl_device_usbctrl *usbctrl, 
  +libxl_usbctrlinfo *usbctrlinfo) 
  +LIBXL_EXTERNAL_CALLERS_ONLY; 
  
 Why is this function marked LIBXL_EXTERNAL_CALLERS_ONLY ? 

Currently libxl itself won't call it. Exposed for toolstack usage. Will
remove that if it's not proper.

  
  diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h 
  index ef7aa1d..89a9f07 100644 
  --- a/tools/libxl/libxl_internal.h 
  +++ b/tools/libxl/libxl_internal.h 
  @@ -2439,6 +2439,18 @@ _hidden void libxl__device_vtpm_add(libxl__egc *egc, 
   
 uint32_t domid, 
 ... 
  +/* AO operation to connect a PVUSB controller. 
  + * Adding a PVUSB controller will add a 'vusb' device entry in xenstore, 
  + * and will wait for device connection. 
  
 In this context I think will wait for device connection is 
 misleading.  What you mean is that the vusb is available for adding 
 devices to, but won't have any yet.  Nothing in libxl is waiting. 

Here I mean libxl_wait_for_device_connection. Since it adds a new device entry
to xenstore, it needs to wait for a moment for frontend/backend connection.

  
  diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c 
  new file mode 100644 
  index 000..a6e1aa1 
  --- /dev/null 
  +++ b/tools/libxl/libxl_pvusb.c 
  @@ -0,0 +1,1249 @@ 
 ... 
  +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid, 
  +   libxl_device_usbctrl *usbctrl, 
  +   libxl__ao_device *aodev) 
  +{ 
  +STATE_AO_GC(aodev-ao); 
 ... 
  +libxl_domain_config_init(d_config); 
  +libxl_device_usbctrl_init(usbctrl_saved); 
  +libxl_device_usbctrl_copy(CTX, usbctrl_saved, usbctrl); 
  
 Wei will need to review the saved/live saved device info handling, and 
 the json, etc. 
  
  +static int 
  +libxl_device_usbctrl_remove_common(libxl_ctx *ctx, uint32_t domid, 
  +   libxl_device_usbctrl *usbctrl, 
  +   const libxl_asyncop_how *ao_how, 
  +   int force) 
  
 As discussed, you mustn't call this within libxl.
I don't quite understand why. I guess it's the same as usb_add problem,
something related to embedded ao?
As in usb_add:
libxl_device_usb_add()
   AO_CREATE(ctx, domid, ao_how)
   libxl__device_usb_add()
 libxl__device_usb_setdefault()
   libxl_device_usbctrl_add_common()
 AO_CREATE(ctx, domid, NULL)
if this is not allowed, what is the correct way?

 If you need to, you 
 need to break it out into an internal function 
 (libxl__initiate_device_usbctrl_remove, maybe) which makes a callback 
 when done.
  
  +libxl_device_usbctrl * 
  +libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num) 
  +{ 
  +GC_INIT(ctx); 
  +libxl_device_usbctrl *usbctrls = NULL; 
  +char *fe_path = NULL; 
  +char **dir = NULL; 
  +unsigned int ndirs = 0; 
  + 
  +*num = 0; 
  + 
  +fe_path = GCSPRINTF(%s/device/vusb, 
  +libxl__xs_get_dompath(gc, domid)); 
  +dir = libxl__xs_directory(gc, XBT_NULL, fe_path, ndirs); 
  + 
  +if (dir  ndirs) { 
  +usbctrls = malloc(sizeof(*usbctrls) * ndirs); 
  
 Please use libxl__calloc with NOGC. 

Thanks. Missing this one.

  
  +libxl_device_usbctrl* usbctrl; 
  +libxl_device_usbctrl* end = usbctrls + ndirs; 
  +for (usbctrl = usbctrls; usbctrl  end; usbctrl++, dir++, 
  (*num)++)  
 { 
  +char *tmp; 
  +const char *be_path = libxl__xs_read(gc, XBT_NULL, 
  +GCSPRINTF(%s/%s/backend, fe_path,  
 *dir)); 
  + 
  +libxl_device_usbctrl_init(usbctrl); 
  +usbctrl-devid = atoi(*dir); 
  
 This function (and the corresponding writing code) is quite formulaic. 
 Perhaps a macro or something could be used. 
  
 I would make a similar criticism of libxl_device_usbctrl_getinfo. 
  
  +/* check if USB device is already assigned to a domain */ 
  +static bool is_usb_assigned(libxl__gc *gc, 

Re: [Xen-devel] [PATCH V4 2/7] libxl_read_file_contents: add new entry to read sysfs file

[Chun Yan Liu]

 On 6/12/2015 at 12:16 AM, in message
21881.46148.466883.923...@mariner.uk.xensource.com, Ian Jackson
ian.jack...@eu.citrix.com wrote: 
 Chunyan Liu writes ([Xen-devel] [PATCH V4 2/7] libxl_read_file_contents: add 
  
 new entry to read sysfs file): 
  Sysfs file has size=4096 but actual file content is less than that. 
  Current libxl_read_file_contents will treat it as error when file size 
  and actual file content differs, so reading sysfs file content with 
  this function always fails. 
   
  Add a new entry libxl_read_sysfs_file_contents to handle sysfs file 
  specially. It would be used in later pvusb work. 
  
 I think this patch is roughly right, but: 
  
  -int libxl_read_file_contents(libxl_ctx *ctx, const char *filename, 
  - void **data_r, int *datalen_r) { 
  +static int libxl_read_file_contents_core(libxl_ctx *ctx, const char  
 *filename, 
  + void **data_r, int *datalen_r, 
  + bool is_sysfs_file) 
  
 I would prefer a functional rather than contextual name for the 
 variabvle is_sysfs_file.  How about `tolerate_shrinking_file' ? 

OK.

  
  @@ -360,15 +362,16 @@ int libxl_read_file_contents(libxl_ctx *ctx, const  
 char *filename, 

   if (stab.st_size  data_r) { 
   data = malloc(datalen); 
  +memset(data, 0, datalen); 
  
 What is this for ? 

I found sometimes reading sysfs file contents, at the end, there is
some random character. With this line, there is no problem then.

  
   if (!data) goto xe; 

   rs = fread(data, 1, datalen, f); 
  -if (rs != datalen) { 
  +if (rs != datalen  !(feof(f)  is_sysfs_file)) { 
   if (ferror(f)) 
   LOGE(ERROR, failed to read %s, filename); 
   else if (feof(f)) 
  
 I think it would be better to handle the special case here, with 
 something like 
if (!tolerate_shrinking_file) 
error stuff 
else { 
assert(datalen_r); 
 and to move the `goto xe' into the individual branches. 

OK. Will update.

  
  
 Is there any risk that the file is actually bigger than advertised, 
 rather than smaller ? 

For sysfs file, couldn't be bigger.

  
  diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h 
  index 1c1761d..7639662 100644 
  --- a/tools/libxl/libxl_utils.h 
  +++ b/tools/libxl/libxl_utils.h 
 ... 
  +int libxl_read_sysfs_file_contents(libxl_ctx *ctx, const char *filename, 
  +   void **data_r, int *datalen_r); 
  
 I think this is a function with sufficiently odd semantics, and a 
 sufficiently internal purpose, that it should probably not be exposed 
 in the API. 

So move to libxl_internal.h? Or not hacking here but just adding an internal
function in libxl_pvusb.c with repeated codes?

  
 Ian
  
 ___ 
 Xen-devel mailing list 
 Xen-devel@lists.xen.org 
 http://lists.xen.org/xen-devel 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] 答复： Re: [PATCH V3 3/6] libxl: add pvusb API

[Chun Yan Liu]

 在 2:06 的 2015/5/20 上，在讯息
caflbxzzhffwo6tm7602y3+x5kx65-w4obfs1vdvb8kqnzda...@mail.gmail.com 中，George
Dunlap george.dun...@eu.citrix.com 写入：
 On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu cy...@suse.com 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: Chunyan Liu cy...@suse.com
  Signed-off-by: Simon Cao caobosi...@gmail.com
 
 OK, getting closer. :-)
 
 A number of comments:

Hi, George, thanks very much!
I'm so sorry for missing the message and not reply immediately.
Before sending new version, I'm answering some of your questions here.
And there are a couple of comments, I still have some hesitation to follow.
All others, I agree and will update as you suggested.

 
  diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
  index 6bc75c5..cbe3519 100644
  --- a/tools/libxl/libxl.h
  +++ b/tools/libxl/libxl.h
  @@ -114,6 +114,12 @@
   #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
 
   /*
  + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of
  + * USB devices through pvusb.
  + */
  +#define LIBXL_HAVE_PVUSB 1
 
 It seems like we should document somewhere how we expect these to be
 used -- namely the connection between usbctrl and usb devices.  In
 particular, that you can either add a usbctrl, and then add a usb
 device to it specifically; or if you don't specify a usbctrl when
 calling usb_add, it will find the most reasonable one to add it to,
 even creating one for you if you didn't have one.
 
 
  diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
  new file mode 100644
  index 000..4e4975a
  --- /dev/null
  +++ b/tools/libxl/libxl_pvusb.c
 
  +int libxl__device_usbctrl_add(libxl__gc *gc, uint32_t domid,
  +  libxl_device_usbctrl *usbctrl)
  +{
  +int rc = 0;
  +
  +rc = libxl__device_usbctrl_setdefault(gc, domid, usbctrl);
  +if (rc  0) goto out;
  +
  +if (usbctrl-devid == -1) {
 
 Hmm, I was doing to say that this shouldn't be a magic constant, but
 it looks like that's what all the other devices do :-/
 
  +static bool is_usb_in_array(libxl_device_usb *usbs, int num,
  +libxl_device_usb *usb)
  +{
  +int i;
  +
  +for (i = 0; i  num; i++) {
  +if (!strcmp(usbs[i].busid, usb-busid) )
 
 Here (and elsewhere) you should probably use the COMPARE_USB() macro
 you define in this patch.
 
  +/* check if USB device type is assignable */
  +static bool is_usb_assignable(libxl__gc *gc, libxl_device_usb *usb)
  +{
  +libxl_ctx *ctx = libxl__gc_owner(gc);
  +int classcode;
  +char *filename;
  +void *buf;
  +
  +assert(usb-busid);
  +
  +filename = GCSPRINTF(SYSFS_USB_DEV/%s/bDeviceClass, usb-busid);
  +if (libxl_read_file_contents(ctx, filename, buf, NULL)  0)
  +return false;
  +
  +sscanf(buf, %x, classcode);
  +if (classcode == USBHUB_CLASS_CODE)
  +return false;
  +
  +return true;
 
 Just checking, is it really the case that *all* USB classes are
 assignable, *except* for hubs?

Referring to xm pvusb implementation, only HUB is excluded, so I
just keep the same.

 
 This is a minor thing, but this might be simper to do this:
 
  return classcode != USBHUB_CLASS_CODE;
 
  +/* get usb devices under certain usb controller */
  +static int libxl__device_usb_list(libxl__gc *gc, uint32_t domid, int 
 usbctrl,
  +  libxl_device_usb **usbs, int *num)
  +{
  +char *be_path, *num_devs;
  +int n, i;
  +
  +*usbs = NULL;
  +*num = 0;
  +
  +be_path = GCSPRINTF(%s/backend/vusb/%d/%d,
  +libxl__xs_get_dompath(gc, 0), domid, usbctrl);
  +num_devs = libxl__xs_read(gc, XBT_NULL,
  +  GCSPRINTF(%s/num-ports, be_path));
  +if (!num_devs)
  +return 0;
  +
  +n = atoi(num_devs);
  +*usbs = calloc(n, sizeof(libxl_device_usb));
  +
  +for (i = 0; i  n; i++) {
  +char *busid;
  +libxl_device_usb *usb = NULL;
  +
  +busid = libxl__xs_read(gc, XBT_NULL,
  +   GCSPRINTF(%s/port/%d, be_path, i + 1));
  +if (busid  strcmp(busid, )) {
  +usb = *usbs + *num;
  +usb-ctrl = usbctrl;
  +usb-port = i + 1;
  +usb-busid = strdup(busid);
 
 This needs to populate the hostbus / hostaddr as well; busid is pretty
 useless to users / external callers.

I thought about that when implementing, but finally not added to codes 
considering:
* for all libxl pvusb internal usage, busid is enough.
* for toolstack usage, if we want to expose users useful information about 
bus:addr,
vendorID:devieID, we have libxl_device_usb_getinfo API, with this API callers 
can get
all information including hostbus, hostaddr.

If that couldn't satisfy qemu usage, I can add a translating to 

[Xen-devel] 答复： Re: [PATCH V3 3/6] libxl: add pvusb API

[Chun Yan Liu]

 在 2:16 的 2015/5/20 上，在讯息
caflbxzaw3zcsq-8tjph+3cvg4xs-j15_na930hcry8x4grb...@mail.gmail.com 中，George
Dunlap george.dun...@eu.citrix.com 写入：
 On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu cy...@suse.com wrote:
  +int libxl_device_usb_getinfo(libxl_ctx *ctx, char *busid, libxl_usbinfo 
 *usbinfo)
  +{
 
 Sorry, missed something.  This function is wrong.  It gives you
 information about a *host* USB device; but should properly give you
 information about a *guest* USB device.  The
 libxl_device_disk_getinfo() counterpart, for example, takes a domid
 and a virtual device (from within a libxl_disk structure) and returns
 information about that virtual device.

Maybe the name should be changed as libxl_device_usb_host_info.
Returning *host* USB device info itself is what we need, should not changed.

ctrl, port is the most important information to the virtual device. But like
in 'xl list', it will first list USB controller, and then each port, USB device
appears in some port, it doesn't need to show ctrl, port info again, but
host information is more useful. e.g.:
#xl usb-list test
Devid Type BE state usb-ver ports BE-path
0pv 0 4  1 4  /local/domain/0/backend/vusb/1/0
port 1: Bus 003 Device 005 ID:  8087:07dc Intel Corp.


- Chunyan


 
 Hrm... which makes me wonder whether we should use ctrl,port as a
 unique handle for usb devices in the interface, or have a separate
 devid for the devices themselves.
 
  -George
 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API

[Chun Yan Liu]

 On 5/20/2015 at 05:04 PM, in message
20150520090407.gw26...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote: 
 On Mon, May 18, 2015 at 09:20:43PM -0600, Chun Yan Liu wrote: 
 [...] 
 
+for (;;) {  
+rc = libxl__xs_transaction_start(gc, t);  
+if (rc) goto out;  
+  
+rc = libxl__device_exists(gc, t, device);  
+if (rc  0) goto out;  
+if (rc == 1) {  
+/* already exists in xenstore */  
+LOG(ERROR, device already exists in xenstore);  
+rc = ERROR_DEVICE_EXISTS;  
+goto out;  
+}  
+  
+rc = libxl__set_domain_configuration(gc, domid, d_config);  
+if (rc) goto out;  
+  
+libxl__device_generic_add(gc, t, device,  
+  libxl__xs_kvs_of_flexarray(gc, back, 
 
+ 
back-count),  
  
+  libxl__xs_kvs_of_flexarray(gc, 
front,  
+  
 front-count),  
+  NULL);  
+libxl__usbport_add_xenstore(gc, t, domid, usbctrl);  
+rc = libxl__xs_transaction_commit(gc, t);  
+if (!rc) break;  
+if (rc  0) goto out;  
+}  
+  
 
   You don't have aodev so you cannot check update_json. Maybe you need  
   aodev?  
 
   That field update_json is set to true when doing hotplug. It's set to  
   false during domain creation.  
 
   The same comment applies to other add functions as well. 
   
  Thanks, I'm updating that. But maybe like pci_add and pci_remove functions, 
  will add a 'starting' flag to indicate hotplug or creation. 
  Looking at DEFINE_DEVICE_ADD and DEFINE_DEVICE_REMOVE, usbctrl_add 
  and usb_add can use DEFINE_DEVICE_ADD; but usbctrl_remove and usb_remove 
  cannot use DEFINE_DEVICE_REMOVE directly, need some extra handling. So, 
  finally turned to not use these macros but refer to pci functions. 
   
  
 TBH I prefer to have only one way to deal with devices.  I personally 
 prefer the async style that every other devices use. Maybe that's just 
 because I mostly worked with those. 
  
 I don't know the full history of libxl_pci.c so I will wait for Ian and 
 Ian's comments on which way to go. 
  
 I think one merit of determining whether to use sync or async is that 
 whether the operation is long running (slow). Long running one should be 
 asyn.  I guess usb passthrough is not slow so we are probably fine in 
 this regard. 
  
 BTW if you find the macros can't meet your need you can either extend 
 them or not use them. 

Got you and Ian. I'll update codes then.

Chunyan

  
 
+out:  
+if (lock) libxl__unlock_domain_userdata(lock);  
+libxl_device_usbctrl_dispose(usbctrl_saved);  
+libxl_domain_config_dispose(d_config);  
+return rc;  
+}  
+  
+int libxl__device_usbctrl_add(libxl__gc *gc, uint32_t domid,  
+  libxl_device_usbctrl *usbctrl)  
+{  
+int rc = 0;  
+  
+rc = libxl__device_usbctrl_setdefault(gc, domid, usbctrl);  
+if (rc  0) goto out;  
+  
+if (usbctrl-devid == -1) {  
+usbctrl-devid = libxl__device_nextid(gc, domid, vusb);  
+if (usbctrl-devid  0) {  
+rc = ERROR_FAIL;  
+goto out;  
+}  
+}  
+  
+if (libxl__usbctrl_add_xenstore(gc, domid, usbctrl)  0){  
+rc = ERROR_FAIL;  
+goto out;  
+}  
+  
+out:  
+return rc;  
+}  
+  
+int libxl_device_usbctrl_add(libxl_ctx *ctx, uint32_t domid,  
+ libxl_device_usbctrl *usbctrl,  
+ const libxl_asyncop_how *ao_how)  
+{  
+AO_CREATE(ctx, domid, ao_how);  
+int rc;  
+  
+rc = libxl__device_usbctrl_add(gc, domid, usbctrl);  
 
   Hmm... Your remove function is async while this one is sync, why? 
   
  Hmm, maybe not proper here, just referred to pci_add implementation. 
  Current calling places only use sync mode. 

  
 Yeah, I only ask for consistency. 
  
 Wei. 
  
  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 3/6] libxl: add pvusb API

[Chun Yan Liu]

 On 5/19/2015 at 02:07 AM, in message
20150518180724.gh9...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote: 
 (I look at overall code structure this pass. I haven't done a line by 
 line review.) 
  
 On Sun, Apr 19, 2015 at 11:50:49AM +0800, 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: Chunyan Liu cy...@suse.com 
  Signed-off-by: Simon Cao caobosi...@gmail.com 
  --- 
  Changes to v2: 
* remove qemu emulated usb related definitions, keep the work pure pvusb. 
  In last patch, will do all refactor work to unify pvusb and qemu  
 emulated 
  usb. 
* use bus.addr as user interface instead of busid to do usb-attach|detach 
* remove usb-assignable-list APIs and some other unnecessary APIs 
* reuse libxl_read_file_contents function instead of another new function 
  to handle getting sysfs file content 
* fix build on different platforms as pci does 
* fix many coding style problems 
* address other comments in last version 
* adjust codes to let it look better 
   
   tools/libxl/Makefile |2 +- 
   tools/libxl/libxl.c  |2 + 
   tools/libxl/libxl.h  |   45 ++ 
   tools/libxl/libxl_internal.h |   11 +- 
   tools/libxl/libxl_osdeps.h   |   13 + 
   tools/libxl/libxl_pvusb.c| 1201  
 ++ 
   tools/libxl/libxl_types.idl  |   41 ++ 
   tools/libxl/libxl_types_internal.idl |1 + 
  
 You also need to document the xenstore keys and values somewhere under 
 docs directory. 

Thanks, will add that.

  
 And you forgot to update libxl_retrieve_domain_configuration function. 

Updating.

  
   8 files changed, 1314 insertions(+), 2 deletions(-) 
   create mode 100644 tools/libxl/libxl_pvusb.c 
   
  diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile 
  index 1b16598..d52281f 100644 
  --- a/tools/libxl/Makefile 
  +++ b/tools/libxl/Makefile 
  @@ -95,7 +95,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
  libxl_dm.o  
 libxl_pci.o \ 
  libxl_internal.o libxl_utils.o libxl_uuid.o \ 
  libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o 
  \ 
  libxl_save_callout.o _libxl_save_msgs_callout.o \ 
  -   libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y) 
  +   libxl_qmp.o libxl_event.o libxl_fork.o libxl_pvusb.o 
  $(LIBXL_OBJS-y) 
   LIBXL_OBJS += libxl_genid.o 
   LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o 

  diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
  index b05d18b..a7c81d9 100644 
  --- a/tools/libxl/libxl.c 
  +++ b/tools/libxl/libxl.c 
  @@ -1611,6 +1611,8 @@ void libxl__destroy_domid(libxl__egc *egc,  
 libxl__destroy_domid_state *dis) 

   if (libxl__device_pci_destroy_all(gc, domid)  0) 
   LIBXL__LOG(ctx, LIBXL__LOG_ERROR, pci shutdown failed for domid  
 %d, domid); 
  +if (libxl__device_usb_destroy_all(gc, domid)  0) 
  + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, usb shutdown failed for domid  
 %d, domid); 
   rc = xc_domain_pause(ctx-xch, domid); 
   if (rc  0) { 
   LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, xc_domain_pause  
 failed for %d, domid); 
  diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
  index 6bc75c5..cbe3519 100644 
  --- a/tools/libxl/libxl.h 
  +++ b/tools/libxl/libxl.h 
  @@ -114,6 +114,12 @@ 
   #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1 

   /* 
  + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of 
  + * USB devices through pvusb. 
  + */ 
  +#define LIBXL_HAVE_PVUSB 1 
  + 
  +/* 
* LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the 
* libxl_vendor_device field is present in the hvm sections of 
* libxl_domain_build_info. This field tells libxl which 
  @@ -1224,6 +1230,45 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t  
 domid, libxl_device_disk *disk, 
  const libxl_asyncop_how *ao_how) 
  LIBXL_EXTERNAL_CALLERS_ONLY; 

  +/* USB Controllers*/ 
  +int libxl_device_usbctrl_add(libxl_ctx *ctx, uint32_t domid, 
  + libxl_device_usbctrl *usbctrl, 
  + const libxl_asyncop_how *ao_how) 
  + LIBXL_EXTERNAL_CALLERS_ONLY; 
  + 
  +int libxl_device_usbctrl_remove(libxl_ctx *ctx, uint32_t domid, 
  + libxl_device_usbctrl *usbctrl, 
  + const libxl_asyncop_how *ao_how) 
  + LIBXL_EXTERNAL_CALLERS_ONLY; 
  + 
  +int libxl_device_usbctrl_destroy(libxl_ctx *ctx, uint32_t domid, 
  + libxl_device_usbctrl *usbctrl, 
  + const libxl_asyncop_how *ao_how) 
  + 

Re: [Xen-devel] [PATCH V3 2/6] libxl_read_file_contents: fix reading sysfs file

[Chun Yan Liu]

 On 5/18/2015 at 10:30 PM, in message
20150518143008.ge9...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote: 
 On Mon, May 18, 2015 at 03:23:38PM +0100, Ian Jackson wrote: 
  Chunyan Liu writes ([PATCH V3 2/6] libxl_read_file_contents: fix reading  
 sysfs file): 
   Sysfs file has size=4096 but actual file content is less than that. 
   
  Wow. 
   
  Is there any danger that the actual size might be 4096 ? 
   
   
   Current libxl_read_file_contents will treat it as error when file size 
   and actual file content differs, so reading sysfs file content with 
   this function always fails. Fix it so that we can reuse this function 
   to get sysfs file content in later pvusb work. 
   
  I'm uncomfortable with removing an error check from this function for 
  all its call sites. 
   
  I think, sadly, that we are going to need a new function - at least, a 
  new entrypoint. 
   
   
  We don't want to repeat the whole of libxl__read_file_contents. 
   
  Perhaps the bulk should be made into libxl__read_file_contents_core 
  which takes a boolean instructing whether to tolerate magically 
  shrinking files ? 
   
  Setting that boolean probably ought to arrange to insist that the 
  function gets eof, in case the file is actually bigger rather than 
  smaller than the size. 
   
   
  Ian, Wei ? 
   
  
 Yes, we need a new entry point. 

Will update. Thanks!

  
 Wei. 
  
  Ian. 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.6 Development Update (four months reminder)

[Chun Yan Liu]

 On 5/13/2015 at 01:01 PM, in message
e1ysont-0004pu...@ukmail1.uk.xensource.com, wei.l...@citrix.com wrote: 
 (Note, please trim your quotes when replying, and also trim the CC list if 
 necessary. You might also consider changing the subject line of your reply  
 to 
 Status of  (Was: Xen 4.6 Development Update (X months reminder)) 
  
 Hi all 
  
 We are now four months into 4.6 development window. This is an email to keep 
 track of all the patch series I gathered. It is by no means complete and /  
 or 
 acurate. Feel free to reply this email with new projects or correct my 
 misunderstanding. 
  
 = Timeline = 
  
 We are planning on a 9-month release cycle, but we could also release a bit 
 earlier if everything goes well (no blocker, no critical bug). 
  
 * Development start: 6 Jan 2015 
 === We are here === 
 * Feature Freeze: 10 Jul 2015 
 * RCs: TBD 
 * Release Date: 9 Oct 2015 (could release earlier) 
  
 The RCs and release will of course depend on stability and bugs, and 
 will therefore be fairly unpredictable. 
  
 Bug-fixes, if Acked-by by maintainer, can go anytime before the First 
 RC. Later on we will need to figure out the risk of regression/reward 
 to eliminate the possiblity of a bug introducing another bug. 
  
 = Prognosis = 
  
 The states are: none - fair - ok - good - done 
  
 none - nothing yet 
 fair - still working on it, patches are prototypes or RFC 
 ok   - patches posted, acting on review 
 good - some last minute pieces 
 done - all done, might have bugs 
  
 = Bug Fixes = 
  
 Bug fixes can be checked in without a freeze exception throughout the 
 freeze, unless the maintainer thinks they are particularly high 
 risk.  In later RC's, we may even begin rejecting bug fixes if the 
 broken functionality is small and the risk to other functionality is 
 high. 
  
 Document changes can go in anytime if the maintainer is OK with it. 
  
 These are guidelines and principles to give you an idea where we're coming 
 from; if you think there's a good reason why making an exception for you  
 will 
 help us make Xen better than not doing so, feel free to make your case. 
  
 == Hypervisor ==  
  
 *  Alternate p2m: support multiple copies of host p2m (ok) 
   -  Ed White 
  
 *  Improve RTDS scheduler (none) 
Change RTDS from quantum driven to event driven 
   -  Dagaen Golomb, Meng Xu 
  
 *  Credit2: introduce per-vcpu hard and soft affinity (good) 
   -  Justin T. Weaver 
  
 *  sndif: add API for para-virtual sound (fair) 
v7 posted 
   -  Oleksandr Dmytryshyn 
  
 *  gnttab: improve scalability (good) 
v5 posted 
   -  Christoph Egger 
  
 *  Display IO topology when PXM data is available (good) 
v7 posted 
   -  Boris Ostrovsky 
  
 *  Clean-up of mem-event subsystem (good) 
v9 posted 
   -  Tamas K Lengyel 
  
 *  Xen multiboot2-EFI support (fair) 
See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html 
RFC posted 
   -  Daniel Kiper 
  
 *  Credit2 production ready (none) 
cpu reservation 
   -  George Dunlap 
  
 *  VM event patches (none) 
Add support for XSETBV vm_events, 
Support hybernating guests 
Support for VMCALL-based vm_events 
   -  Razvan Cojocaru 
  
 === Hypervisor X86 ===  
  
 *  Intel GVT-g (none) 
requires refactoring ioreq-server, fixing 16-byte MMIO emulation 
and optional PV IOMMU support 
   -  Yu, Zhang 
  
 *  Porting Intel P-state driver to Xen (fair) 
   -  Wang, Wei 
  
 *  VT-d Posted-interrupt (PI) (good) 
v1 posted 
   -  Wu, Feng 
  
 *  HT enabled with credit has 7.9 per perf drop. (none) 
kernbench demonstrated it 
http://www.gossamer-threads.com/lists/xen/devel/339409 
This has existed since credit1 introduction. 
   -  Dario Faggioli 
  
 *  Support controlling the max C-state sub-state (fair) 
v3 posted 
Hadn't see the patch reposted. 
   -  Ross Lagerwall 
  
 *  IOMMU ABI for guests to map their DMA regions (fair) 
   -  Malcolm Crossley 
  
 *  RMRR fix (fair) 
RFC posted 
   -  Tiejun Chen 
  
 *  VPMU - 'perf' support in Xen (good) 
v21 posted 
Need reviews/final ack. 
   -  Boris Ostrovsky 
  
 *  PVH domU (fair) 
RFC posted 
   -  Elena Ufimtseva 
  
 === Hypervisor ARM ===  
  
 *  Mem_access for ARM (good) 
v15 posted 
   -  Tamas K Lengyel 
  
 *  ITS support (fair ) 
   -  Vijaya Kumar K 
  
 *  Add ACPI support for arm64 on Xen (fair) 
RFC posted 
   -  Parth Dixit 
  
 *  ARM: reenable support 32-bit userspace running in 64-bit guest (good) 
v2 posted 
   -  Ian Campbell 
  
 *  ARM remote processor iommu module (GPUs + IPUs) (fair) 
v3 posted 
   -  Andrii Tseglytskyi 
  
 *  ARM VM save/restore/live migration (none) 
Need to rebased against migrationv2 - no code posted. 
   -  None 
  
 *  ARM GICv2m support (none) 
   -  Suravee Suthikulanit 
  
 *  ARM  PCI passthrough (none) 
   -  Manish Jaggi 
   -  Vijay Kilari 
  
 == Xen toolstack ==  
  
 *  Migration v2 (libxl) (none) 
   -  

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

[Chun Yan Liu]

 On 4/20/2015 at 04:12 PM, in message 5534b4d8.4010...@suse.com, Juergen 
 Gross
jgr...@suse.com wrote: 
 On 04/19/2015 05:50 AM, Chunyan Liu wrote: 
  Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list, 
  usb-attach and usb-detach. 
  
  To attach a usb device to guest through pvusb, one could follow 
  following example: 
  
#xl usb-ctrl-attach test_vm version=1 num_ports=8 
  
#xl usb-list test_vm 
will show the usb controllers and port usage under the domain. 
  
#xl usb-attach test_vm 1.6 
will find the first usable controller:port, and attach usb 
device whose bus address is 1.6 (busnum is 1, devnum is 6) 
to it. One could also specify which controller and which port. 
  
#xl usb-detach test_vm 1.6 
  
#xl usb-ctrl-detach test_vm dev_id 
will destroy the controller with specified dev_id. Dev_id 
can be traced in usb-list info. 
  
  Signed-off-by: Chunyan Liu cy...@suse.com 
  Signed-off-by: Simon Cao caobosi...@gmail.com 
  --- 
  Changes to v2: 
 * use bus.addr as user interface instead of busid in usb-attach|detach 
 * remove usb-assignable-list interface 
  
 Why? While lsusb in combination with xl usb-list for each domain will 
 give the same information, having to iterate through all domains can be 
 quite annoying. 
  
 An alternative would be to accept omitting the domain for xl usb-list 
 and list all domains with assigned usb devices in this case. 

Ian  George, how do you think?

  
 * add documentation 
  
docs/man/xl.pod.1 |  38  
tools/libxl/xl.h  |   5 + 
tools/libxl/xl_cmdimpl.c  | 238  
 ++ 
tools/libxl/xl_cmdtable.c |  25 + 
4 files changed, 306 insertions(+) 
  
 ... 
  --- a/tools/libxl/xl_cmdimpl.c 
  +++ b/tools/libxl/xl_cmdimpl.c 
  @@ -3196,6 +3196,244 @@ int main_cd_insert(int argc, char **argv) 
return 0; 
} 
  
  +static void usbinfo_print(libxl_device_usb *usbs, int num) { 
  +int i; 
  +if ( usbs == NULL ) 
  
 Coding style. 
  
  + return; 
  +for (i = 0; i  num; i++) { 
  +libxl_usbinfo usbinfo; 
  +libxl_usbinfo_init(usbinfo); 
  + 
  +if (usbs[i].port ) 
  
 Coding style. 
  
  +printf(  Port %d:, usbs[i].port); 
  +if (!libxl_device_usb_getinfo(ctx, usbs[i].busid, usbinfo)) { 
  +printf( Bus %03x Device %03x: ID %04x:%04x %s %s\n, 
  +usbinfo.busnum, usbinfo.devnum, usbinfo.idVendor, 
  +usbinfo.idProduct, usbinfo.manuf, usbinfo.prod); 
  +} 
  +libxl_usbinfo_dispose(usbinfo); 
  +} 
  +} 
  + 
  +int main_usbctrl_attach(int argc, char **argv) 
  +{ 
  +uint32_t domid; 
  +int opt; 
  +char *oparg; 
  +libxl_device_usbctrl usbctrl; 
  + 
  +SWITCH_FOREACH_OPT(opt, , NULL, usb-ctrl-attach, 1) { 
  +/* No options */ 
  +} 
  + 
  +domid = find_domain(argv[optind++]); 
  + 
  +libxl_device_usbctrl_init(usbctrl); 
  + 
  +while (argc  optind) { 
  +if (MATCH_OPTION(version, argv[optind], oparg)) { 
  +usbctrl.version = atoi(oparg); 
  +} else if (MATCH_OPTION(ports, argv[optind], oparg)) { 
  +usbctrl.ports = atoi(oparg); 
  +} else { 
  +fprintf(stderr, unrecognized argument `%s'\n, argv[optind]); 
  +exit(-1); 
  
 I don't think this is the preferred way of error handling. 
 Returning with an appropriate error code would be better. 
  
 Same applies to all other uses of exit() below. 
  
  +} 
  +optind++; 
  +} 
  + 
  +if (dryrun_only) { 
  +   char* json = libxl_device_usbctrl_to_json(ctx, usbctrl); 
  +   printf(usb controller: %s\n, json); 
  +   free(json); 
  +   libxl_device_usbctrl_dispose(usbctrl); 
  +   if (ferror(stdout) || fflush(stdout)) { 
  +   perror(stdout); 
  +   exit(-1); 
  +   } 
  +   return 0; 
  +} 
  + 
  +if (libxl_device_usbctrl_add(ctx, domid, usbctrl, 0)) { 
  +fprintf(stderr, libxl_device_usbctrl_add failed.\n); 
  +exit(-1); 
  +} 
  +libxl_device_usbctrl_dispose(usbctrl); 
  +return 0; 
  +} 
  + 
  +int main_usbctrl_detach(int argc, char **argv) 
  +{ 
  +uint32_t domid; 
  +int opt; 
  +libxl_device_usbctrl usbctrl; 
  + 
  +SWITCH_FOREACH_OPT(opt, , NULL, usb-ctrl-detach, 2) { 
  +/* No options */ 
  +} 
  + 
  +domid = find_domain(argv[optind]); 
  + 
  +libxl_device_usbctrl_init(usbctrl); 
  +usbctrl.devid = atoi(argv[optind+1]); 
  + 
  +if(libxl_device_usbctrl_remove(ctx, domid, usbctrl, 0)) { 
  
 Coding style. 
  
  +fprintf(stderr, libxl_device_usbctrl_add failed.\n); 
  +exit(-1); 
  +} 
  +libxl_device_usbctrl_dispose(usbctrl); 
  +return 0; 
  + 
  +} 
  
 Juergen 
  
  
 ___ 
 

Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)

[Chun Yan Liu]

 On 4/14/2015 at 09:33 PM, in message 552d1718.8060...@eu.citrix.com, 
 George
Dunlap george.dun...@eu.citrix.com wrote: 
 On 04/14/2015 11:27 AM, wei.l...@citrix.com wrote: 
  == Hypervisor ==  
   
  *  Alternate p2m: support multiple copies of host p2m (ok) 
-  Ed White 
   
  *  Improve RTDS scheduler (none) 
-  Dagaen Golomb, Meng Xu 
  
 This is a little vague... exactly what kinds of improvements are 
 envisioned here? 
  
  *  Credit2: introduce per-vcpu hard and soft affinity (good) 
-  Justin T. Weaver 
  
 Still good (Probably in part awaiting my further review -- should get to 
 that this week) 
  
  *  Credit2 production ready (none) 
 cpu pinning, numa affinity and cpu reservation 
-  George Dunlap 
  
 The first two are identical to Justin Weaver's patch; you might want to 
 note that.  No work on CPU reservation yet. 
  
  *  PV USB support in libxl (fair) 
-  Chunyan Liu 
   
  *  HVM USB support in libxl (fair) 
-  George Dunlap 
  
 Haven't heard anything on the first one in a while; the second one is 
 basically blocked on the first. 

New version should be posted this week, addressing all comments of last
version.

  
  *  Blktap2 support (fair) 
-  George Dunlap 
  
 Working on integrating this with raisin; still fair by the definitions 
 above. 
  
  -George 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC V2 3/5] libxl: add pvusb API

[Chun Yan Liu]

 On 3/7/2015 at 12:50 AM, in message
caflbxzzfzl2f4qnuwgbpza8v1ffgvvkbgn+gco6ceekvbf6...@mail.gmail.com, George
Dunlap george.dun...@eu.citrix.com wrote: 
 On Mon, Jan 19, 2015 at 8:28 AM, Chunyan Liu cy...@suse.com wrote: 
  diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
  index 0a123f1..2e89244 100644 
  --- a/tools/libxl/libxl.h 
  +++ b/tools/libxl/libxl.h 
  
  +int libxl_intf_to_device_usb(libxl_ctx *ctx, uint32_t domid, 
  +char *intf, libxl_device_usb *usb) 
  +LIBXL_EXTERNAL_CALLERS_ONLY; 
  
 I guess this function will go away? 

With using bus:addr instead of sysfs interface, this will be removed.

  
  diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c 
  new file mode 100644 
  index 000..830a846 
  --- /dev/null 
  +++ b/tools/libxl/libxl_usb.c 
  @@ -0,0 +1,1277 @@ 
  
  +static int libxl__usbport_add_xenstore(libxl__gc *gc, 
  +   xs_transaction_t tran, 
  +   uint32_t domid, 
  +   libxl_device_usbctrl *usbctrl) 
  
 Would it be too much to ask to have all the pvusb-specific stuff in a 
 separate file -- say, libxl_pvusb.c or something?  That would make 
 it a lot easier when I add in the HVM USB stuff. 

Sure.

  
 (Just to be clear, I'm asking as a favor -- it's policy that the first 
 mover gets to have it easier, and people who want to come and add 
 something later are the ones who have to do the refactoring.) 
  
  +{ 
  +char *path; 
  +int i; 
  + 
  +path = GCSPRINTF(%s/backend/vusb/%d/%d/port, 
  + libxl__xs_get_dompath(gc, 0), domid, usbctrl-devid); 
  + 
  +libxl__xs_mkdir(gc, tran, path, NULL, 0); 
  + 
  +for (i = 1; i = usbctrl-num_ports; i++) { 
  +if (libxl__xs_write_checked(gc, tran, GCSPRINTF(%s/%d, path, i), 
   
 )) 
  +return ERROR_FAIL; 
  +} 
  + 
  +return 0; 
  +} 
  + 
  +static int libxl__usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid, 
  +   libxl_device_usbctrl *usbctrl) 
  +{ 
  +libxl_ctx *ctx = libxl__gc_owner(gc); 
  +flexarray_t *front; 
  +flexarray_t *back; 
  +libxl__device *device; 
  +xs_transaction_t tran; 
  +int rc = 0; 
  + 
  +GCNEW(device); 
  +rc = libxl__device_from_usbctrl(gc, domid, usbctrl, device); 
  +if (rc) goto out; 
  + 
  +front = flexarray_make(gc, 4, 1); 
  +back = flexarray_make(gc, 12, 1); 
  + 
  +flexarray_append(back, frontend-id); 
  +flexarray_append(back, libxl__sprintf(gc, %d, domid)); 
  +flexarray_append(back, online); 
  +flexarray_append(back, 1); 
  +flexarray_append(back, state); 
  +flexarray_append(back, libxl__sprintf(gc, %d, 1)); 
  +flexarray_append(back, usb-ver); 
  +flexarray_append(back, libxl__sprintf(gc, %d, 
  usbctrl-usb_version)); 
  +flexarray_append(back, num-ports); 
  +flexarray_append(back, libxl__sprintf(gc, %d, usbctrl-num_ports)); 
  
 So how much of this is pvusb-specific, and how much would be shared 
 between DEVICEMODEL?  Because this bit looks specifically like the 
 stuff used to set up the pvusb connection... 

To share with qemu emulated usb controller? I think pvusb backend driver will
probe things under backend/vusb/* and setup connection with pvusb frontend
driver, qemu emulated usb controller should not be placed there at all maybe.

  
  +flexarray_append(back, type); 
  +switch(usbctrl-type) { 
  +case LIBXL_USBCTRL_TYPE_PV:{ 
  +flexarray_append(back, PVUSB); 
  +break; 
  +} 
  +case LIBXL_USBCTRL_TYPE_DEVICEMODEL: { 
  +flexarray_append(back, IOEMU); 
  +break; 
  +} 
  +default: 
  +/* not supported */ 
  +rc = ERROR_FAIL; 
  +goto out; 
  +} 
  
 ...but this looks like it's trying to be shared between PVUSB and 
 DEVICEMODEL.  I'm pretty sure this isn't going to work long-run, 
 because if we were to write all this stuff for a devicemodel, wouldn't 
 the pvusb back-end take this as setting up a new pvusb port? 

Yes, I think you are right. This place should only allow pvusb type.
Qemu emulated usb controller should not be stored here.

  
 Also, you don't seem to be storing or retreiving usbctrl-name here -- 
 if we want that to be part of the interface we need to use it.  (I 
 think we wanted that so that it could default to something like pv-0, 
 emul-1, c). 

First I wonder usbctrl-name is really needed. If just for interface, we can
use devid (index), it could be 0, 1, and with usb-list one knows info like:
0 is pv, 1 is emulated. But if it helps a lot with a 'name', surely we can
add :)

  
 In general, I don't think libxl should be storing stuff in the pvusb 
 front/back xenstore directories not related to that protocol.  We 
 should store extraneous information in a libxl-specific directory. 
 You can see 

Re: [Xen-devel] [PATCH RFC V2 4/5] xl: add pvusb commands

[Chun Yan Liu]

 On 3/7/2015 at 01:25 AM, in message
caflbxzb1n3_9pvvg-yc8dyvaiyszvra3h2e8496vhnefvrm...@mail.gmail.com, George
Dunlap george.dun...@eu.citrix.com wrote: 
 On Mon, Jan 19, 2015 at 8:28 AM, Chunyan Liu cy...@suse.com wrote: 
  Add pvusb commands. 
  
  To attach a usb device to guest through pvusb, one could follow 
  following example: 
  
   #xl usb-ctrl-attach test_vm version=1 num_ports=8 
  
 This doesn't allow you to specify controller name or devid. 
  
 I was looking at the other device-attach code, and they all seem to 
 have a devicespec-style specification.  Would it make sense to do 
 something similar? 
  
 For example: 
  
 xl usb-ctrl-attach test_vm name=pv-1,type=pv,version=1,ports=8 
  
 Then we could re-use this for the config file as well. 
  
   #xl usb-list test_vm 
   will show the usb controllers and port usage under the domain. 
  
   #xl usb-assignable-list 
   will list all assignable usb devices now in host, with their 
   sysfs interface. (This is very useful since later we will use 
   sysfs interface to attach a usb devie to guest) 
  
   #xl usb-attach test_vm 2-1.1 
   will find the first usable controller:port, and attach usb 
   device with sysfs interface 2-1.1 (sys/bus/usb/devices/2-1.1) 
   to it. One could also specify which controller and which port 
  
   #xl usb-detach test_vm 2-1.1 
  
 Long-term we want to be able to attach and detach more kinds of 
 devices than just host devices; for example for HVM guests we want to 
 be able to attach mice, keyboards, tablets, c. 
  
 What if we continued with the devicespec idea above, it might make 
 more sense to say something like 
  
 xl usb-attach test_vm type=hostdev,hostbus=X,hostaddr=Y,ctrl=pv-1 
  
 (Assuming you had a controller named pv-1, for example.) 
  
 And then maybe in the future we could have something like 
  
 xl usb-attach test_vm type=tablet 
  
 Thoughts? 

This could be. I can update.

  
  -George 
  
  



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)

[Chun Yan Liu]

 On 3/12/2015 at 06:21 PM, in message
e1yw0fy-0002p7...@ukmail1.uk.xensource.com, wei.l...@citrix.com wrote: 
 Hi all 
  
 We are now two months into 4.6 development window. This is an email to keep 
 track of all the patch series I gathered. It is by no means complete and /  
 or 
 acurate. Feel free to reply this email with new projects or correct my 
 misunderstanding. 
  
 = Timeline = 
  
 We are planning on a 9-month release cycle, but we could also release a bit 
 earlier if everything goes well (no blocker, no critical bug). 
  
 * Development start: 6 Jan 2015 
 === We are here === 
 * Feature Freeze: 10 Jul 2015 
 * RCs: TBD 
 * Release Date: 9 Oct 2015 (could release earlier) 
  
 The RCs and release will of course depend on stability and bugs, and 
 will therefore be fairly unpredictable. 
  
 Bug-fixes, if Acked-by by maintainer, can go anytime before the First 
 RC. Later on we will need to figure out the risk of regression/reward 
 to eliminate the possiblity of a bug introducing another bug. 
  
 = Prognosis = 
  
 The states are: none - fair - ok - good - done 
  
 none - nothing yet 
 fair - still working on it, patches are prototypes or RFC 
 ok   - patches posted, acting on review 
 good - some last minute pieces 
 done - all done, might have bugs 
  
 = Bug Fixes = 
  
 Bug fixes can be checked in without a freeze exception throughout the 
 freeze, unless the maintainer thinks they are particularly high 
 risk.  In later RC's, we may even begin rejecting bug fixes if the 
 broken functionality is small and the risk to other functionality is 
 high. 
  
 Document changes can go in anytime if the maintainer is OK with it. 
  
 These are guidelines and principles to give you an idea where we're coming 
 from; if you think there's a good reason why making an exception for you  
 will 
 help us make Xen better than not doing so, feel free to make your case. 
  
 == Linux ==  
  
 *  PV domain with memory  512GB (fair) 
   -  Juergen Gross 
  
 *  Block driver multiqueue support (fair) 
RFC posted 
   -  Bob Liu 
  
 *  Block driver multi-page ring support (fair) 
   -  Bob Liu 
  
 *  Preemptable privcmd hypercalls (good) 
v5 posted 
   -  David Vrabel 
  
 *  Linux ARM - Device assigment (PCI) (none) 
Depends on Xen pieces which are on the Xen 4.6 list. 
   -  Manish Jaggi 
  
 *  pvUSB in Linux (fronted and backend) (Fair) 
   -  Juergen Gross 
  
 *  VPMU - 'perf' support in Linux (ok) 
Depends on Xen patches 
Acked by David Vrabel 
   -  Boris Ostrovsky 
  
 *  vNUMA in Linux (ok) 
v6 posted 
git://gitorious.org/vnuma/linux_vnuma.git 
   -  Elena Ufimtseva 
  
 *  vsyscall in Linux (fair) 
   -  Konrad Rzeszutek Wilk 
  
 *  COLO Agent in Linux (fair) 
   -  Gui Jianfeng 
   -  Yang Hongyang 
   -  Dong, Eddie 
  
 *  ARM64 - support 64K guest (none) 
   -  Julien Grall 
  
 == OpenStack ==  
  
 *  setup CI loop for OpenStack (fair) 
   -  Anthony Perard 
  
 == FreeBSD ==  
  
 *  PVH FreeBSD dom0 (ok) 
FreeBSD 11 goal. Toolstack side done in Xen 4.5 
   -  Roger Pau Monné 
  
 == Other OSes (MiniOS, QNX) ==  
  
 *  PV drivers for automotive kernels (fair) 
   -  Artem Mygaiev 
  
 *  mini-os: xenbus changes for rump kernels (ok) 
git://xenbits.xen.org/people/iwj/rumpuser-xen.git 
branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1 
v2 posted 
   -  Ian Jackson 
  
 == GRUB2 ==  
  
 *  GRUB2 multiboot2 (fair) 
   -  Daniel Kiper 
  
 == OSSTEST ==  
  
 *  OSSTest: studom test case (none) 
   -  Wei Liu 
  
 *  OSSTest: libvirt migration (fair) 
   -  Wei Liu 
  
 *  OSSTest: upgrade to Debian Jessie (none) 
   -  Wei Liu 
  
 *  OSSTest: performance test (fair) 
   -  Dario Faggioli 
  
 *  CPU pool test case (fair) 
   -  Dario Faggioli 
  
 *  Add a FreeBSD host (fair) 
   -  Roger Pau Monné 
  
 *  Nested virt test case (fair) 
   -  Robert Hu 
  
 == QEMU ==  
  
 *  Linux-based QEMU upstream stub domain (fair) 
RFC posted 
   -  Eric Shelton 
  
 *  Using qemu-upstream in a stubdomain (none) 
Will use rump kernels. 
   -  Wei Liu 
  
 *  AMD Radeon PCI GPU passthrough (none) 
Focusing on Xen 4.2 and qemu-traditional 
   -  Kelly Zytaruk 
  
 *  Intel IGD PCI GPU passthrough (ok) 
v5 posted 
   -  Chen, Tiejun 
  
 == Up for grabs ==  
  
 *  save/restore/migrate PVHVM guest with  32 vcpus 
http://lists.xen.org/archives/html/xen-devel/2015-02/msg00244.html 
  
 *  PoD fixes 
if you boot with memory = maxmem we have a size estimation bug 
  
 *  TLB flushing without locks in Xen 
  
 *  xl does not support specifying virtual function for passthrough device 
http://bugs.xenproject.org/xen/bug/22 
  
 *  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with  
 PCI/GPU passthrough 
http://bugs.xenproject.org/xen/bug/28 
  
 *  libx{c,l} error handling cleanup  
  
 *  Adding missing 'xend' features in libxl 
Need to define what is missing 
  
 *  xl list -l doesn't contain tty console