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

[Anthony Liguori]

On 11/16/2010 03:24 PM, 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.
>    

Yup.  As Gleb mentions, there's the SDRAM register which controls 
whether 0xa0000 is mapped to PCI or whether it's mapped to RAM (but KVM 
explicitly disabled SMM support).

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

Today we model on flat space that's a mixed of device memory, RAM, or 
ROM.  This is not how machines work and the limitations of this model is 
holding us back.

IRL, there's a block of RAM that's connected to a memory controller.  
The CPU is also connected to the memory controller.  Devices are 
connected to another controller which is in turn connected to the memory 
controller.  There may, in fact, be more than one controller between a 
device and the memory controller.

A controller may change the way a device sees memory in arbitrary ways.  
In fact, two controllers accessing the same page might see something 
totally different.

The idea behind the RAM API is to begin to establish this hierarchy.  
RAM is not what any particular device sees--it's actual RAM.  IOW, the 
RAM API should represent what address mapping I would get if I talked 
directly to DIMMs.

This is not what RamBlock is even though the name would suggest 
otherwise.  RamBlocks are anything that qemu represents as cache 
consistency directly accessable memory.  Device ROMs and areas of device 
RAM are all allocated from the RamBlock space.

So the very first task of a RAM API is to simplify differentiate these 
two things.  Once we have the base RAM API, we can start adding the 
proper APIs that sit on top of it (like a PCI memory API).

Regards,

Anthony Liguori

> Alex
>
>
>