From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbDzA-0001vK-Vg for qemu-devel@nongnu.org; Mon, 27 Jun 2011 11:44:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbDz8-0000o8-78 for qemu-devel@nongnu.org; Mon, 27 Jun 2011 11:44:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbDz7-0000nl-Ha for qemu-devel@nongnu.org; Mon, 27 Jun 2011 11:44:25 -0400 Message-ID: <4E08A553.5060207@redhat.com> Date: Mon, 27 Jun 2011 18:44:19 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1309180927-19003-1-git-send-email-avi@redhat.com> <4E08A3C6.5080409@codemonkey.ws> In-Reply-To: <4E08A3C6.5080409@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 00/20] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org 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