From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbEDJ-0006By-7W for qemu-devel@nongnu.org; Mon, 27 Jun 2011 11:59:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbEDG-0003Cz-R1 for qemu-devel@nongnu.org; Mon, 27 Jun 2011 11:59:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbEDG-0003Cq-AD for qemu-devel@nongnu.org; Mon, 27 Jun 2011 11:59:02 -0400 Date: Mon, 27 Jun 2011 18:59:20 +0300 From: "Michael S. Tsirkin" Message-ID: <20110627155920.GB5614@redhat.com> References: <1309180927-19003-1-git-send-email-avi@redhat.com> <4E089DFF.3090401@redhat.com> <20110627155216.GA5614@redhat.com> <4E08A79D.7010606@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E08A79D.7010606@redhat.com> Subject: Re: [Qemu-devel] [RFC v2 00/20] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On Mon, Jun 27, 2011 at 06:54:05PM +0300, Avi Kivity wrote: > On 06/27/2011 06:52 PM, Michael S. Tsirkin wrote: > >On Mon, Jun 27, 2011 at 06:13:03PM +0300, Avi Kivity wrote: > >> 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). > > > >Per spec, VGA is special: > >- bridges have VGA enable bit > > > >The VGA Enable bit in the Bridge Control register (see Section 3.2.5.18) > >is used to control response by the bridge to both the VGA frame buffer > >addresses and to the VGA register addresses. When a VGA compatible > >device is located downstream of a PCI-to-PCI bridge, the VGA Enable bit > >must be set. When set, the bridge will positively decode and forward > >memory accesses to VGA frame buffer addresses and I/O accesses to VGA > >registers from the primary to secondary interface and block forwarding > >of these same accesses from the secondary to primary interface (see > >Section 4.5.1). > >VGA memory addresses: > >0A 0000h through 0B FFFFh > >VGA I/O addresses (including ISA aliases address - AD[15::10] are not > >decoded): > >AD[9::0] = 3B0h through 3BBh and 3C0h through 3DFh > >The bridge does not decode or forward VGA BIOS memory addresses when the > >VGA Enable bit is set. ROM code provided by PCI compatible devices may > >be mapped to any address in PCI memory address space via the Expansion > >ROM Base Address register in the device's configuration header and must > >be copied to system memory before execution. > > > > Okay, looks like generalized clipping is needed. It's nice anyway > and guarantees me a job for life as maintainer of memory.c. > > > >- bridges might also enable subtractive decoding > > (required for isa behind the bridge) > > What does that mean? subtractive decoding is a method of address decoding in which a device accepts all accesses not positively decoded by another agent. > -- > error compiling committee.c: too many arguments to function