Re: [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support

["Brijesh Singh" <brijesh.singh@amd.com>]

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