A regular SEV guest can be built in the hybrid IA32 and X64 configuration, so this will break existing SEV firmwares built in that manner. Only SEV-ES and SEV-SNP require the full X64 confguration. Th

Makes sense. Thanks, Tom

Ah, thanks. I just saw the comment above get_out_of_range_cpuid_entry() in arch/x86/kvm/cpuid.c where HyperV would get the 0x40000000-0x400000ff range and KVM would then get the 0x40000100-0x400001ff

s/the make/and make/ ? Just a nit, maybe SevClearPageEncMaskForGhcbPage? How about moving the xor as the first line of this routine and jumping to GetSevCBitMaskAbove31Exit if the first cmp is non-zer

Laszlo was trying to keep things sorted, so you should move this down to the end of the list. Ditto here, even though the list isn't truly sorted to begin with. The IsSevGuest() function checks for a

If SEV-ES is enabled, then we previously had already verified that the work area was present. Without that check now, it may not be. Just for safety, it is probably worth replacing the: if (MemEncrypt

DEBUG_ERROR? Should there be an "ASSERT_EFI_ERROR (Status)" after the DEBUG call? Thanks, Tom

s/STAT/STATE/ ? Need to put the function parameters in the comment here. Just a nit, but EncryptMask is a bit confusing because is sounds like the encryption mask used by SEV, but it's really the page

I don't think KvmDetectSevLiveMigrationFeature() should be in OvmfPkg/Include/Library/MemEncryptSevLib.h since it isn't called except as a helper by InternalDetectSevLiveMigrationFeature(). You should

My only comment is the AmdSev.asm file header should be updated. The file function needs to be changed and there should only be a single copyright statement for AMD from 2017 to now 2021. Thanks, Tom

I believe PcdOvmfSecGhcbBackupBase can be cleared early. For SEV-ES, it isn't shared with the hypervisor, so clearing it before activating the pagetables can be done (it will be treated as encrypted b

Is the memory area guaranteed to be zeroed for legacy guests? Hopefully, this won't trip up a non-TDX guest with a false match (highly unlikely, though). If you clear ebx here... ... you can remove th

I believe the convention is that this line be in the individual patch commit messages just like this (i.e. with the BZ: tag and the first line), not as a Ref: tag at the end of the commit message. I'l

Reviewed-by: Tom Lendacky <thomas.lendacky@...>

A comment about the use of INT32 in the for loop to protect against a large entry length value would be useful. I don't think it's worth another version, but if you have to make any updates it would b

Reviewed-by: Tom Lendacky <thomas.lendacky@...>

Reviewed-by: Tom Lendacky <thomas.lendacky@...>

Reviewed-by: Tom Lendacky <thomas.lendacky@...>

Reviewed-by: Tom Lendacky <thomas.lendacky@...>

I guess that it should probably be BlobVerifierLibSevHashes just for consistency, but I'm not sure whether there's a convention for BASE_NAME. Thanks, Tom