Re: [PATCH v2 -mm 0/2] x86: per-device dma_mapping_ops

[Amit Shah]

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.

What is the plan with this patch then? When do you plan to ask for mainline 
merging?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/