Messages in this thread | | | Subject | Re: [PATCH v2 -mm 0/2] x86: per-device dma_mapping_ops | From | FUJITA Tomonori <> | Date | Wed, 28 May 2008 19:19:32 +0900 |
| |
On Tue, 27 May 2008 11:24:08 +0530 Amit Shah <amit.shah@qumranet.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.
| |