USB virt port to 2.6 status

USB virt port to 2.6 status

[Harry Butterworth]

I've been working on porting the USB virtualisation code to the 2.6
kernel for a while now.  It took some time to get up to speed with Xen,
Linux 2.6, USB and the existing 2.4 USB virtualisation code but I'm
starting to make progress.

Up until last week I was trying to get the 2.4 code to compile for 2.6
and was eventually successful but in the process discovered just how
much the USB stack and the Linux device model had changed between 2.4
and 2.6---the code resulting from the forward porting effort was not
pretty and simply fixing the compile errors was not sufficient to
integrate into the new linux device model.  I didn't bother testing this
effort as it was obviously not going to work.

This week I started on a rewrite of the usb front end driver based on
the 2.6 infrastructure and have gone with the following approach:

I created a new bus device to represent a virtual bus where each USB
back-end will be represented as a device.

I created a new device for the above bus to represent a USB back-end.

I created a new driver to drive instances of the above devices. The
driver creates a new virtual USB host controller for each device
instance (i.e. one per back-end). The virtual USB host controller is
created using the USB hc_driver interface which is new to 2.6 and
eliminates redundancy in the host controller driver implementations.

This framework is all present in a single loadable module and currently
loads into 2.6, installs the bus and driver and a dummy device, the
driver gets matched to the device and successfully creates a virtual USB
host controller. All the objects appear in sysfs OK.

Next step is to create a test machine with a 2.4 dom0 and working USB
devices and construct the 2.6 front end within the new 2.6 framework by
porting forwards the remaining function from the 2.4 code.
After that I'll work on the 2.6 back end which I expect to be easier.

I'm expecting to have to make changes to this new code for the new
persistent store mechanism for discovery and hotplug. Specifically, I'm
expecting that the new bus device will probably be moved out of the usb
front end driver and made common between all xen virtualised devices and
that this bus will perform discovery using the persistent store.

Once I'm done with both the 2.6 back and front end code I'll look at
commoning up code between the 2.4 and 2.6 drivers.

Any comments on approach etc welcome.

Harry.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: USB virt port to 2.6 status

[Nivedita Singhvi]

Harry Butterworth wrote:

> I created a new bus device to represent a virtual bus where each USB
> back-end will be represented as a device.

[Harry, not sure I understood your scheme fully, so excuse a few
dumb questions]

I'm assuming that means: real USB Device = 1 backend?

Does this need to remain USB specific or could this
virtual bus be generalized to include a broader range
of devices?

> I created a new device for the above bus to represent a USB back-end.

So this is something present only on dom0/driver domains?
I'm a little confused by what the guest domains (front-end
domains) see as a device(?).

> I created a new driver to drive instances of the above devices. The
> driver creates a new virtual USB host controller for each device
> instance (i.e. one per back-end). The virtual USB host controller is
> created using the USB hc_driver interface which is new to 2.6 and
> eliminates redundancy in the host controller driver implementations.
> 
> This framework is all present in a single loadable module and currently
> loads into 2.6, installs the bus and driver and a dummy device, the

Also works compiled into the kernel?

> driver gets matched to the device and successfully creates a virtual USB
> host controller. All the objects appear in sysfs OK.
> 
> Next step is to create a test machine with a 2.4 dom0 and working USB
> devices and construct the 2.6 front end within the new 2.6 framework by
> porting forwards the remaining function from the 2.4 code.

Will 2.4 backends be compatible with your new 2.6 frontends?

> After that I'll work on the 2.6 back end which I expect to be easier.

Did you mean 2.6 backend (which you said you had) or 2.4?

> I'm expecting to have to make changes to this new code for the new
> persistent store mechanism for discovery and hotplug. Specifically, I'm
> expecting that the new bus device will probably be moved out of the usb
> front end driver and made common between all xen virtualised devices and
> that this bus will perform discovery using the persistent store.

Ah, good. Is anyone working on a new virtual bus infrastructure?

> Once I'm done with both the 2.6 back and front end code I'll look at
> commoning up code between the 2.4 and 2.6 drivers.

The expectation is that all the following permutations:
	2.4 be <-> 2.4 fe
	2.6 be <-> 2.4 fe
	2.4 be <-> 2.6 fe
	2.6 be <-> 2.6 fe

will work?

> Any comments on approach etc welcome.

Very interesting so far, Harry.

thanks,
Nivedita



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: USB virt port to 2.6 status

[Mark Williamson]

> > I created a new bus device to represent a virtual bus where each USB
> > back-end will be represented as a device.
>
> [Harry, not sure I understood your scheme fully, so excuse a few
> dumb questions]
>
> I'm assuming that means: real USB Device = 1 backend?

In Linux you have to create a bus device (which is not a USB device) that 
represents the USB bus.  Multiple USB devices are then associated with this 
bus device.  I think this is what Harry is referring to.

> > Once I'm done with both the 2.6 back and front end code I'll look at
> > commoning up code between the 2.4 and 2.6 drivers.

Harry, how would you feel about getting any working 2.6 code checked in before 
commoning up the drivers?  I think there's something to be said for having it 
in the tree.  The other drivers (block, net, balloon) have also gone through 
a phase of being duplicated in the tree before being merged back together...

> The expectation is that all the following permutations:
> 	2.4 be <-> 2.4 fe
> 	2.6 be <-> 2.4 fe
> 	2.4 be <-> 2.6 fe
> 	2.6 be <-> 2.6 fe
>
> will work?

I think it's realistic to aim for the USB interface to be OS independent so 
it'll work with any Linux and, potentially with other OSs too.  Harry has 
identified some minor points where the interface could usefully be tweaked 
for this purpose.

Cheers,
Mark

>
> > Any comments on approach etc welcome.
>
> Very interesting so far, Harry.
>
> thanks,
> Nivedita


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: USB virt port to 2.6 status

[Harry Butterworth]

On Wed, 2005-03-09 at 15:28 +0000, Mark Williamson wrote:
> > > I created a new bus device to represent a virtual bus where each USB
> > > back-end will be represented as a device.
> >
> > [Harry, not sure I understood your scheme fully, so excuse a few
> > dumb questions]
> >
> > I'm assuming that means: real USB Device = 1 backend?
> 
> In Linux you have to create a bus device (which is not a USB device) that 
> represents the USB bus.  Multiple USB devices are then associated with this 
> bus device.  I think this is what Harry is referring to.

So, the new hc_driver interface assumes that your USB host controllers
are bridges from another bus type to USB.

Most of the USB host controllers are PCI devices and so bridge from the
PCI bus to USB.  For those controllers there is therfore a PCI BUS and a
PCI device on the PCI bus which represents the host controller.

To make the 2.6 USB code fit in with this, I have created a new bus type
which is the equivalent of the PCI bus above. i.e. it basically
represents the inter-domain communication interface but at present only
the USB aspects of the inter-domain communication interface.

We ought to extend this bus to be a virtual bus for all the different
types of devices exported over the inter-domain communication interface.

I expect to have to rip this out and change it when the new architecture
is defined.

> Harry, how would you feel about getting any working 2.6 code checked in before 
> commoning up the drivers?

Yes, I'll check in the code as soon as it is equivalent to the 2.4 code.

> > The expectation is that all the following permutations:
> > 	2.4 be <-> 2.4 fe
> > 	2.6 be <-> 2.4 fe
> > 	2.4 be <-> 2.6 fe
> > 	2.6 be <-> 2.6 fe
> >
> > will work?

This is what I'm aiming at.

The current protocol doesn't seem to support multiple back-end domains
though. I'm going to work within this limitation for the time being.

Harry



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click