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

[Laszlo Ersek]

On 09/20/19 10:28, Igor Mammedov wrote:
> On Thu, 19 Sep 2019 19:02:07 +0200
> "Laszlo Ersek" <lersek at 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.

OK. Let's go with 128KB for now. Shrinking the area is always easier
than growing it.

> 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.

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

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47712): https://edk2.groups.io/g/devel/message/47712
Mute This Topic: https://groups.io/mt/34201782/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-