Xen devel - Feb 2005 - Re: Re: [PATCH] Hook USB... and a first question about the USB code

OK.  Whatever you think is best. 

Finally, I have a question about the code:

The back end driver is calling usb_set_configuration which has disappeared in
the 2.6 kernel.

My understanding of this after having extracted my head from the blender of the
USB spec is that the configuration determines what USB resources are used i.e.
USB bandwidth and power and the reason that this has been removed from the 2.6
driver interface is that this should be a policy defined by the user via hotplug
scripts and not set by the driver.

But the USB virtualisation code is, as far as I can tell, letting the guest OS
instance set the configuration from the front end.

It seems to me that this A) isn''t compatible with the new 2.6 interface
and B) isn''t what is required for protection between the guest OSs
anyway.

I think the correct design would be for the back-end domain to set the
configuration based on the Xen guest configuration and then present the usb
device to the front end as if it only had one configuration and fake up the USB
device state machine such that bus enumeration could be performed in the guest
without affecting the back end.

This would allow the USB bus resources to be managed with protection between the
different guests but would make devices with multiple configurations look
different in the guests---not sure how this would affect driver compatibility.

Alternatively, there is some provision in the USB spec for declaring that a HCI
has less bandwidth available than the theoretical USB maximum.  I guess, using
this mechanism, the available USB B/W might be divided up between the guests and
then they might be allowed to set configurations within the constraints of their
allocated bandwidths.  Not too sure about this option though: it still seems
incompatible with the 2.6 interface and care would be required to ensure
isolation didn''t rely on cooperation from the guests.

What are your thoughts on this?

Harry.
> Message date : Feb 01 2005, 02:50 PM
> From : "Mark A. Williamson" <mark.williamson@cl.cam.ac.uk>
> To : "Harry Butterworth"
<harry@hebutterworth.freeserve.co.uk>
> Copy to : 
> Subject : Re: [PATCH] Hook USB virt code into 2.6 build
> 
> Thanks Harry,
> 
> I''ll take a look at this but I''m in two minds whether to
merge it just yet.
> One the one hand, it seems like a reasonable thing to do.  On the other
hand,
> people might see the option there and wonder why it breaks the build...
> 
> Cheers,
> Mark
> 
> On Monday 31 January 2005 18:43, you wrote:
> > This patch creates the Makefiles and the Kconfig but doesn''t
fix the
> > compile issues.  The config options are set to n to avoid breaking the
> > 2.6 build. Tested with make world.
> 
-- 

Whatever you Wanadoo:
http://www.wanadoo.co.uk/time/

This email has been checked for most known viruses - find out more at:
http://www.wanadoo.co.uk/help/id/7098.htm


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> The back end driver is calling usb_set_configuration which has disappeared
> in the 2.6 kernel.
>
> My understanding of this after having extracted my head from the blender of
> the USB spec is that the configuration determines what USB resources are
> used i.e. USB bandwidth and power and the reason that this has been removed
> from the 2.6 driver interface is that this should be a policy defined by
> the user via hotplug scripts and not set by the driver.
>
> But the USB virtualisation code is, as far as I can tell, letting the guest
> OS instance set the configuration from the front end.
The guest OS tries to set the configuration because the Linux USB core expects 
to be able to do it.

The reason this was handled explicitly in the backend driver is that otherwise 
the guest will send control packets to the device that change its behaviour 
without dom0 knowing about it.  I did think this breaks some sanity checks 
(e.g. on packet sizes) elsewhere is dom0''s USB stack, causing requests
to be
failed for no reason (but that might just have been interface sets).
> It seems to me that this A) isn''t compatible with the new 2.6
interface
:-(
> and 
> B) isn''t what is required for protection between the guest OSs
anyway.
Nope, it''s purely there to stop dom0 getting confused.  It''s
not required for
correctness or isolation, since it does whatever the guest asked anyhow.
> I think the correct design would be for the back-end domain to set the
> configuration based on the Xen guest configuration and then present the usb
> device to the front end as if it only had one configuration and fake up the
> USB device state machine such that bus enumeration could be performed in
> the guest without affecting the back end.
>
> This would allow the USB bus resources to be managed with protection
> between the different guests but would make devices with multiple
> configurations look different in the guests---not sure how this would
> affect driver compatibility.
I seem to remember needing to set the configuration for my webcam to work (but 
that might have been interface setting) - we may need to (at least) resolve 
mismatches between 2.4 frontends trying to set this and 2.6 backends not 
liking it!

First off it might be worthing trying to get away with just catching 
SET_CONFIGURATION messages and not really doing anything.  Can you try 
ifdef-ing out the offending call for 2.6 and see if that breaks anything?

If that doesn''t work, usb_set_configuration still seems to exist so we
might
be able to abuse the interface by including drivers/usb/core/usb.h and 
calling it anyhow as a stopgap measure.
> Alternatively, there is some provision in the USB spec for declaring that a
> HCI has less bandwidth available than the theoretical USB maximum.  I
> guess, using this mechanism, the available USB B/W might be divided up
> between the guests and then they might be allowed to set configurations
> within the constraints of their allocated bandwidths.  Not too sure about
> this option though: it still seems incompatible with the 2.6 interface and
> care would be required to ensure isolation didn''t rely on
cooperation from
> the guests.
I haven''t implemented bandwidth restrictions yet but I do pass a
bandwidth
value for each interface that''s connected.  I use a "balloon"
approach in the
guest by allocating bandwidth in the XHCI driver - it''d be nice to get
rid of
this by returning the correct bandwidth value to the USB core.

Some cleverer scheduling in the backend would be required to enforce fairness 
if we decide it''s worth implementing.

Cheers,
Mark
> What are your thoughts on this?
>
> Harry.
>
> > Message date : Feb 01 2005, 02:50 PM
> > From : "Mark A. Williamson"
<mark.williamson@cl.cam.ac.uk>
> > To : "Harry Butterworth"
<harry@hebutterworth.freeserve.co.uk>
> > Copy to :
> > Subject : Re: [PATCH] Hook USB virt code into 2.6 build
> >
> > Thanks Harry,
> >
> > I''ll take a look at this but I''m in two minds
whether to merge it just
> > yet. One the one hand, it seems like a reasonable thing to do.  On the
> > other hand, people might see the option there and wonder why it breaks
> > the build...
> >
> > Cheers,
> > Mark
> >
> > On Monday 31 January 2005 18:43, you wrote:
> > > This patch creates the Makefiles and the Kconfig but
doesn''t fix the
> > > compile issues.  The config options are set to n to avoid
breaking the
> > > 2.6 build. Tested with make world.

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel