Paolo Bonzini <pbonzini@...>
On 20/09/19 11:28, Laszlo Ersek wrote:
Another possibility would be to alias the 0xA0000..0xBFFFF SMRAM toOn QEMU side, we can drop black-hole approach and allocateI prefer the black-hole approach, introduced in your current patch
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.
I've started work on the counterpart OVMF patches; I'll report back.