[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 03 of 38] swiotlb: allow architectures tooverrideswiotlb pool allocation
>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 14.11.08 20:33 >>> >Jan Beulich wrote: >> Not directly related to this patch alone, but to the combined set of changes >> to swiotlb: I don't see any handling of CONFIG_HIGHMEM here (or at least >> a note that this a known limitation needing work). I mention this because >> this was the largest part of the changes I had posted long ago to make >> lib/swiotlb.c Xen-ready, and which got rejected due to their ugliness. >> > >Was that Andi's objection on the grounds that he didn't think that Xen >should need swiotlb at all? No, Tony Luck actually merged it, but someone else (I don't recall who it was) requested it to be reverted again. >I have to admit I didn't follow that thread very closely (or threads, as >I seem to remember). Do you have a pointer to the pertinent bits? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=51099005ab8e09d68a13fea8d55bc739c1040ca6 >> While perhaps less intrusive to take care of, I also didn't see an equivalent >> of the range_straddles_page_boundary() logic, without which I can't see >> how this would work in the common case. >> >Could you be more specific? The swiotlb allocation should be machine >contiguous and so there's no stradding required, but I think I'm missing >your point. The question is whether a multi-page piece of memory must be funneled through the swiotlb in the first place. In native code, checking whether the first/last byte satisfies the address_needs_mapping() check is sufficient, but in Xen you also need to check whether the known to be physically contiguous pages are also machine-contiguous. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |