Re: [PATCH 00/20] OvmfPkg: SEV: decrypt the initial SMRAM save state map for SMBASE relocation

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

On 3/2/18 5:53 AM, Laszlo Ersek wrote:
> On 03/02/18 02:16, Brijesh Singh wrote:
>>
>> On 3/1/18 6:03 PM, Laszlo Ersek wrote:
>>> I also tried to test the series with SEV guests (again with Brijesh's v2
>>> 2/2 patch applied on top). Unfortunately, I didn't get good results with
>>> or without SMM. Without SMM, the guest OS boots to a point, but then it
>>> gets stuck with the CPU spinning. With SMM, OVMF gets stuck in SMBASE
>>> relocation.
>> To boot the SEV guest with SMM support we need this KVM patch, without
>> this we will get either #UD or some undefined behavior.
>>
>> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?id=7607b7174405aec7441ff6c970833c463114040a
> Looks like a very recent commit. What tree (and at what commit) do you
> recommend that I build a new host kernel?

Yes this is very recent commit and it was developed during SMM work. For
host kernel we need at least 4.16.0-rc1 but since you are going to boot
the SMM enabled BIOS hence I recommend using latest kvm/master

https://git.kernel.org/pub/scm/virt/kvm/kvm.git/

>
>> It's strange that you are having trouble booting SEV guest without SMM
>> support. It's possible that we might have some mismatch kernel kvm +
>> qemu + ovmf patches.
> Wait, the details matter: I wrote "the guest OS boots to a point". There
> are no problems with the firmware, or the initial OS boot progress. The
> issue happens fairly later (but certainly before I reach a login prompt
> or similar). Maybe this is nothing new relative to last November; I
> don't remember.

Ah, my best guess is that userspace program is getting wrong time using
clock_gettime() and hence the bootscripts are waiting on some events
forever .. IIRC, I was getting boot hang sometime back in Oct or Nov and
debugging took me to the kvmclock support for SEV guest. I was doing
everything right in my patches for kvmclock except the first hunk of the
below patch. When kvmclock is available the clock_getttime() uses vdso
and since kvmclock page is shared between HV and Guest hence we needed
to ensure that userspace pgtable have proper C-bit when accessing this
memory range.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.16-rc3&id=819aeee065e5d1b417ecd633897427c89f3253ec

All the SEV guest got accepted in 4.15, hence for guest kernel you can
use Linux kernel >=4.15

>>> Until then, Brijesh, can you please test this series? Thank you!
>>
>> Sure, I will try the series tomorrow morning. thank you so much for the
>> cleanup and remaining SMM work.
> Thanks!
>
> Do you have (maybe updated) instructions for setting up the SEV host?
> What are the latest bits that are expected to work together?

AMDSEV page https://github.com/AMDESE/AMDSEV contains some instruction
and scripts to boot the SEV guest but its still using the older version
of kernel and qemu. Here is what you need to do:

For host kernel:
- use recent kvm/master
- make sure following kernel config is enabled
  CONFIG_KVM_AMD_SEV
  CONFIG_CRYPTO_DEV_SP_PSP
  CONFIG_AMD_MEM_ENCRYPT
  CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT

For guest kernel:
 - you can use host kernel or anything >=4.15
    make sure you have following config enabled in kernel:
      CONFIG_AMD_MEM_ENCRYPT

For qemu:
- v10 patches from this branch
https://github.com/codomania/qemu/tree/v10


> Thanks!
> Laszlo