On Mon, Feb 12, 2024 at 12:57 PM James Bottomley wrote:
>
> On Mon, 2024-02-12 at 12:16 -0800, Dionna Amalie Glaze wrote:
> > This is not a patch but it felt inappropriate to derail a recent
> > patch that's just refactoring the kernel-hashes object_class_property
>
This is not a patch but it felt inappropriate to derail a recent patch
that's just refactoring the kernel-hashes object_class_property
definition. Apologies if this has been discussed before, as I'm not
particularly active here.
Regarding kernel-hashes, how is that load-time information passed
alo
> > The most recent patches I recall for SEV-SNP introduced a new
> > 'sev-snp-guest' object instead of overloading the existing
> > 'sev-guest' object:
> >
> >https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg04757.html
> >
>
> Correct, the SNP support for Qemu is only RFC at this point
I think the option should be boolean since it doesn't look like we're
going to need to tune the number very much.
It all boils down to "does the OS affirmatively support unaccepted
memory?" as in, we have no way to negotiate it, but force unaccepted
memory on.
Ovmf can interpret the existence of an
> > > For Qemu, the main code I see for adding config is here, but I'm not sure
> > > what y'all's preferred external configuration method is to get a value
> > > from an
>
> Ideally no external configuration, although I suspect we need something
> at least temporarily.
Yes, whereas TDX can assum
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", sin
