[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/4] amd iommu: Large io page support - enablement
On 03/12/2010 08:45, "Wei Wang2" <wei.wang2@xxxxxxx> wrote: > On Friday 03 December 2010 17:24:53 Keir Fraser wrote: >> Well, let's see. The change to p2m_set_entry() now allows (superpage) calls >> to the iommu mapping functions even if !need_iommu(). That seems a semantic >> change. > That is because we have iommu_populate_page_table() which will delay io page > table construction until device assignment. But this function can only > updates io page table with 4k entries. I didn't find a better way to tracking > page orders after page allocation (Q: could we extend struct page_info to > cache page orders?). So my thought is to update IO page table earlier. And > therefore, enabling super io page will also disable lazy io page table > construction. How about hiding the superpage mapping stuff entirely within the existing iommu_[un]map_page() hooks? If you have 9 spare bits per iommu pde (seems very likely), you could cache in the page-directory entry how many entries one level down currently are suitable for coalescing into a superpage mapping. When a new iommu pte/pde is written, if it is a candidate for coalescing, increment the parent pde's count. If the count == 2^superpage_order, then coalesce. You can maintain such counts in every pde up the hierarchy, for 2MB, 1GB, ... superpages. Personally I think we could do similar for ordinary host p2m maintenance as well, if the bits are available. With 64-bit entries, we probably have sufficient bits (we only need 9 spare bits). What we have now for host p2m maintenance I can't say I love very much, and I don't think we need follow that as a model for how we introduce superpage mappings to iommu pagetables. Anyway, this would make your patch only touch AMD code. Similar could be done on the Intel side later, and for bonus points at that point perhaps this coalescing/uncoalescing logic could be pulled out to some degree into shared code. -- Keir > Also, without need_iommu() checking both passthru and non-passthru guests will > get io page table allocation. Since super paging will highly reduce io page > table size, we might not waste too much memories here... _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |