Mailing List Archive: 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