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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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, theAlso 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel