On 11/9/23 08:35, Jeremi Piotrowski wrote:
> On 09/11/2023 17:25, Dave Hansen wrote:
>> On 11/9/23 08:14, Jeremi Piotrowski wrote:
>> ...
>>> pr_info("Memory Encryption Features active:");
>>>
>>> - if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
>>> + if (cc_vendor == CC_VENDOR_INTEL) {
>>> pr_cont(" Intel TDX\n");
>>> return;
>>> }
>>
>> Why aren't these guests setting X86_FEATURE_TDX_GUEST?
>
> They could if we can confirm that the code gated behind
> cpu_feature_enabled(X86_FEATURE_TDX_GUEST) is correct when running with TD partitioning.
Let me elaborate a bit on my question.
X86_FEATURE_TDX_GUEST is set based on some specific gunk that shows up
in CPUID in TDX guests. I *believe* it's in one of the CPUID leaves
that the VMM has no control over.
So, first, what in practice is keeping tdx_early_init() from running on
these "TD partitioning" systems? Because it's either not running, or
I'm misreading the code horribly.
> It still makes sense to have these prints based on the cc_xxx abstractions.
I'm not sure I'm following.
For instance, let's say that someone came up with a nutty reason to do
MKTME in Linux. We'd need a host-side contraption that sets
CC_ATTR_MEM_ENCRYPT and so forth. It would also, obviously, set
cc_vendor=CC_VENDOR_INTEL just like host-side SME sets
cc_vendor=CC_VENDOR_AMD.
Then we'd have to go back and disentangle all the places where we
assumed CC_VENDOR_INTEL==TDX.
That, combined with this patch's apparent disregard for why
X86_FEATURE_TDX_GUEST isn't getting set makes me think that the big
picture was not considered here and this patch represents the quickest
hack to get the right spew out to dmesg that is desired.
