[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

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