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