[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080528191932Z.fujita.tomonori@lab.ntt.co.jp>
Date: Wed, 28 May 2008 19:19:32 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: amit.shah@...ranet.com
Cc: fujita.tomonori@....ntt.co.jp, muli@...ibm.com,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
alexisb@...ibm.com, andi@...stfloor.org, kvm@...r.kernel.org,
avi@...ranet.com
Subject: Re: [PATCH v2 -mm 0/2] x86: per-device dma_mapping_ops
On Tue, 27 May 2008 11:24:08 +0530
Amit Shah <amit.shah@...ranet.com> wrote:
> On Tuesday 27 May 2008 10:54:06 FUJITA Tomonori wrote:
>
> > > An example with per-device dma_ops and stacking will look like this:
> > >
> > > pvdma->hardware->nommu/swiotlb
> > > ^ ^
> > >
> > > e1000 rtl8139
> > >
> > > And this scheme is going to suit everyone, agreed?
> > >
> > > This is simple and doesn't need too many changes all around.
> >
> > Sorry, I'm not sure what this picture represents.
>
> It meant to show just e1000 needs to go through the pvdma translations.
> rtl8139 goes via the other iommus. e1000 also goes through the other iommus
> (mainly if it's going to be the swiotlb that a guest might need).
>
> > BTW, without pvdma, there is no need to hardware->nommu/swiotlb
> > stacking for IOMMUs like Calgary. Per-device dma_ops wor for them.
>
> Hmm, ok. Then this argument doesn't count.
>
> > > I was suggesting something more than this that can handle cases like an
> > > iommu wanting to have each device behind a bus to pass through it (it's
> > > still possible, but needs a per-device walk). Also, in the scenario
> > > depicted above, each device will start by pointing to the first iommu in
> > > the chain (pvdma in this case) and the iommu will then determine if that
> > > device needs to be passed via its translations.
> >
> > No, IOMMUs doesn't need to do that. We need to put a stacking
> > mechanism in dma-mapping.h. A stacking mechanism should not be visible
> > to IOMMUs.
>
> OK; then just per-device dma_ops will work and for the pvdma case, we'll have
> to have the stacking. Since this is a special case, any kind of generic APIs
> shouldn't be needed as well.
I'm not sure what you mean exactly, but there might be other people
who want to use the dma_ops stacking though I'm not sure yet how they
use it:
http://lkml.org/lkml/2008/5/15/79
> What is the plan with this patch then? When do you plan to ask for mainline
> merging?
Andrew already put this patchset in -mm. Unless someone comes with a
new reason against this patchset, it will be merged, I think.
BTW, Andrew, really sorry about several compile bugs due to the first
patch (changing dma_mapping_error) in this patchset. And thanks a lot
for fixing them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists