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

Avi Kivity
2008-12-14T06:07:17Z

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.