On 07/12/2023 18:21, Jeremi Piotrowski wrote: > On 07/12/2023 13:58, Huang, Kai wrote: >>> >>> That's how it currently works - all the enlightenments are in >>> hypervisor/paravisor >>> specific code in arch/x86/hyperv and drivers/hv and the vm is not marked >>> with >>> X86_FEATURE_TDX_GUEST. >> >> And I believe there's a reason that the VM is not marked as TDX guest. > Yes, as Elena said: > """ > OK, so in your case it is a decision of L1 VMM not to set the > TDX_CPUID_LEAF_ID > to reflect that it is a tdx guest and it is on purpose because you want to > drop into a special tdx guest, i.e. partitioned guest. > """ > TDX does not provide a means to let the partitioned guest know that it needs > to > cooperate with the paravisor (e.g. because TDVMCALLs are routed to L0) so > this is > exposed in a paravisor specific way (cpuids in patch 1). > >> >>> >>> But without X86_FEATURE_TDX_GUEST userspace has no unified way to discover >>> that an >>> environment is protected by TDX and also the VM gets classified as "AMD >>> SEV" in dmesg. >>> This is due to CC_ATTR_GUEST_MEM_ENCRYPT being set but >>> X86_FEATURE_TDX_GUEST not. >> >> Can you provide more information about what does _userspace_ do here? > > I gave one usecase in a different email. A workload scheduler like Kubernetes > might want to > place a workload in a confidential environment, and needs a way to determine > that a VM is > TDX protected (or SNP protected) to make that placement decision. > >> >> What's the difference if it sees a TDX guest or a normal non-coco guest in >> /proc/cpuinfo? >> >> Looks the whole purpose of this series is to make userspace happy by >> advertising >> TDX guest to /proc/cpuinfo. But if we do that we will have bad side-effect >> in >> the kernel so that we need to do things in your patch 2/3. >> > > Yes, exactly. It's unifying the two approaches so that userspace doesn't have > to > care. > >> That doesn't seem very convincing. > > Why not? > The whole point of the kernel is to provide a unified interface to userspace > and > abstract away these small differences. Yes it requires some kernel code to do, > thats not a reason to force every userspace to implement its own logic. This > is > what the flags in /proc/cpuinfo are for. >
So I feel like we're finally getting to the gist of the disagreements in this thread. Here's something I think we should all agree on (both a) and b)). X86_FEATURE_TDX_GUEST: a) is visible to userspace and not just some kernel-only construct b) means "this is a guest running in an Intel TDX Trust Domain, and said guest is aware of TDX" a) is obvious but I think needs restating. b) is what userspace expects, and excludes legacy (/unmodified) guests running in a TD. That's a reasonable definition. For kernel only checks we can rely on platform-specific CC_ATTRS checked through intel_cc_platform_has. @Borislav: does that sound reasonable to you? @Kai, @Kirill, @Elena: can I get you to agree with this compromise, for userspace' sake? Jeremi
