On 06/27/2011 06:37 PM, Anthony Liguori wrote:
On 06/27/2011 08:21 AM, Avi Kivity wrote:
As expected, this is taking longer than expected, so I'm releasing
something
less complete than I'd have liked. Not even all of the PC machine is
converted, but the difficult parts are (cirrus). It appears to work
well.
The major change compared to v1 is the introduction of
memory_region_init_alias(), which defines a memory region in terms of
another.
With the current API, the ability to alias is provided by address
arithmetic
on ram_addr_t:
ram_addr = qemu_ram_alloc(...);
cpu_register_physical_memory(..., ram_addr, size, ...);
/* alias: */
cpu_register_physical_memory(..., ram_addr + offset, another_size,
...);
With the new API, you have to create an alias:
memory_region_init_ram(&mem, ...);
memory_region_register_subregion(...,&mem);
/* alias: */
memory_region_init_alias(&alias, ...,&mem, offset, another_size);
memory_region_register_subregion(...,&alias);
What's the rationale for explicit aliasing verses registering the same
region to two different address spaces?
Two:
- an alias is usually just a portion of the original region (vga
windows; the two main RAM sections below and above 4GB); so we need an
object to hold the differences
- easier for the implementation (a MemoryRegion object can be in just
one child list instead of many)
While I can work around the implementation difficulties, there's no
point since the alias is usually not identical to the origin, so we need
a new object anyway.
(ram_addr_t works around that by carrying the offset in the handle, and
letting the caller carry the size).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
