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

[Alexey Gladkov]

On Mon, Mar 10, 2025 at 11:28:46AM +0100, Joerg Roedel wrote:
> On Thu, Mar 06, 2025 at 11:37:28AM +0100, Alexey Gladkov (Intel) wrote:
> > I was thinking to suggest something like that
> > 
> > /sys/firmware/coco/tdx/...
> > /sys/firmware/coco/sev/...
> 
> So on a second thought I'd like to vote for the /sys/hypervisor/
> hierarchy. The `firmware` term is a bit amibious here, the TDX module
> can be seen as a kind of firmware for the guest OS, but realistically it
> is more like another hypervisor sitting between KVM and the guest.
> 
> Also the settings on the SEV side that need to be exposed (VMPL and
> SEV_STATUS) are CPU properties, but on the other side also set by some
> form of hypervisor (either KVM/QEMU, the SVSM, or some other paravisor
> in-between).
> 
> Overall /sys/hypervisor/ seems to be the best-fitting location for all
> this data. To avoid ambiguation I propose:
> 
> 	/sys/hypervisor/common/[coco/]tdx/
> 	/sys/hypervisor/common/[coco/]sev/

The /sys/hypervisor requires CONFIG_SYS_HYPERVISOR=y. Now, this parameter
is not required for the minimum TDX guest configuration.

As I can see right now [1] this directory is used exclusively by xen team.
It's part of their ABI stable. I'm not sure we can go in there.

/sys/hypervisor/compilation/compile_date
/sys/hypervisor/compilation/compiled_by
/sys/hypervisor/compilation/compiler
/sys/hypervisor/properties/capabilities
/sys/hypervisor/properties/changeset
/sys/hypervisor/properties/features
/sys/hypervisor/properties/pagesize
/sys/hypervisor/properties/virtual_start
/sys/hypervisor/type
/sys/hypervisor/uuid
/sys/hypervisor/version/extra
/sys/hypervisor/version/major
/sys/hypervisor/version/minor
/sys/hypervisor/start_flags/*
/sys/hypervisor/guest_type
/sys/hypervisor/pmu/pmu_mode
/sys/hypervisor/pmu/pmu_features
/sys/hypervisor/properties/buildid

[1] Documentation/ABI/stable/sysfs-hypervisor-xen

> Using `common` makes it clear that this directory does not point to some
> sort of Hypervisor, but to data common to all hypervisors. Using another
> `coco` subdirectory is not necessary in my view, but if people think it
> should exist I am fine with that.
> 
> Is this something we can agree on?
> 
> Regards,
> 
> 	Joerg

-- 
Rgrds, legion