Anthony Liguori wrote:
I think any API based on a can_dma abstraction is wrong. The
write_post_dma thing is equally wrong.
The concept of "dma" that you're introducing is not correct.
The DMA API should have the following properties:
1) You attempt to map a physical address. This effectively is a lock
or pin operation.
a) In the process of this, you get a virtual address that you can
manipulate.
2) You do your IO to the virtual address
3) You indicate how much of the memory you have dirtied
4) You unmap or unlock that memory region. The virtual address is
now no longer valid.
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);
Let me clarify this a bit more. The problem we're trying to address
today is the encapsulating knowledge of phys_ram_base. We want to
minimize the amount of code that makes any assumptions about
phys_ram_base. Your current API still accesses phys_ram_base directly
in the PCI DMA API. The only real improvement compared to the current
virtio code is that you properly handle MMIO. This is not just about
layout but this also includes the fact that in the future, guest
memory could be discontiguous in QEMU (think memory hotplug).
There are two more problems the dma api solves:
- DMA into mmio regions; this requires bouncing
- DMA with an associated transform (xor, byteswap); also requires bouncing
In turn, bouncing requires splitting large requests to avoid unbounded
memory allocation.
While I think _map/_unmap is an improvement over can_dma(), this API
can't handle bounded bouncing, and so a separate layer (dma.c) is still
necessary.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
