[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8hYEsHvwUwlOold@suse.de>
Date: Wed, 5 Mar 2025 14:56:34 +0100
From: Joerg Roedel <jroedel@...e.de>
To: Borislav Petkov <bp@...en8.de>
Cc: Ingo Molnar <mingo@...nel.org>, Joerg Roedel <joro@...tes.org>,
x86@...nel.org, hpa@...or.com,
Tom Lendacky <thomas.lendacky@....com>,
Nikunj A Dadhania <nikunj@....com>, linux-kernel@...r.kernel.org,
Larry.Dewey@....com
Subject: Re: [PATCH] x86/sev: Make SEV_STATUS available via SYSFS
On Wed, Mar 05, 2025 at 12:50:35PM +0100, Borislav Petkov wrote:
> On Wed, Mar 05, 2025 at 12:42:41PM +0100, Ingo Molnar wrote:
> > So if the convenience of tooling is the argument, the raw feature mask
> > exposed is the best option overall.
>
> The convenience of tooling *and* user. I want both. I want to be able to boot
> a guest and see what features are enabled without needing a tool.
>
> And, at the same time, tools should be able to use the same interface.
>
> Exactly like we *and glibc* use /proc/cpuinfo today. Now think the same thing
> but for confidential guests.
So this question boils down to whether the parsing of the bits happens
in kernel- or user-space. Actually there is already parsing in
kernel-space to print the status bits into the kernel log:
SEV: Status: SEV SEV-ES SEV-SNP
... which is great for a quick glance without needing any tools. The
user-space tools which already exist have their own parsing of the bits
and for them it is much easier to consume the raw value of the
SEV_STATUS MSR. See my changes to snpguest:
https://github.com/virtee/snpguest/pull/88/files
Btw, what is the equivalent on the Intel TDX side for these feature
bits?
Regards,
--
Jörg Rödel
jroedel@...e.de
SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg
Germany
https://www.suse.com/
Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)
Powered by blists - more mailing lists