Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address


Paolo Bonzini <pbonzini@...>
 

On 20/09/19 11:28, Laszlo Ersek wrote:
On QEMU side, we can drop black-hole approach and allocate
dedicated SMRAM region, which explicitly gets mapped into
RAM address space and after SMI hanlder initialization, gets
unmapped (locked). So that SMRAM would be accessible only
from SMM context. That way RAM at 0x30000 could be used as
normal when SMRAM is unmapped.
I prefer the black-hole approach, introduced in your current patch
series, if it can work. Way less opportunity for confusion.
Another possibility would be to alias the 0xA0000..0xBFFFF SMRAM to
0x30000..0x4FFFF (only when in SMM).

I'm not super enthusiastic about adding this kind of QEMU-only feature.
The alternative would be to implement VT-d range locking through the
intel-iommu device's PCI configuration space (which includes _adding_
the configuration space, i.e. making the IOMMU a PCI device in the first
place, and the support to the firmware for configuring the VT-d BAR at
0xfed90000). This would be the right way to do it, but it would entail
a lot of work throughout the stack. :( So I guess some variant of this
would be okay, as long as it's peppered with "this is not how real
hardware does it" comments in both QEMU and EDK2.

Thanks,

Paolo

I've started work on the counterpart OVMF patches; I'll report back.

Join rfc@edk2.groups.io to automatically receive all group messages.