qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] dma_rw.h (was Re: [PATCH 0/7] AMD IOMMU emu


From: Eduard - Gabriel Munteanu
Subject: Re: [Qemu-devel] [PATCH RFC] dma_rw.h (was Re: [PATCH 0/7] AMD IOMMU emulation patchset v4)
Date: Thu, 16 Sep 2010 10:12:12 +0300
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Sep 13, 2010 at 03:45:34PM -0500, Anthony Liguori wrote:
> On 09/13/2010 03:01 PM, Michael S. Tsirkin wrote:
> > So I think the following will give the idea of what an API
> > might look like that will let us avoid the scary hacks in
> > e.g. the ide layer and other generic layers that need to do DMA,
> > without either binding us to pci, adding more complexity with
> > callbacks, or losing type safety with casts and void*.
> >
> > Basically we have DMADevice that we can use container_of on
> > to get a PCIDevice from, and DMAMmu that will get instanciated
> > in a specific MMU.
> >
> > This is not complete code - just a header - I might complete
> > this later if/when there's interest or hopefully someone interested
> > in iommu emulation will.
> >
> > Notes:
> > the IOMMU_PERM_RW code seem unused, so I replaced
> > this with plain is_write. Is it ever useful?
> >
> > It seems that invalidate callback should be able to
> > get away with just a device, so I switched to that
> > from a void pointer for type safety.
> > Seems enough for the users I saw.
> >
> > I saw devices do stl_le_phys and such, these
> > might need to be wrapped as well.
> >
> > Signed-off-by: Michael S. Tsirkin<address@hidden>
> >    
> 
> One of the troubles with an interface like this is that I'm not sure a 
> generic model universally works.
> 
> For instance, I know some PCI busses do transparent byte swapping.  For 
> this to work, there has to be a notion of generic memory reads/writes 
> vs. reads of a 32-bit, 16-bit, and 8-bit value.
> 
> With a generic API, we lose the flexibility to do this type of bus 
> interface.
> 
> Regards,
> 
> Anthony Liguori
> 

[snip]

I suppose additional callbacks that do the actual R/W could solve this.
If those aren't present, default to cpu_physical_memory_*().

It should be easy for such a callback to decide on a case-by-case basis
depending on the R/W transaction size, if this is ever needed.


        Eduard




reply via email to

[Prev in Thread] Current Thread [Next in Thread]