Re: [PATCH] x86/sev: Make SEV_STATUS available via SYSFS

[Joerg Roedel <joro@8bytes.org>]

On Mon, Mar 10, 2025 at 12:02:02PM +0100, Borislav Petkov wrote:
> ... or you can drop the "common" thing and use only the "coco":
>
> /sys/hypervisor/coco

Common is less likely to be mistaken for a hypervisor name than coco.
But if there is agreement on that naming I can live with that.

> and then you kinda denote that while it is the hypervisor hierarchy, it is
> related to confidential computing so it could be consumed by guests too.
> 
> But I still don't see why we can't simply do
> 
> /sys/guest
> 
> It is just another sysfs node. Or is there a particular reason to stick to
> /sys/hypervisor?

/sys/hypervisor/ has the best-fitting name imho. Unfortunately it is
taken in a very non-generic way by Xen, with no clean way to make it
more generic without breaking Xen or increase the mess. So /sys/guest
might be a viable alternative. /sys/guest/xen/ could then link to
/sys/hypervisor/.

> And putting it in sysfs still doesn't solve the human-readable aspect: dumping
> a raw SEV_STATUS might as well be simply reading the MSR and if someone wants
> to read it, someone would need to go count bits. Imagine the following
> scenario: a user reports a bug, you say, ok, send me
> 
> /sys/hypervisor/coco/sev/sev_status
> 
> you get it and you dump it through your script or start looking at the bits.
> Yeah, we all have scripts for that but it ain't too user-friendly...

Right, it is not really a good human-readable interface. On the other
side SYSFS was always an interface targeted more towards tooling than
humans, therefore the one-datum-per-file rule. The use-case I want to
target with this patch is also tooling-related.

We can add a human-readable version of the coco-features somewhere else,
if wanted.  You already suggested /proc/cpuinfo, which in itself is
designed for direct human consumption.

Regards,

	Joerg