Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO

[Anthony Liguori <anthony@codemonkey.ws>]

Anthony Liguori wrote:
>
> This could correspond to a:
>
> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t 
> size, int is_write);
>
> void cpu_physical_memory_unmap(target_physical_addr_t addr, ram_addr_t 
> size, void *mapping, int is_dirty);

A really nice touch here, and note this is optional and can be a follow 
up series later, would be to use the mapping itself to encode the 
physical address and size so the signatures were:

void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size, 
int flags);
void cpu_physical_memory_unmap(void *mapping);

flags could be PHYS_MAP_READ and/or PHYS_MAP_WRITE.

In unmap, you could check to see if the address is in phys_ram_base ... 
phys_ram_size.  If so, you can get the physical address.

If you maintained a list of mappings, you could then search the list of 
mappings based on the physical address and check the flags to see if a 
flush was required.

If you also stored the address in the list, you could search on unmap if 
the address was not in phys_ram_base .. phys_ram_size (which implies a 
bounce buffer).

Another potential optimization would be to provide a mechanism to 
explicitly set the dirty range of a physical mapping.  For instance:

cpu_physical_memory_map_set_dirty(void *start, ram_addr_t size);

That would let you only copy the data that actually needed to.  I think 
we can probably ignore this later optimization for a while though.

Regards,

Anthony Liguori

> The whole dma.c thing should not exist.  If we're going to introduce a 
> higher level API, it should be a PCI DMA API.
>
> Something like virtio could use this API directly seeing as it doesn't 
> really live on a PCI bus in real life.
>
> Regards,
>
> Anthony Liguori
>