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-ia64-devel

Re: [Xen-ia64-devel] [RFC] gnttab unmap_and_replace

To: Alex Williamson <alex.williamson@xxxxxx>
Subject: Re: [Xen-ia64-devel] [RFC] gnttab unmap_and_replace
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Wed, 6 Jun 2007 12:44:03 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 05 Jun 2007 20:42:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1181070488.6221.273.camel@bling>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070605142710.GB25309%yamahata@xxxxxxxxxxxxx> <1181070488.6221.273.camel@bling>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
I attached the updated patch for those who want to try.


On Tue, Jun 05, 2007 at 01:08:07PM -0600, Alex Williamson wrote:

>    Just to make sure I understand this DMA tracking... swiotlb only
> needs to track pages that that are accessed by the I/O device directly.
> The bounce buffer pool is presumably already pinned.  This leaves only
> the individual mappings that don't use that pool, correct?  With a
> hardware iommu the I/O device accesses unpinned memory whether it goes
> through the iommu address space or not.  So all mappings need to be
> tracked.  Correct?

It's same to my understanding.


> > @@ -1027,6 +1087,9 @@ void sba_unmap_single(struct device *dev
> >                         mark_clean(bus_to_virt(iova), size);
> >                 }
> >  #endif
> > +#ifdef CONFIG_XEN
> > +               gnttab_dma_unmap_page(iova);
> 
>    This interface can map multiple pages, so shouldn't we iterate
> through them? 

Yeah. So Is the following part of the update patch necessary
independent of dma tracking?

@@ -1016,7 +1074,8 @@ void sba_unmap_single(struct device *dev
        ASSERT(ioc);
 
 #ifdef ALLOW_IOV_BYPASS
-       if (likely((iova & ioc->imask) != ioc->ibase)) {
+       if (likely((iova & ioc->imask) != ioc->ibase) &&
+           !range_straddles_page_boundary(bus_to_virt(iova), size)) {
                /*
                ** Address does not fall w/in IOVA, must be bypassing
                */


>    I think the above should probably work, but I'm concerned about the
> overhead.  We're adding one hypercall per scatterlist entry on the sg
> mapping path (we already have 2 virt to machine lookups on the map
> single path... not optimal).  If we had the gnttab interface that didn't
> do it's own lookup, we might be able to put this in sba_io_pdir_entry()
> to avoid the extra hypercall.  Thanks again for looking at this.

Agreed.
The grant table API should only mark/unmark that the page is under DMA,
thus we can reduce/optimise address conversion overhead.

-- 
yamahata

Attachment: 15173_2d56bb613bed_dma_tracking_sba_iommu_c.patch
Description: Text Data

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel