Re: [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

["Lendacky, Thomas" <thomas.lendacky@amd.com>]

On 4/13/23 01:05, Gerd Hoffmann wrote:
>    Hi,
> 
>>>> Specifying both OVMF_CODE.fd and OVMF_VARS.fd generates an ASSERT.
>>>
>>> Both as pflash I assume?  Which assert?
>>
>> Yes, both as pflash. I've never attempted to run an SEV guest using the
>> -bios option.
>>
>> The assert is:
>> ASSERT [PlatformPei] /root/kernels/ovmf-build-X64/OvmfPkg/Library/PlatformInitLib/Platform.c(930): ((BOOLEAN)(0==1))
> 
> Ok, so wrong encryption settings.
> 
>>>> Specifying just OVMF.fd boots successfully
>>>
>>> pflash or -bios or both?
>>
>> Just pflash.
> 
> /me looks surprised.  It should not make a difference whenever you use
> the separate OVMF_CODE.fd + OVMF_VARS.fd files or the combined OVMF.fd.
> 
> What are the exact qemu command lines for both cases?

For the OVMF_CODE.fd/OVMF_VARS.fd case:
   qemu-system-x86_64 -enable-kvm -cpu EPYC,host-phys-bits=true -smp 1
    -machine type=q35,confidential-guest-support=sev0,vmport=off -m 1G
    -object sev-guest,id=sev0,policy=0,cbitpos=51,reduced-phys-bits=1
    -drive if=pflash,format=raw,unit=0,file=/root/kernels/qemu-install/OVMF_CODE.fd,readonly=on
    -drive if=pflash,format=raw,unit=1,file=./fedora.fd
    -drive file=./fedora.img,if=none,id=disk0,format=raw
    -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true
    -device scsi-hd,drive=disk0
    -nographic -monitor pty -monitor unix:monitor,server,nowait
    -gdb tcp::1234 -qmp tcp::4444,server,wait=off

  In this case, only OVMF_CODE.fd will be encrypted.
  The fedora.fd (OVMF_VARS.fd) will be unencrypted.

For the OVMF.fd case:
   qemu-system-x86_64 -enable-kvm -cpu EPYC,host-phys-bits=true -smp 1
    -machine type=q35,confidential-guest-support=sev0,vmport=off -m 1G
    -object sev-guest,id=sev0,policy=0,cbitpos=51,reduced-phys-bits=1
    -drive if=pflash,format=raw,unit=0,file=/root/kernels/qemu-install/OVMF.fd,readonly=on
    -drive file=./fedora.img,if=none,id=disk0,format=raw
    -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true
    -device scsi-hd,drive=disk0
    -nographic -monitor pty -monitor unix:monitor,server,nowait
    -gdb tcp::1234 -qmp tcp::4444,server,wait=off

  In this case, OVMF.fd will be encrypted, which includes the now memory
  backed variable store.

> 
>> I believe none of the mappings are setup properly at this point. I
>> think just eliminating the call for an SEV guest is fine.
> 
> Can AmdSevInitialize() setup the mappings?

Is there a way to tell when OVMF.fd vs OVMF_VARS.fd/OVMF_CODE.fd is used?
The reason being that the variable store of OVMF.fd must be accessed
encrypted since the whole binary was used in the LAUNCH_UPDATE. But with
the split mode, only the OVMF_CODE.fd was encrypted in the LAUNCH_UPDATE,
so the variable store must be accessed unencrypted.

If we can make that determination, then I think we can setup the mappings.

Thanks,
Tom

> 
> take care,
>    Gerd
>