Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: Sean Christopherson <seanjc@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Tianrui Zhao <zhaotianrui@loongson.cn>,
	Bibo Mao <maobibo@loongson.cn>,
	kvm@vger.kernel.org, loongarch@lists.linux.dev,
	Dave Hansen <dave.hansen@linux.intel.com>,
	chenhuacai@loongson.cn, lixianglai@loongson.cn,
	patches@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel
Date: Wed, 13 May 2026 12:31:38 +0200	[thread overview]
Message-ID: <2026051319-lazily-machine-5ab3@gregkh> (raw)
In-Reply-To: <CAAhV-H6GFmKrJpVgaShCzUigZByvQkXQy_2qGcyaJ089Q6chWg@mail.gmail.com>

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

  reply	other threads:[~2026-05-13 10:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260512173940.376401154@linuxfoundation.org>
2026-05-12 20:52 ` [PATCH 6.18 091/270] LoongArch: KVM: Compile switch.S directly into the kernel Miguel Ojeda
2026-05-12 21:53   ` Sean Christopherson
2026-05-13  3:06     ` Huacai Chen
2026-05-13 10:31       ` Greg KH [this message]
2026-05-13 11:58         ` Wentao Guan
2026-05-13 12:04           ` Greg KH
2026-05-13 12:08             ` Wentao Guan
2026-05-13 15:29               ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026051319-lazily-machine-5ab3@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=chenhuacai@loongson.cn \
    --cc=dave.hansen@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=lixianglai@loongson.cn \
    --cc=loongarch@lists.linux.dev \
    --cc=maobibo@loongson.cn \
    --cc=ojeda@kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=seanjc@google.com \
    --cc=stable@vger.kernel.org \
    --cc=zhaotianrui@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox