Here''s the final snapshot before I try to update to the latest, Ewan-flavoured xenbus. This snapshot of the USB code fixes a couple of bugs over the last one: the phys_to_machine mapping is cleaned up after grant table access is completed. This avoids a BUG in the balloon driver which is triggered if you free up and then attempt to reallocate an empty_page_range. I was hitting this when unloading and reloading the back-end module while performing I/O. There''s also some code there to set the dma_mask of the xenbus device in an attempt to get the USB code to use dma_alloc_coherent for its buffers. This code seems to work in the front-end but the memory-mapping in the backend stops working so it''s disabled for the time being. It''s still necessary to use swiotlb=force to get this code to work reliably but aside from that and the possible issue with a deadlock on unregistering the backend watch which I haven''t seen for a while (fixed in the tree?) it seems to work reasonably well on my hardware. Remaining work: o - sync up with latest xenbus change o - work out what to do about the swiotlb problem o - reformat to kernel coding style o - split patch up into manageable chunks for review and patch submission o - more testing: need to test using USB 2.0 HW (my test machine is 1.2) o - run the USB code by the usb mailing list o - fix remaining FIXMEs in code, error codes in particular. o - more comments and API documentation _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Nov 15, 2005 at 11:00:21AM +0000, harry wrote:> Here''s the final snapshot before I try to update to the latest, > Ewan-flavoured xenbus.Speaking of which, do you need any help with this? If you''ve got code that works with the old tree, I''m happy to give you a hand moving over to the new one. I thought you were using your own abstraction layer anyway though, so I don''t know how much of your stuff will be broken. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2005-11-15 at 15:12 +0000, Ewan Mellor wrote:> On Tue, Nov 15, 2005 at 11:00:21AM +0000, harry wrote: > > > Here''s the final snapshot before I try to update to the latest, > > Ewan-flavoured xenbus. > > Speaking of which, do you need any help with this? If you''ve got code that > works with the old tree, I''m happy to give you a hand moving over to the new > one.You probably have more urgent things to do but if you''d like to play around with the new USB code and try to load/unload modules and kill FE/BE domains etc then you might find that useful for flushing out bugs in the new xenbus code. The USB driver used to be fairly robust against these dynamic changes but seems more fragile now.> > I thought you were using your own abstraction layer anyway though, so I don''t > know how much of your stuff will be broken.BTW, xenidc is no more an "abstraction layer" than xenbus. xenidc is a service implementing a high-level inter-domain communication and bulk-data transfer API. i.e. it actually implements a big chunk of useful code and it''s not simply a different set of names for the underlying grant-table and xenbus APIs. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel