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

[Laszlo Ersek <lersek@redhat.com>]

On 03/05/18 15:44, Brijesh Singh wrote:
> On 03/05/2018 08:00 AM, Laszlo Ersek wrote:

>> QEMU exits with the following error for me:
>>
>> 2018-03-05T13:40:12.478835Z qemu-system-x86_64: sev_ram_block_added:
>> failed to register region (0x7f3df3e00000+0x200000000)
>> 2018-03-05T13:40:12.489183Z qemu-system-x86_64: sev_ram_block_added:
>> failed to register region (0x7f3ffaa00000+0x37c000)
>> 2018-03-05T13:40:12.497580Z qemu-system-x86_64: sev_ram_block_added:
>> failed to register region (0x7f3ffa800000+0x20000)
>> 2018-03-05T13:40:12.504485Z qemu-system-x86_64:
>> sev_launch_update_data: LAUNCH_UPDATE ret=-12 fw_error=0 ''
>> 2018-03-05T13:40:12.504493Z qemu-system-x86_64: failed to encrypt
>> pflash rom
>>
>> Here's my full QEMU command line (started by libvirt) -- this command
>> line does not restrict pflash access to guest code that runs in SMM,
>> and correspondingly, the OVMF build lacks SMM_REQUIRE:
>>
> 
> Are you launching guest as a normal users or root ? If you are launching
> guest as normal user then please make sure you have increased the 'max
> locked memory' limit. The register region function will try to pin the
> memory, while doing so we check the limit and if requested size is
> greater than ulimit then we fail.
> 
> 
> # ulimit -a
> core file size          (blocks, -c) unlimited
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 966418
> max locked memory       (kbytes, -l) 10240000
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 0
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 966418
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited

Good catch! Libvirtd starts the QEMU process with UID=qemu, but the
restriction doesn't come from there.

Instead, it seems like the systemd default for "max locked memory" is
64KB on RHEL-7 anyway. I raised it by setting

  DefaultLimitMEMLOCK=infinity

in "/etc/systemd/system.conf".

(The documentation is at:
- <https://www.freedesktop.org/software/systemd/man/systemd.exec.html>,
-
<https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html>.)

Following your other email, I've now also added
"iommu_platform=on,ats=on" to virtio-net-pci, not just virtio-scsi-pci.

This got a lot farther: the TianoCore splash screen was dispalyed, but
then it got stuck.

Looking more at the libvirt-generated command line, I figured maybe
"vhost" should be disabled for virtio-net (so that the device
implementation would run from QEMU userspace, not in the host kernel).
Thus, ultimately I added

    <interface type='network'>
      <driver name='qemu' iommu='on' ats='on'/>
              ^^^^^^^^^^^
    </interface>

documented at
<https://libvirt.org/formatdomain.html#elementsDriverBackendOptions>.

With these settings, the guest boots & works fine for me! I tested the
SEV guest with 4 VCPUs, both with and without SMM. (I used the same
kernel in the guest as on the host -- you wrote CONFIG_AMD_MEM_ENCRYPT
for the guest, and the host requirements imply that.)

I'm attaching the full domain XML for reference.

Thanks!
Laszlo