On 2011-05-18 17:37, Avi Kivity wrote: >>> void memory_region_init_ram(MemoryRegion *mr, >>> target_phys_addr_t size); >>> void memory_region_init_ram_ptr(MemoryRegion *mr, >>> target_phys_addr_t size, >>> void *ptr); >>> void memory_region_destroy(MemoryRegion *mr); >>> void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t >>> offset); >> >> What's "offset" mean? > > It's the equivalent of cpu_register_physical_memory_offset(). > > Note the intent is to have addresses always be relative to the innermost > container. Perhaps we can get away without offset. Offset is supposed to support the transition of devices that expect absolute I/O addresses in their callbacks to those that are fine with relative ones (based on the region start). This API change is a good chance to finally get rid of the former group. > >> >>> void memory_region_set_log(MemoryRegion *mr, bool log); >>> void memory_region_clear_coalescing(MemoryRegion *mr); >>> void memory_region_add_coalescing(MemoryRegion *mr, >>> target_phys_addr_t offset, >>> target_phys_addr_t size); >> >> I don't think it's worth while to try to fit coalescing into this API. >> It's a KVM specific hack. I think it's fine to be a hacked on API. > > The problem is that only the device knows about coalescing, while the > region can be mapped, unmapped, or moved without device knowledge. So > if a PCI is unmapped and then remapped (possibly at a different address) > we need to tell kvm about it, but there is no device callback involved. Doesn't Xen use coalescing as well, or could use? It looks like a generic optimization feature for hypervisors that want to build on top of QEMU. Jan