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

[Avi Kivity]

On 11/18/2010 01:42 AM, Anthony Liguori wrote:
> > 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).

KVM not supporting SMM is a bug (albeit one that is likely to remain 
unresolved for a while).  Let's pretend that kvm smm support is not an 
issue.

IIUC, SMM means that there two memory maps when the cpu accesses memory, 
one for SMM, one for non-SMM.

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

Things aren't that bad - a ram_addr_t and a physical address are already 
different things, so we already have one level of translation.

--
error compiling committee.c: too many arguments to function