Re: [Qemu-devel] [RFC v2 00/20] Memory API

[Avi Kivity]

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