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<alex.williamson@xxxxxxxxxx>
> > > ---
> > >
> > > 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
