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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47939): https://edk2.groups.io/g/devel/message/47939 Mute This Topic: https://groups.io/mt/34201782/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
