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.
--
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
