From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50856 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIeMN-0003Cy-VS for qemu-devel@nongnu.org; Wed, 17 Nov 2010 04:31:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIeMM-0004uG-LM for qemu-devel@nongnu.org; Wed, 17 Nov 2010 04:31:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIeMM-0004u0-Am for qemu-devel@nongnu.org; Wed, 17 Nov 2010 04:31:22 -0500 Date: Wed, 17 Nov 2010 11:31:14 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH v2 2/2] RAM API: Make use of it for x86 PC Message-ID: <20101117093114.GT7948@redhat.com> References: <20101101150701.3927.88854.stgit@s20.home> <20101101151415.3927.87944.stgit@s20.home> <4CE29C15.7040704@codemonkey.ws> <1289942646.3069.38.camel@x201> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1289942646.3069.38.camel@x201> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw@redhat.com, kvm@vger.kernel.org, mst@redhat.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, ddutile@redhat.com On Tue, Nov 16, 2010 at 02:24:06PM -0700, Alex Williamson wrote: > On Tue, 2010-11-16 at 08:58 -0600, Anthony Liguori wrote: > > On 11/01/2010 10:14 AM, Alex Williamson wrote: > > > Register the actual VM RAM using the new API > > > > > > Signed-off-by: Alex Williamson > > > --- > > > > > > hw/pc.c | 12 ++++++------ > > > 1 files changed, 6 insertions(+), 6 deletions(-) > > > > > > diff --git a/hw/pc.c b/hw/pc.c > > > index 69b13bf..0ea6d10 100644 > > > --- a/hw/pc.c > > > +++ b/hw/pc.c > > > @@ -912,14 +912,14 @@ void pc_memory_init(ram_addr_t ram_size, > > > /* allocate RAM */ > > > ram_addr =3D qemu_ram_alloc(NULL, "pc.ram", > > > below_4g_mem_size + above_4g_mem_size= ); > > > - cpu_register_physical_memory(0, 0xa0000, ram_addr); > > > - cpu_register_physical_memory(0x100000, > > > - below_4g_mem_size - 0x100000, > > > - ram_addr + 0x100000); > > > + > > > + qemu_ram_register(0, 0xa0000, ram_addr); > > > + qemu_ram_register(0x100000, below_4g_mem_size - 0x100000, > > > + ram_addr + 0x100000); > > > #if TARGET_PHYS_ADDR_BITS> 32 > > > if (above_4g_mem_size> 0) { > > > - cpu_register_physical_memory(0x100000000ULL, above_4g_mem_si= ze, > > > - ram_addr + below_4g_mem_size); > > > + qemu_ram_register(0x100000000ULL, above_4g_mem_size, > > > + ram_addr + below_4g_mem_size); > > > } > > > =20 > >=20 > > Take a look at the memory shadowing in the i440fx. The regions of=20 > > memory in the BIOS area can temporarily become RAM. > >=20 > > That's because there is normally RAM backing this space but the memory= =20 > > controller redirects writes to the ROM space. > >=20 > > Not sure the best way to handle this, but the basic concept is, RAM=20 > > always exists but if a device tries to access it, it may or may not be= =20 > > accessible as RAM at any given point in time. >=20 > Gack. For the benefit of those that want to join the fun without > digging up the spec, these magic flippable segments the i440fx can > toggle are 12 fixed 16k segments from 0xc0000 to 0xeffff and a single > 64k segment from 0xf0000 to 0xfffff. There are read-enable and > write-enable bits for each, so the chipset can be configured to read > from the bios and write to memory (to setup BIOS-RAM caching), and read > from memory and write to the bios (to enable BIOS-RAM caching). The > other bit combinations are also available. >=20 There is also 0xa0000=E2=88=920xbffff which is usually part of framebuffer,= but chipset can be configured to access this memory as RAM when CPU is in SMM mode. > For my purpose in using this to program the IOMMU with guest physical to > host virtual addresses for device assignment, it doesn't really matter > since there should never be a DMA in this range of memory. But for a IIRC spec defines for each range of memory if it is accessed from PCI bus. > general RAM API, I'm not sure either. I'm tempted to say that while > this is in fact a use of RAM, the RAM is never presented to the guest as > usable system memory (E820_RAM for x86), and should therefore be > excluded from the RAM API if we're using it only to track regions that > are actual guest usable physical memory. A guest is no only OS (like Windows or Linux), but the bios code is also pa= rt of the guest and it can access all of this memory. >=20 > We had talked on irc that pc.c should be registering 0x0 to > below_4g_mem_size as ram, but now I tend to disagree with that. The > memory backing 0xa0000-0x100000 is present, but it's not presented to > the guest as usable RAM. It is, during SMM, if bios configured chipset to do so. =20 > What's your strict definition of what the RAM > API includes? Is it only what the guest could consider usable RAM or > does it also include quirky chipset accelerator features like this > (everything with a guest physical address)? Thanks, >=20 -- Gleb.