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

[Alex Williamson]

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.

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

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

Alex