* On Friday 26 Sep 2008 14:29:24 Joerg Roedel wrote: > On Fri, Sep 26, 2008 at 01:26:19PM +0530, Amit Shah wrote: > > * On Monday 22 Sep 2008 23:51:21 Joerg Roedel wrote: > > > This patch enables stackable dma_ops on x86. To do this, it also > > > enables the per-device dma_ops on i386. > > > > > > Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]> > > > --- > > > arch/x86/kernel/pci-dma.c | 26 ++++++++++++++++++++++++++ > > > include/asm-x86/device.h | 6 +++--- > > > include/asm-x86/dma-mapping.h | 14 +++++++------- > > > 3 files changed, 36 insertions(+), 10 deletions(-) > > > > > > diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c > > > index b990fb6..2e517c2 100644 > > > --- a/arch/x86/kernel/pci-dma.c > > > +++ b/arch/x86/kernel/pci-dma.c > > > @@ -82,6 +82,32 @@ void x86_register_dma_ops(struct dma_mapping_ops > > > *ops, write_unlock_irqrestore(&dma_ops_list_lock, flags); > > > } > > > > > > +struct dma_mapping_ops *find_dma_ops_for_device(struct device *dev) > > > +{ > > > + int i; > > > + unsigned long flags; > > > + struct dma_mapping_ops *entry, *ops = NULL; > > > + > > > + read_lock_irqsave(&dma_ops_list_lock, flags); > > > + > > > + for (i = 0; i < DMA_OPS_TYPE_MAX; ++i) > > > + list_for_each_entry(entry, &dma_ops_list[i], list) { > > > + if (!entry->device_supported) > > > + continue; > > > + if (entry->device_supported(dev)) { > > > + ops = entry; > > > + goto out; > > > + } > > > + } > > > +out: > > > + read_unlock_irqrestore(&dma_ops_list_lock, flags); > > > > For PVDMA, we want the "native" dma_ops to succeed first, eg, nommu, and > > then do our "PV DMA", which is just translating gpa to hpa and then > > program the hardware. This isn't being done here. This can be done by > > extending the return type: > > > > DMA_DEV_NOT_SUPPORTED > > DMA_DEV_HANDLED > > DMA_DEV_PASS > > > > Where NOT_SUPPORTED means we should look for the next one in the chain > > (current return value 0), DEV_HANDLED means the dma operation has been > > handled successfully (current return value 1) and DEV_PASS means fall > > back to the next layer and then return back. > > I am not sure I fully understand what you mean? Why do we need to call > nommu handlers first for PVDMA devices?
For the usual dma_alloc_coherent, dma_map_single, etc. routines. They return the gpa to the driver. We want to intercept this gpa and convert it to the hpa before passing on the value to the driver. So our dma_alloc_coherent will assume the real underlying alloc_coherent has succeeded and then make a hypercall. The PV dma_ops routines won't do the usual allocation, etc. that's already done elsewhere. > I think that PVDMA devices must always be handled by a pv-dma_ops > implementation. So it makes more sense for me to assign the the dma_ops > of this implementation to the per-device dma_ops structure when we do > the first call to the dma api. So we pay this overhead of finding out > who is responsible only once and not at every call to the dma api. > > Joerg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html