On Thu, Feb 13, 2025 at 03:50:19PM -0600, Xing, Cedric wrote:

On 2/13/2025 10:58 AM, Dave Hansen wrote:

quoted

On 2/13/25 08:21, Xing, Cedric wrote:

quoted

On 2/12/2025 10:50 PM, Dave Hansen wrote:

quoted

On 2/12/25 18:23, Cedric Xing wrote:

quoted

NOTE: This patch series introduces the Measurement Register (MR) ABI,
and
is a continuation of the RFC series on the same topic [1].

Could you please explain how the benefits of this series are helpful to
end users?

This series exposes MRs as sysfs attributes, allowing end users to
access them effortlessly without needing to write any code. This
simplifies the process of debugging and diagnosing measurement-related
issues. Additionally, it makes the CC architecture more intuitive for
newcomers.

Wait a sec, so there's already ABI for manipulating these? This just
adds a parallel sysfs interface to the existing ABI?

No, this is new. There's no existing ABI for accessing measurement registers
from within a TVM (TEE VM). Currently, on TDX for example, reading TDX
measurement registers (MRs) must be done by getting a TD quote. And there's
no way to extend any RTMRs. Therefore, it would be much easier end users to

TD reports *are* available through the tdx_guest ioctl so there's overlap
with the suggested reportdata/report0 entries at least. Since configfs-tsm
provides the generic transport for TVM reports, the best option to make report0
available is through configfs-tsm reports.

The use case on MRCONFIGID mentioned later in this thread does not depend
on this series. It's easy for the user-space to interprete the full report
to find MRCONFIGID or any other register value (the same is true for HOSTDATA
on SNP).

The question here is whether there's any real benefit for the kernel to
expose the provider specific report details through sysfs or could we focus on
the RTMR extend capability only.

-- 
Regards, Mikko