On 6/15/22 10:19, Xiaoyao Li wrote:
On 6/15/2022 8:46 AM, Xu, Min M wrote:
I would like to add more engineers (Confidential Computing Reviewers in
EDK2 community and Intel's QEMU engineers) in this mail thread.
-----Original Message-----
From: Dionna Amalie Glaze <dionnagl...@google.com>
Sent: Wednesday, June 15, 2022 2:09 AM
To: qemu-devel@nongnu.org
Cc: Xu, Min M <min.m...@intel.com>; Lendacky, Thomas
<thomas.lenda...@amd.com>
Subject: New "IndustryStandard" fw_cfg?
Hi y'all, I'm Dionna. I work on Confidential VMs at Google Cloud. I've
been
keeping up with the TDX and SEV-SNP developments in OVMF and Linux,
and some in Qemu.
There's a new UEFI feature in v2.9 of the specification (March 2021) that
allows for memory ranges to be classified as "unaccepted", since both TDX
and SEV-SNP require that the guest VM accept any host-made changes to
page state. We should expect newer technologies on non-x86 architectures
to require memory acceptance as well. Operating systems are not
necessarily going to support this memory type, however.
This leads to a problem: how does the UEFI know that the OS it's going to
boot will support unaccepted memory?
Why does UEFI need to know it?
Per my understanding, Unaccepted Memory in UEFI is introduced for
confidential VMs, i.e., for Intel TDX and AMD SEV-SNP. The only reason
UEFI/OVMF reports "Unaccepted Memory" to OS, is a confidential VM is
desired. Thus, the (guset) OS has to be enlightened to know how to handle
unaccepted memory. And of course, the non-confidential enlightened OS,
e.g., old linux kernel, fails boot/hits issue if it doesn't support
unaccepted memory.
As of today, SNP guest support is part of current OVMF and Linux 5.19-rcX,
but support for unaccepted memory is not. The current OVMF SNP guest
support will accept all the guest memory and the Linux SNP guest support
will terminate the SNP guest if a page is accessed that has not been accepted.
Thanks,
Tom
