All of lore.kernel.org
 help / color / mirror / Atom feed
From: harry@hebutterworth.freeserve.co.uk
To: mark.williamson@cl.cam.ac.uk
Cc: xen-devel@lists.sourceforge.net
Subject: Re: Re: [PATCH] Hook USB... and a first question about the USB code
Date: Tue,  1 Feb 2005 17:14:42 +0100 (CET)	[thread overview]
Message-ID: <12390833.1107274482186.JavaMail.www@wwinf3102> (raw)

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

             reply	other threads:[~2005-02-01 16:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-01 16:14 harry [this message]
2005-02-01 17:00 ` [PATCH] Hook USB... and a first question about the USB code Mark A. Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12390833.1107274482186.JavaMail.www@wwinf3102 \
    --to=harry@hebutterworth.freeserve.co.uk \
    --cc=mark.williamson@cl.cam.ac.uk \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.