This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] usb storage vitualization

>  If I remember correctly - u had mentioned that you had started
> working on USB virtualization. How much progress have you made?

Got sidetracked by the Xen 2.0 release work.  I'll be back to working on this 
(almost) full time now.

>  I would be interested in contributing/learning to/from the USB
> virtualization project.

I'm planning on making the code available once I have a prototype 
implementation starting to do things...

>  If you have time pls give me some detailed information on how you plan on
> virtualizing USB.

The Linux USB subsystem provides core functionality that is independent of 
platform, device and controller.  Uses two kinds of device drivers:
* Host controller drivers - these talk to the actual USB controller and 
provide services to the core USB code.  These generally use the services 
provided by the PCI core since USB controllers are usually attached to the 
PCI bus.
* USB device drivers - these use the services provided by the USB core in 
order to provide support for a specific device (e.g. USB mass storage, webcam 

You can think of it like this:

Things using block / webcam / whatever
USB Client Device Driver (block / webcam / whatever)
USB Core (generic services for client device drivers)
USB Host Controller Driver

I'm writing a Xen Virtual Host Controller driver that will run in unprivileged 
domains.  Instead of talking to a hardware host controller, it'll relay 
requests to a backend USB driver running in dom0.  The backend driver in dom0 
will vet the requests to make sure they are safe and then issue them to the 
device on behalf of the domain.

You can visualise this (use a fixed width font ;-) as follows:

Dom 0                               XenU dom

------------------------            -----------------------
Backend USB driver                   USB Client driver (block / 
(a USB Client Driver to  <----+      webcam / whatever)
rest of dom0 kernel)          |
------------------------      |     -----------------------
USB Core                      |      USB Core
------------------------      |     -----------------------
USB Host Controller           +----> Xen Virtual Host Controller
(talks to real hardware)             (talks to backend using shared memory)

From the XenU kernel's PoV, the Xen Virtual Host Controller looks like any 
other host controller.  However, it's really implemented entirely in software 
- the details of talking to the real host controller are taken care of in 

The shared memory interface will be OS agnostic, so BSD etc can hook in their 
own drivers here if they want (the USB subsystem has a similar structure in 
*BSD and probably any sane implementation).  I'm planning to support Linux 
2.4 first, then maybe port to 2.6.

From the user's PoV, you'll be able to say "Give this USB port [on my physical 
host] to this domain." then plug devices into it and the domain should just 
register the device and start using it.


> On Sat, 6 Nov 2004 01:44:25 +0000, Mark A. Williamson
> <mark.williamson@xxxxxxxxxxxx> wrote:
> > > Does it just work? USB storage devices would probably alter all the
> > > time in terms of their major and minor numbers, and would come and go
> > > as hot pluggable devices do. Maybe udev takes care of all this though.
> >
> > Weeell, as long as you keep the thing plugged in while you're using it
> > you shouldn't have any problems exporting the device like any other block
> > device, so in that sense it should work fine.
> >
> > Unfortunately, as you rightly point out, by the time you've rebooted dom0
> > and plugged / unplugged devices a few times you may find that your USB
> > storage device has different major / minor.  On non-udev setups, it's
> > quite possibly going to have a different device node altogether, which
> > will mean your config file needs updating...
> >
> > I tend to agree that udev should solve this problem, however, since
> > you'll be able to configure that device to always bind to the same device
> > node. Whenever you create the domain, it'll look up the major / minor
> > associated with that device node and everything should work fine.
> >
> > Cheers,
> > Mark
> >
> > > I ask because i'm interested in doing this too.
> > >
> > > James
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by:
> > > Sybase ASE Linux Express Edition - download now for FREE
> > > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > > http://ads.osdn.com/?ad_idU88&alloc_id065&op=Click
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.sourceforge.net/lists/listinfo/xen-devel

This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>