On Thu, 19 Sep 2019 19:02:07 +0200 "Laszlo Ersek" <ler...@redhat.com> wrote:
> Hi Igor, > > (+Brijesh) > > long-ish pondering ahead, with a question at the end. [...] > Finally: can you please remind me why we lock down 128KB (32 pages) at > 0x3_0000, and not just half of that? What do we need the range at > [0x4_0000..0x4_FFFF] for? If I recall correctly, CPU consumes 64K of save/restore area. The rest 64K are temporary RAM for using in SMI relocation handler, if it's possible to get away without it then we can drop it and lock only 64K required for CPU state. It won't help with SEV conflict though as it's in the first 64K. 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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47710): https://edk2.groups.io/g/devel/message/47710 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] -=-=-=-=-=-=-=-=-=-=-=-
