|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO |
Date: | Sat, 13 Dec 2008 16:47:07 -0600 |
User-agent: | Thunderbird 2.0.0.17 (X11/20080925) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |