Re: [Qemu-devel] [PATCH v2 2/2] RAM API: Make use of it for x86 PC

[Gleb Natapov]

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<address@hidden>
> > > ---
> > >
> > >   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 = 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_size,
> > > -                                     ram_addr + below_4g_mem_size);
> > > +        qemu_ram_register(0x100000000ULL, above_4g_mem_size,
> > > +                          ram_addr + below_4g_mem_size);
> > >       }
> > >    
> > 
> > Take a look at the memory shadowing in the i440fx.  The regions of 
> > memory in the BIOS area can temporarily become RAM.
> > 
> > That's because there is normally RAM backing this space but the memory 
> > controller redirects writes to the ROM space.
> > 
> > Not sure the best way to handle this, but the basic concept is, RAM 
> > always exists but if a device tries to access it, it may or may not be 
> > accessible as RAM at any given point in time.
> 
> 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.
> 
There is also 0xa0000−0xbffff 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 part
of the guest and it can access all of this memory.

> 
> 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.
 
>                          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,
> 

--
                        Gleb.