[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2e0e538e-99f0-4828-bdd3-fda7ad3794c3@intel.com>
Date: Wed, 29 Oct 2025 14:13:31 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Cc: "seanjc@...gle.com" <seanjc@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
 "kas@...nel.org" <kas@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
 "mingo@...hat.com" <mingo@...hat.com>,
 "tglx@...utronix.de" <tglx@...utronix.de>, "x86@...nel.org"
 <x86@...nel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "Li, Xiaoyao" <xiaoyao.li@...el.com>
Subject: Re: [PATCH 1/2] x86/virt/tdx: Remove __user annotation from kernel
 pointer
On 10/29/25 14:06, Edgecombe, Rick P wrote:
> For the KVM side of tdx, the commits are getting prefixed with "KVM: TDX: ", and
> "x86/virt/tdx" is being used arch/x86/virt/vmx/tdx/tdx.c. It's probably not too
> late to adopt the one true naming scheme. I don't have a strong preference
> except some consistency and that the maintainers agree :)
Yeah, I just picked one. I honestly don't care what we do in the end. I
was also probably just going to send these in the tip/x86/tdx branch
unless anyone screams, so I did it the tip-ish way.
>> There are two 'kvm_cpuid2' pointers involved here. There's an "input"
>> side: 'td_cpuid' which is a normal kernel pointer and an 'output'
>> side. The output here is userspace and there is an attempt at properly
>> annotating the variable with __user:
>>
>> 	struct kvm_cpuid2 __user *output, *td_cpuid;
>>
>> But, alas, this is wrong. The __user in the definition applies to both
>> 'output' and 'td_cpuid'.
>>
>> Fix it up by completely separating the two definitions so that it is
>> obviously correct without even having to know what the C syntax rules
>> even are.
> 
> If we want it:
> Fixes: 488808e682e7 ("KVM: x86: Introduce KVM_TDX_GET_CPUID")
Thanks for that. I might dump in in, but sometimes folks can get all hot
and bothered about getting true fixes upstream fast. I was planning to
go go the slow next-merge-window route with these.
Powered by blists - more mailing lists
 
