WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[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