[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyuLf5evSQlZqG6w@google.com>
Date: Wed, 6 Nov 2024 07:30:07 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>
Cc: Kai Huang <kai.huang@...el.com>, Xiaoyao Li <xiaoyao.li@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"yuan.yao@...ux.intel.com" <yuan.yao@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rick P Edgecombe <rick.p.edgecombe@...el.com>, Isaku Yamahata <isaku.yamahata@...el.com>
Subject: Re: [PATCH v3 1/2] KVM: x86: Check hypercall's exit to userspace generically
On Wed, Nov 06, 2024, Binbin Wu wrote:
> On 11/6/2024 4:54 PM, Huang, Kai wrote:
> > On Wed, 2024-11-06 at 16:32 +0800, Binbin Wu wrote:
> > > > static void kvm_complete_hypercall_exit(struct kvm_vcpu *vcpu, int ret_reg,
> > > > unsigned long ret, bool op_64_bit)
> > > > {
> > > > if (!op_64_bit)
> > > > ret = (u32)ret;
> > > > kvm_register_write_raw(vcpu, ret_reg, ret);
> > > > ++vcpu->stat.hypercalls;
> > > > }
> > > If this is going to be the final version, it would be better to make it
> > > public, and export the symbol, so that TDX code can reuse it.
> > Does making it 'static inline' and moving to kvm_host.h work?
> It doesn't have a complete definition of struct kvm_vcpu in
> arch/x86/include/asm/kvm_host.h, and the code is dereferencing
> struct kvm_vcpu.
> Also, the definition of kvm_register_write_raw() is in
> arch/x86/kvm/kvm_cache_regs.h, which make it difficult to be called
> there.
A way around that would be to move the declarations from asm/kvm_host.h to x86.h,
and then kvm_complete_hypercall_exit() can be inlined (or not), without having to
deal with the kvm_host.h ordering issues.
IMO, KVM x86 would ideally put as much as possible in x86.h. The vast majority
of KVM x86's exports are intended only for the vendor modules. Declaring those
exports in kvm_host.h is effectively bleeding KVM internals to the broader kernel.
I'll go that route for the series, assuming it works as I intend :-)
Powered by blists - more mailing lists