| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [RFC SWIOTLB-0.2]
|
To: |
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [RFC SWIOTLB-0.2] |
|
From: |
Chris Wright <chrisw@xxxxxxxxxxxx> |
|
Date: |
Thu, 14 Jan 2010 18:25:10 -0800 |
|
Cc: |
chrisw@xxxxxxxxxxxx, jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian.Campbell@xxxxxxxxxxxxx, joerg.roedel@xxxxxxx, fujita.tomonori@xxxxxxxxxxxxx, iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx, dwmw2@xxxxxxxxxxxxx, alex.williamson@xxxxxx |
|
Delivery-date: |
Thu, 14 Jan 2010 18:25:55 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<1263510064-16788-1-git-send-email-konrad.wilk@xxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<1263510064-16788-1-git-send-email-konrad.wilk@xxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mutt/1.5.19 (2009-01-05) |
* 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
|
|
|
| |
|
Home