[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 _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |