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

["Mark A. Williamson" <mark.williamson@xxxxxxxxxxxx>]

> 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@xxxxxxxxxxxx>
> > To : "Harry Butterworth" <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel