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