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<mst@xxxxxxxxxx> > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
