On 2011-05-19 21:02, Anthony Liguori wrote:
> On 05/19/2011 01:50 PM, Jan Kiszka wrote:
>> On 2011-05-19 20:18, Anthony Liguori wrote:
>>> Well, not really.
>>>
>>> kvm.ko has a global mapping of RAM regions and currently only allows
>>> code execution from RAM.
>>>
>>> This means the only way for QEMU to enable SMM support is to program the
>>> global RAM regions table to enable allow RAM access for the VGA region.
>>>
>>> The problem with this is that it's perfectly conceivable to have CPU 0
>>> in SMM mode while CPU 1 is doing MMIO to the VGA planar.
>>>
>>> The same problem exists with PAM.  It would be much easier to implement
>>> PAM correctly in QEMU if it were possible to execute code via MMIO as we
>>> could just mark the BIOS memory as non-RAM and deal with the dispatch
>>> ourselves.
>>
>> If we already have to change KVM (I guess we have to), let's better add
>> per-CPU memory slot support. That will allow to switch between VGA and
>> SMRAM without costly dispatching. At this chance, I think we also need
>> some support for half-MMIO (MMIO on write, RAM on read) for proper flash
>> support.
> 
> This is needed for PAM too.

Yeah, right, there were some to-do comments I strictly ignored

> 
> But RAM isn't mapped per-CPU so this is at best an optimization.

SMRAM is mapped per CPU, depending on the execution mode. That is the point.

>  You
> can (and do) execute instructions out of non-RAM memory though.  I think
> if we lifted this restriction in KVM, it would allow us to handle
> SMRAM/PAM in a more thorough way.

I do not disagree that having such feature would be nice for certain
corner cases. But executing code by jumping to user space on every
instruction fetch, maybe just to dispatch between SMRAM and normal MMIO
on a per-CPU base, will give you horrible performance. That can at best
be an intermediate step, though I bet it's better to address both at
roughly the same time.

Jan