On Wed, 06 Feb 2008 15:18:55 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: FUJITA Tomonori <[EMAIL PROTECTED]> > Date: Thu, 07 Feb 2008 08:12:36 +0900 > > > Really sorry about it. > > I am happy to test patches you send to me in the future :-) Thanks a lot. > > PARISC, Alpha, and IA64 IOMMUs use the two-pass algorithm like SPARC > > but their first pass decides how to merge sg entires (and stores that > > information in the sg entries), then the second pass simpliy follows > > it (Hopefully I understand these IOMMUs correctly, or else I break > > them too). > > For now I've removed all of the merging code from the sparc64 IOMMU > support so that other users do not get corrupt filesystems. It > basically mimicks how the intel-iommu code works, ie. no attempts to > merge anything. I've just saw it. > I intend to put merging back in, perhaps something similar to > powerpc's merging logic but without the expensive (in my opinion) > IOMMU allocation every loop. I think it is better to determine the > segment breaks in one pass, allocate that many IOMMU entries in one > allocation, then fill them all in. I thought about asking you if I can modify the SPARC IOMMUs to do allocation in every loop. The reason why I need the allocation in every loop is that I also need to fix the problem that IOMMUs allocate memory areas without considering a low level driver's segment boundary limits. http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-11/msg07616.html http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-12/msg02286.html As far as I know, all the IOMMUs except for SPARC allocate a free area in every loop but if it's too expensive for SPARC, then we need to find a different way to handle segment boundary limits. > Ideally, we should have some generic code that does all of this. > Then you would only need to test one implementation. > > It is definitely doable and increasingly necessary as we have so > many reimplementations of what is essentially identical core code. Agreed though it's a very hard task. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
