[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aRZHeTNW9o5SlQSK@google.com>
Date: Thu, 13 Nov 2025 13:02:49 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Chao Gao <chao.gao@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Allocate/free user_return_msrs at kvm.ko
(un)loading time
On Mon, Nov 10, 2025, Chao Gao wrote:
> >-static int kvm_init_user_return_msrs(void)
> >+static void kvm_destroy_user_return_msrs(void)
> > {
> >- user_return_msrs = alloc_percpu(struct kvm_user_return_msrs);
> >- if (!user_return_msrs) {
> >- pr_err("failed to allocate percpu user_return_msrs\n");
> >- return -ENOMEM;
> >- }
> >+ int cpu;
> >+
> >+ for_each_possible_cpu(cpu)
> >+ WARN_ON_ONCE(per_cpu(user_return_msrs, cpu).registered);
>
> Could this warning be triggered if the forced shutdown path didn't
> unregister the user return callback (i.e., with the patch [*] applied),
> and then vendor modules got unloaded immediately after the forced shutdown
> (before the CPU exits to the userspace)?
Probably? But that's more of a feature than a bug, e.g. gives the (privileged!)
user the heads up of how exactly they broke their system when they forced a
reboot. I'd prefer not to condition it on e.g. !kvm_rebooting unless it's truly
necessary, because it's "just" a WARN, i.e. shouldn't crash the system.
> [*]: https://lore.kernel.org/kvm/20251030191528.3380553-4-seanjc@google.com/
Powered by blists - more mailing lists