Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Miguel Ojeda]

On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> 6.18-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Xianglai Li <lixianglai@loongson.cn>
>
> commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
>
> If we directly compile the switch.S file into the kernel, the address of
> the kvm_exc_entry function will definitely be within the DMW memory area.
> Therefore, we will no longer need to perform a copy relocation of the
> kvm_exc_entry.
>
> So this patch compiles switch.S directly into the kernel, and then remove
> the copy relocation execution logic for the kvm_exc_entry function.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

For loongarch64, I am seeing a bunch of errors like:

    arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
    EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
    ^

`EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
modules where obvious/possible")?

Cc'ing a few folks...

Thanks!

Cheers,
Miguel

Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Sean Christopherson]

On Tue, May 12, 2026, Miguel Ojeda wrote:
> On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > 6.18-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Xianglai Li <lixianglai@loongson.cn>
> >
> > commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
> >
> > If we directly compile the switch.S file into the kernel, the address of
> > the kvm_exc_entry function will definitely be within the DMW memory area.
> > Therefore, we will no longer need to perform a copy relocation of the
> > kvm_exc_entry.
> >
> > So this patch compiles switch.S directly into the kernel, and then remove
> > the copy relocation execution logic for the kvm_exc_entry function.
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> For loongarch64, I am seeing a bunch of errors like:
> 
>     arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
>     EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
>     ^
> 
> `EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
> of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
> modules where obvious/possible")?

Either that or just convert EXPORT_SYMBOL_FOR_KVM() => EXPORT_SYMBOL_GPL().  If
that's somewhat scriptable for ongoing LTS backports, that's probably the best
option.  EXPORT_SYMBOL_FOR_KVM() will only work for 6.18, and the list of backports
needed to get EXPORT_SYMBOL_FOR_MODULES() working on older LTS kernels looks to
be non-trivial

If we do end up backporting EXPORT_SYMBOL_FOR_KVM() and others, we might as well
also grab a subset of 01122b89361e ("perf: Use EXPORT_SYMBOL_FOR_KVM() for the
mediated APIs") to ensure a kvm_types.h stub is present on all archs.  That way
EXPORT_SYMBOL_FOR_KVM() usage in arch-neutral code will also work.

diff --git include/asm-generic/Kbuild include/asm-generic/Kbuild
index 295c94a3ccc1..9aff61e7b8f2 100644
--- include/asm-generic/Kbuild
+++ include/asm-generic/Kbuild
@@ -32,6 +32,7 @@ mandatory-y += irq_work.h
 mandatory-y += kdebug.h
 mandatory-y += kmap_size.h
 mandatory-y += kprobes.h
+mandatory-y += kvm_types.h
 mandatory-y += linkage.h
 mandatory-y += local.h
 mandatory-y += local64.h

Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Huacai Chen]

On Wed, May 13, 2026 at 5:53 AM Sean Christopherson <seanjc@google.com> wrote:
>
> On Tue, May 12, 2026, Miguel Ojeda wrote:
> > On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > >
> > > 6.18-stable review patch.  If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Xianglai Li <lixianglai@loongson.cn>
> > >
> > > commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
> > >
> > > If we directly compile the switch.S file into the kernel, the address of
> > > the kvm_exc_entry function will definitely be within the DMW memory area.
> > > Therefore, we will no longer need to perform a copy relocation of the
> > > kvm_exc_entry.
> > >
> > > So this patch compiles switch.S directly into the kernel, and then remove
> > > the copy relocation execution logic for the kvm_exc_entry function.
> > >
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > For loongarch64, I am seeing a bunch of errors like:
> >
> >     arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
> >     EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
> >     ^
> >
> > `EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
> > of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
> > modules where obvious/possible")?
>
> Either that or just convert EXPORT_SYMBOL_FOR_KVM() => EXPORT_SYMBOL_GPL().  If
> that's somewhat scriptable for ongoing LTS backports, that's probably the best
> option.  EXPORT_SYMBOL_FOR_KVM() will only work for 6.18, and the list of backports
> needed to get EXPORT_SYMBOL_FOR_MODULES() working on older LTS kernels looks to
> be non-trivial
>
> If we do end up backporting EXPORT_SYMBOL_FOR_KVM() and others, we might as well
> also grab a subset of 01122b89361e ("perf: Use EXPORT_SYMBOL_FOR_KVM() for the
> mediated APIs") to ensure a kvm_types.h stub is present on all archs.  That way
> EXPORT_SYMBOL_FOR_KVM() usage in arch-neutral code will also work.
I have already noticed Greg about this before.

And I think the best solution is to use EXPORT_SYMBOL_GPL().

If Greg doesn't want to adjust manually, please drop this patch and I
will send one.



Huacai

>
> diff --git include/asm-generic/Kbuild include/asm-generic/Kbuild
> index 295c94a3ccc1..9aff61e7b8f2 100644
> --- include/asm-generic/Kbuild
> +++ include/asm-generic/Kbuild
> @@ -32,6 +32,7 @@ mandatory-y += irq_work.h
>  mandatory-y += kdebug.h
>  mandatory-y += kmap_size.h
>  mandatory-y += kprobes.h
> +mandatory-y += kvm_types.h
>  mandatory-y += linkage.h
>  mandatory-y += local.h
>  mandatory-y += local64.h
>
>

Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Greg KH]

On Wed, May 13, 2026 at 11:06:20AM +0800, Huacai Chen wrote:
> On Wed, May 13, 2026 at 5:53 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Tue, May 12, 2026, Miguel Ojeda wrote:
> > > On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > 6.18-stable review patch.  If anyone has any objections, please let me know.
> > > >
> > > > ------------------
> > > >
> > > > From: Xianglai Li <lixianglai@loongson.cn>
> > > >
> > > > commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
> > > >
> > > > If we directly compile the switch.S file into the kernel, the address of
> > > > the kvm_exc_entry function will definitely be within the DMW memory area.
> > > > Therefore, we will no longer need to perform a copy relocation of the
> > > > kvm_exc_entry.
> > > >
> > > > So this patch compiles switch.S directly into the kernel, and then remove
> > > > the copy relocation execution logic for the kvm_exc_entry function.
> > > >
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > For loongarch64, I am seeing a bunch of errors like:
> > >
> > >     arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
> > >     EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
> > >     ^
> > >
> > > `EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
> > > of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
> > > modules where obvious/possible")?
> >
> > Either that or just convert EXPORT_SYMBOL_FOR_KVM() => EXPORT_SYMBOL_GPL().  If
> > that's somewhat scriptable for ongoing LTS backports, that's probably the best
> > option.  EXPORT_SYMBOL_FOR_KVM() will only work for 6.18, and the list of backports
> > needed to get EXPORT_SYMBOL_FOR_MODULES() working on older LTS kernels looks to
> > be non-trivial
> >
> > If we do end up backporting EXPORT_SYMBOL_FOR_KVM() and others, we might as well
> > also grab a subset of 01122b89361e ("perf: Use EXPORT_SYMBOL_FOR_KVM() for the
> > mediated APIs") to ensure a kvm_types.h stub is present on all archs.  That way
> > EXPORT_SYMBOL_FOR_KVM() usage in arch-neutral code will also work.
> I have already noticed Greg about this before.

You did?  Where?

> And I think the best solution is to use EXPORT_SYMBOL_GPL().
> 
> If Greg doesn't want to adjust manually, please drop this patch and I
> will send one.

I'll go drop this one from the queue.

thanks,

greg k-h

Re: Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Wentao Guan]

Hello,

> On Wed, May 13, 2026 at 11:06:20AM +0800, Huacai Chen wrote:
> > On Wed, May 13, 2026 at 5:53 AM Sean Christopherson <seanjc@google.com> wrote:
> > >
> > > On Tue, May 12, 2026, Miguel Ojeda wrote:
> > > > On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > 6.18-stable review patch.  If anyone has any objections, please let me know.
> > > > >
> > > > > ------------------
> > > > >
> > > > > From: Xianglai Li <lixianglai@loongson.cn>
> > > > >
> > > > > commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
> > > > >
> > > > > If we directly compile the switch.S file into the kernel, the address of
> > > > > the kvm_exc_entry function will definitely be within the DMW memory area.
> > > > > Therefore, we will no longer need to perform a copy relocation of the
> > > > > kvm_exc_entry.
> > > > >
> > > > > So this patch compiles switch.S directly into the kernel, and then remove
> > > > > the copy relocation execution logic for the kvm_exc_entry function.
> > > > >
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >
> > > > For loongarch64, I am seeing a bunch of errors like:
> > > >
> > > >     arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
> > > >     EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
> > > >     ^
> > > >
> > > > `EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
> > > > of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
> > > > modules where obvious/possible")?
> > >
> > > Either that or just convert EXPORT_SYMBOL_FOR_KVM() => EXPORT_SYMBOL_GPL().  If
> > > that's somewhat scriptable for ongoing LTS backports, that's probably the best
> > > option.  EXPORT_SYMBOL_FOR_KVM() will only work for 6.18, and the list of backports
> > > needed to get EXPORT_SYMBOL_FOR_MODULES() working on older LTS kernels looks to
> > > be non-trivial
> > >
> > > If we do end up backporting EXPORT_SYMBOL_FOR_KVM() and others, we might as well
> > > also grab a subset of 01122b89361e ("perf: Use EXPORT_SYMBOL_FOR_KVM() for the
> > > mediated APIs") to ensure a kvm_types.h stub is present on all archs.  That way
> > > EXPORT_SYMBOL_FOR_KVM() usage in arch-neutral code will also work.
> > I have already noticed Greg about this before.
> 
> You did?  Where?

Small problem, I guess where he means is 'stable-commits@vger.kernel.org', is a
not public maillist? I want to find it in 'lore.kernel.org' but not found... 

BRs
Wentao Guan

Re: Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Greg KH]

On Wed, May 13, 2026 at 07:58:10PM +0800, Wentao Guan wrote:
> Hello,
> 
> > On Wed, May 13, 2026 at 11:06:20AM +0800, Huacai Chen wrote:
> > > On Wed, May 13, 2026 at 5:53 AM Sean Christopherson <seanjc@google.com> wrote:
> > > >
> > > > On Tue, May 12, 2026, Miguel Ojeda wrote:
> > > > > On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > 6.18-stable review patch.  If anyone has any objections, please let me know.
> > > > > >
> > > > > > ------------------
> > > > > >
> > > > > > From: Xianglai Li <lixianglai@loongson.cn>
> > > > > >
> > > > > > commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
> > > > > >
> > > > > > If we directly compile the switch.S file into the kernel, the address of
> > > > > > the kvm_exc_entry function will definitely be within the DMW memory area.
> > > > > > Therefore, we will no longer need to perform a copy relocation of the
> > > > > > kvm_exc_entry.
> > > > > >
> > > > > > So this patch compiles switch.S directly into the kernel, and then remove
> > > > > > the copy relocation execution logic for the kvm_exc_entry function.
> > > > > >
> > > > > > Cc: stable@vger.kernel.org
> > > > > > Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> > > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > >
> > > > > For loongarch64, I am seeing a bunch of errors like:
> > > > >
> > > > >     arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
> > > > >     EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
> > > > >     ^
> > > > >
> > > > > `EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
> > > > > of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
> > > > > modules where obvious/possible")?
> > > >
> > > > Either that or just convert EXPORT_SYMBOL_FOR_KVM() => EXPORT_SYMBOL_GPL().  If
> > > > that's somewhat scriptable for ongoing LTS backports, that's probably the best
> > > > option.  EXPORT_SYMBOL_FOR_KVM() will only work for 6.18, and the list of backports
> > > > needed to get EXPORT_SYMBOL_FOR_MODULES() working on older LTS kernels looks to
> > > > be non-trivial
> > > >
> > > > If we do end up backporting EXPORT_SYMBOL_FOR_KVM() and others, we might as well
> > > > also grab a subset of 01122b89361e ("perf: Use EXPORT_SYMBOL_FOR_KVM() for the
> > > > mediated APIs") to ensure a kvm_types.h stub is present on all archs.  That way
> > > > EXPORT_SYMBOL_FOR_KVM() usage in arch-neutral code will also work.
> > > I have already noticed Greg about this before.
> > 
> > You did?  Where?
> 
> Small problem, I guess where he means is 'stable-commits@vger.kernel.org', is a
> not public maillist? I want to find it in 'lore.kernel.org' but not found... 

It's a public list, anyone can sign up for it.  Don't know if lore
archives it, but I'm sure that someone does...

thanks,

greg k-h

Re: Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Wentao Guan]

