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

[Avi Kivity]

On 11/18/2010 06:09 PM, Anthony Liguori wrote:
> > That's what "two memory maps" mean.  If you have one cpu in SMM and 
> > another outside SMM, then those two maps are active simultaneously.
>
>
> I'm not sure if more modern memory controllers do special things here, 
> but for the i440fx, if any CPU asserts SMM mode, then any memory 
> access to that space is going to access SMRAM.

How does SMP work then?

> SMM Space Open (DOPEN). When DOPEN=1 and DLCK=0, SMM space DRAM is 
> made visible even
> when CPU cycle does not indicate SMM mode access via EXF4#/Ab7# 
> signal. This is intended to help
> BIOS initialize SMM space. Software should ensure that DOPEN=1 is 
> mutually exclusive with DCLS=1.
> When DLCK is set to a 1, DOPEN is set to 0 and becomes read only.

The words "cpu cycle does not indicate SMM mode" seem to say that SMM 
accesses are made on a per-transaction basis, or so my lawyers tell me.


> > > Alternatively, if the SMRAM register is activated, then the i440fx 
> > > will redirect 0xa0000 to RAM regardless of whether the CPU asserts 
> > > that signal.  That means that even without KVM supporting SMM, this 
> > > mode can happen.
> >
> > That's a single memory map that is modified under hardware control, 
> > it's no different than BARs and such.
>
> There is a single block of RAM.
>
> The memory controller may either forward an address unmodified to the 
> RAM block or it may forward the address to the PCI bus[1].  A non CPU 
> access goes through a controller hierarchy and may be modified while 
> it transverses the hierarchy.
>
> So really, we should have a big chunk of RAM that we associate with a 
> guest, with a list of intercepts that changes as the devices are 
> modified.  Instead of having that list dispatch directly to a device, 
> we should send all intercepted accesses to the memory controller and 
> let the memory controller propagate out the access to the appropriate 
> device.
>
> [1] The except is access to the local APIC.  That's handled directly 
> by the CPU (or immediately outside of the CPU before the access gets 
> to the memory controller if the local APIC is external to the CPU).

Agree.  However the point with SMM is that the dispatch is made not only 
based on the address, but also based on SMM mode (and, unfortunately, 
can also be different based on read vs write).

> > > > 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.
> > >
> > > Yeah, but ram_addr_t doesn't model anything meaningful IRL.  It's an 
> > > internal implementation detail.
> >
> > Does it matter?  We can say those are addresses on the memory bus.  
> > Since they are not observable anyway, who cares if the correspond 
> > with reality or not?
>
> It matters a lot because the life cycle of RAM is different from the 
> life cycle of ROM.
>
> For instance, the original goal was to madvise(MADV_DONTNEED) RAM on 
> reboot.  You can't do that to ROM because the contents matter.

I don't think you can do that to RAM either.

> But for PV devices, we can be loose in how we define the way the 
> devices interact with the rest of the system.  For instance, we can 
> say that virtio-pci devices are directly connected to RAM and do not 
> go through the memory controllers.  That means we could get stable 
> mappings of the virtio ring.

That wouldn't work once we have an iommu and start to assign them to 
nested guests.

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