From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC v2 00/20] Memory API Date: Mon, 27 Jun 2011 18:13:03 +0300 Message-ID: <4E089DFF.3090401@redhat.com> References: <1309180927-19003-1-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: qemu-devel@nongnu.org, "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15802 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751264Ab1F0PNI (ORCPT ); Mon, 27 Jun 2011 11:13:08 -0400 In-Reply-To: <1309180927-19003-1-git-send-email-avi@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/27/2011 04:21 PM, 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); > > The patchset is somewhat churny. One of the reasons is that we move from a > handle/pointer scheme in ram_addr_t to an object constructor/destructor scheme. > Another is that region size becomes a property of a region instead of being > maintained externally. Also, container memory regions must be passed around, > though we don't do that as well as we should. > > Todo: > - eliminate calls to get_system_memory() (where we ignore the bus hierarchy) > - add PCI APIs for the VGA window > - support the PIO address space using the memory API (allowing simplified > PCI BAR registration) > - convert 440FX > - convert everything else Michael, I'm looking at the pci bridge code, and it basically does the same thing - clip each BAR to the intersection of the decode window of all bridges it hides behind. How does a PCI bridge behave wrt VGA? is it a separate control? If so I probably need to implement generalized clipping (i.e. decode between 0xa0000-0xc0000 or between 0xc0000000-0xf0000000). -- error compiling committee.c: too many arguments to function