> On Wed, May 13, 2026 at 07:58:10PM +0800, Wentao Guan wrote:
> > Hello,
> > 
> > > On Wed, May 13, 2026 at 11:06:20AM +0800, Huacai Chen wrote:
> > > > On Wed, May 13, 2026 at 5:53 AM Sean Christopherson <seanjc@google.com> wrote:
> > > > >
> > > > > On Tue, May 12, 2026, Miguel Ojeda wrote:
> > > > > > On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > 6.18-stable review patch.  If anyone has any objections, please let me know.
> > > > > > >
> > > > > > > ------------------
> > > > > > >
> > > > > > > From: Xianglai Li <lixianglai@loongson.cn>
> > > > > > >
> > > > > > > commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
> > > > > > >
> > > > > > > If we directly compile the switch.S file into the kernel, the address of
> > > > > > > the kvm_exc_entry function will definitely be within the DMW memory area.
> > > > > > > Therefore, we will no longer need to perform a copy relocation of the
> > > > > > > kvm_exc_entry.
> > > > > > >
> > > > > > > So this patch compiles switch.S directly into the kernel, and then remove
> > > > > > > the copy relocation execution logic for the kvm_exc_entry function.
> > > > > > >
> > > > > > > Cc: stable@vger.kernel.org
> > > > > > > Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> > > > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > >
> > > > > > For loongarch64, I am seeing a bunch of errors like:
> > > > > >
> > > > > >     arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
> > > > > >     EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
> > > > > >     ^
> > > > > >
> > > > > > `EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
> > > > > > of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
> > > > > > modules where obvious/possible")?
> > > > >
> > > > > Either that or just convert EXPORT_SYMBOL_FOR_KVM() => EXPORT_SYMBOL_GPL().  If
> > > > > that's somewhat scriptable for ongoing LTS backports, that's probably the best
> > > > > option.  EXPORT_SYMBOL_FOR_KVM() will only work for 6.18, and the list of backports
> > > > > needed to get EXPORT_SYMBOL_FOR_MODULES() working on older LTS kernels looks to
> > > > > be non-trivial
> > > > >
> > > > > If we do end up backporting EXPORT_SYMBOL_FOR_KVM() and others, we might as well
> > > > > also grab a subset of 01122b89361e ("perf: Use EXPORT_SYMBOL_FOR_KVM() for the
> > > > > mediated APIs") to ensure a kvm_types.h stub is present on all archs.  That way
> > > > > EXPORT_SYMBOL_FOR_KVM() usage in arch-neutral code will also work.
> > > > I have already noticed Greg about this before.
> > > 
> > > You did?  Where?
> > 
> > Small problem, I guess where he means is 'stable-commits@vger.kernel.org', is a
> > not public maillist? I want to find it in 'lore.kernel.org' but not found... 
> 
> It's a public list, anyone can sign up for it.  Don't know if lore
> archives it, but I'm sure that someone does...

Thanks for your reply. It is interesting that now i found them in
https://marc.info/?l=linux-stable-commits&m=177859589029820&w=2,
and https://marc.info/?l=linux-stable-commits&m=177859840800303

BRs
Wentao Guan

Re: Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel

[Greg KH]

On Wed, May 13, 2026 at 08:08:08PM +0800, Wentao Guan wrote:
> > On Wed, May 13, 2026 at 07:58:10PM +0800, Wentao Guan wrote:
> > > Hello,
> > > 
> > > > On Wed, May 13, 2026 at 11:06:20AM +0800, Huacai Chen wrote:
> > > > > On Wed, May 13, 2026 at 5:53 AM Sean Christopherson <seanjc@google.com> wrote:
> > > > > >
> > > > > > On Tue, May 12, 2026, Miguel Ojeda wrote:
> > > > > > > On Tue, 12 May 2026 19:38:12 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > > > > >
> > > > > > > > 6.18-stable review patch.  If anyone has any objections, please let me know.
> > > > > > > >
> > > > > > > > ------------------
> > > > > > > >
> > > > > > > > From: Xianglai Li <lixianglai@loongson.cn>
> > > > > > > >
> > > > > > > > commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream.
> > > > > > > >
> > > > > > > > If we directly compile the switch.S file into the kernel, the address of
> > > > > > > > the kvm_exc_entry function will definitely be within the DMW memory area.
> > > > > > > > Therefore, we will no longer need to perform a copy relocation of the
> > > > > > > > kvm_exc_entry.
> > > > > > > >
> > > > > > > > So this patch compiles switch.S directly into the kernel, and then remove
> > > > > > > > the copy relocation execution logic for the kvm_exc_entry function.
> > > > > > > >
> > > > > > > > Cc: stable@vger.kernel.org
> > > > > > > > Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
> > > > > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > >
> > > > > > > For loongarch64, I am seeing a bunch of errors like:
> > > > > > >
> > > > > > >     arch/loongarch/kvm/switch.S:201:1: error: unrecognized instruction mnemonic
> > > > > > >     EXPORT_SYMBOL_FOR_KVM(kvm_exc_entry)
> > > > > > >     ^
> > > > > > >
> > > > > > > `EXPORT_SYMBOL_FOR_KVM` does not exist in 6.18. Does this need a subset
> > > > > > > of commit 6276c67f2bc4 ("x86: Restrict KVM-induced symbol exports to KVM
> > > > > > > modules where obvious/possible")?
> > > > > >
> > > > > > Either that or just convert EXPORT_SYMBOL_FOR_KVM() => EXPORT_SYMBOL_GPL().  If
> > > > > > that's somewhat scriptable for ongoing LTS backports, that's probably the best
> > > > > > option.  EXPORT_SYMBOL_FOR_KVM() will only work for 6.18, and the list of backports
> > > > > > needed to get EXPORT_SYMBOL_FOR_MODULES() working on older LTS kernels looks to
> > > > > > be non-trivial
> > > > > >
> > > > > > If we do end up backporting EXPORT_SYMBOL_FOR_KVM() and others, we might as well
> > > > > > also grab a subset of 01122b89361e ("perf: Use EXPORT_SYMBOL_FOR_KVM() for the
> > > > > > mediated APIs") to ensure a kvm_types.h stub is present on all archs.  That way
> > > > > > EXPORT_SYMBOL_FOR_KVM() usage in arch-neutral code will also work.
> > > > > I have already noticed Greg about this before.
> > > > 
> > > > You did?  Where?
> > > 
> > > Small problem, I guess where he means is 'stable-commits@vger.kernel.org', is a
> > > not public maillist? I want to find it in 'lore.kernel.org' but not found... 
> > 
> > It's a public list, anyone can sign up for it.  Don't know if lore
> > archives it, but I'm sure that someone does...
> 
> Thanks for your reply. It is interesting that now i found them in
> https://marc.info/?l=linux-stable-commits&m=177859589029820&w=2,
> and https://marc.info/?l=linux-stable-commits&m=177859840800303

Ah, yeah, I had to delete that message due to that footer, and didn't
even look at it on request of the sender as it was confidental
information which is not allowed here.

thanks,

greg k-h