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. > Is there any other way that userspace can > utilize, e.g., any HV hypervisor/paravisor specific attributes that are exposed > to userspace? > There are no HV hyper-/para-visor attributes exposed to userspace directly, but userspace can poke at the same cpuid bits as in patch 1 to make this determination. Not great for confidential computing adoption.
