[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [RFC SWIOTLB-0.2]
* Konrad Rzeszutek Wilk (konrad.wilk@xxxxxxxxxx) wrote: > Another approach, which this set of patches explores, is to abstract the > address translation and address determination functions away from the > SWIOTLB book-keeping functions. This way the core SWIOTLB library functions > are present in one place, while the address related functions are in > a separate library for different run-time platforms. I would very much > appreciate input on this idea and the set of patches. It seems like it still needs some refinement, since the Xen implementation is hooking into two layers. Both: + swiotlb_register_engine(&xen_ops); and +static struct dma_map_ops xen_swiotlb_dma_ops = { Wouldn't the idea be to get to the point that you'd use common swiotlb and keep the hooks to one layer? Also, it's unclear when some of the prior global to swiotlb variables would actually be useful to a private implementation. For example, overflow, which is just 32 * 1024 in both cases. Are those really needed to be private to a swiotlb engine? Do you think you can reduce the swiotlb_engine to just the relevant ops? thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |