From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D64DE21E082B8 for ; Mon, 5 Mar 2018 13:00:37 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D99BEAE91; Mon, 5 Mar 2018 21:06:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-64.rdu2.redhat.com [10.10.120.64]) by smtp.corp.redhat.com (Postfix) with ESMTP id ECF79AFD74; Mon, 5 Mar 2018 21:06:47 +0000 (UTC) To: Brijesh Singh , edk2-devel-01 Cc: Ard Biesheuvel , Jordan Justen References: <20180302000408.14201-1-lersek@redhat.com> <2d6e37a5-fdfa-330d-d7ef-51e0350afdad@amd.com> <6be3c2e4-0269-7743-d14d-4cf1f2935342@redhat.com> <45c6adcc-57a1-c7c4-3474-b33b7323ea17@amd.com> <43e0c837-3f1d-691b-f701-10c2777b721a@amd.com> From: Laszlo Ersek Message-ID: Date: Mon, 5 Mar 2018 22:06:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <43e0c837-3f1d-691b-f701-10c2777b721a@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 05 Mar 2018 21:06:49 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 05 Mar 2018 21:06:49 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' X-Content-Filtered-By: Mailman/MimeDel 2.1.23 Subject: Re: [PATCH 00/20] OvmfPkg: SEV: decrypt the initial SMRAM save state map for SMBASE relocation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 21:00:38 -0000 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: - , - .) 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 ^^^^^^^^^^^ documented at . 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