>> Since I had the data structures available in PEI
>> phase for the tracking the page state hence made those available to
>> DXE to verify that we are called to invalidate the SYSTEM_RAM and not
>> MMIO. IMO, we should either extend the
>> MemEncryptSev{Set,Clear}PageEncMask() to pass either a new flag to
>> hint where its system RAM or non-RAM. Thoughts ?
> I think I'd prefer a new function in the lib class, one that's dedicated
> to clearing the C bit on MMIO without attempting invalidation. It's a
> special-case function, and the dedicated name helps with two things:
>
> - no need to mess with existing call sites except in AmdSevDxe,
> - the new function is easier to grep for.
>
> BTW, there would be at least one other approach for this, I think -- the
> PEI instance of the library could consult the HOB list, and the DXE
> instance of the library could consult the GCD memory space map, to
> decide whether the page being C-bit-flipped is MMIO or not. But that's a
> lot of complexity (and likely some performance hit too), when in fact we
> know at the call sites whether the area being encrypted/decrypted is
> MMIO or RAM.
Sound good to me, will introduce new function for the MMIO in v2.
> Note also that (IIUC) in AmdSevDxe, we only *decrypt*, so we only need
> *one* new function, "MemEncryptSevClearMmioPageEncMask" or similar.
>
> BTW, in the "MemEncryptSevLib.h" header, the documentation of the
> MemEncryptSev{Set,Clear}PageEncMask function declarations should be
> updated -- the leading comments should explain that, in case SEV-SNP is
> found active, then page (in)validation will occur too (as appropriate).
Noted.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74094): https://edk2.groups.io/g/devel/message/74094
Mute This Topic: https://groups.io/mt/81584576/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
