[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.