On 4/11/22 11:27, Dave Hansen wrote:
On 4/11/22 08:55, Borislav Petkov wrote:
On Sun, Apr 10, 2022 at 11:41:57PM -0700, Dave Hansen wrote:
Let's just call out the possible (probable?) need for new ABI here.
Maybe it will cue folks who care to speak up.
Err, why would you teach the user to go poke at some arbitrary sysfs
nodes when the accepting code can simply issue a printk from time to
time
"Guest unnaccepted memory progress: XX%. This slows down operations at the moment."
I guess that's not a horrible place to start. It's also not *horribly*
different from how guests work today. If hosts lazily allocate RAM,
they'll see largely the same kind of behavior.
What ends up determining how much memory is pre-accepted versus being
done from the guest? Is that just a normal part of setting up a TDX
guest, like from the qemu cmdline? Or, is there some convention with
the virtual firmware?
With SNP, some memory will be accepted as part of the LAUNCH_UPDATE
sequences that the hypervisor performs, but that is not all of the guest
memory. Once the guest is started, the (initial implementation of) OVMF
SNP support will accept (PVALIDATE) all of the remaining guest memory.
When the kernel boots, there isn't any unaccepted memory.
Once support is available in the kernel for unaccepted memory, then OVMF
could be updated to only accept a limited amount of memory and pass the
information about the unaccepted memory to the kernel through the EFI
memory map.
The approaches would have to be measured to see which ends up being the
best one. The GHCB specification allows for lots of memory to be accepted
in a single VMGEXIT (world switch) vs performing a VMGEXIT for each 2MB of
memory being accepted.
Thanks,
Tom
