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

[Laszlo Ersek <lersek@redhat.com>]

On 03/02/18 14:17, Brijesh Singh wrote:
> 
> 
> 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

Great, I'll work on updating all the bits and I'll report back.

Thanks!
Laszlo