qemu-devel
[Top][All Lists]
Advanced

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

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


From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Date: Sun, 14 Dec 2008 08:07:09 +0200
User-agent: Thunderbird 2.0.0.18 (X11/20081119)

Anthony Liguori wrote:
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.


That will come back and bite us when we implement memory slots (for memory hotplug, etc.). You want here to return two values - a pointer for the caller's use, and some information for unmap's use. The best thing to do is return two values instead of having unmap() try to figure out the things that map() has already calculated.



--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





reply via email to

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