From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Sean Christopherson <seanjc@google.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
James Houghton <jthoughton@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-rt-devel@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: KVM: x86/mmu: __kvm_rmap_lock() preemption assert trips on PREEMPT_RT
Date: Fri, 28 Aug 2026 12:45:37 +0200 [thread overview]
Message-ID: <20260828104537.pXtV2G8D@linutronix.de> (raw)
In-Reply-To: <apC3lYri5r4KUM3T@google.com>
On 2026-08-27 15:17:57 [-0700], Sean Christopherson wrote:
> > @@ -1745,11 +1754,15 @@ static bool kvm_rmap_age_gfn_range(struct kvm *kvm,
> > gfn_t gfn;
> > int level;
> >
> > +#ifdef CONFIG_PREEMPT_RT
> > + guard(read_lock)(&kvm->mmu_lock);
> > +#endif
>
> And now I remember why I swept this under the rug. This really should take
> mmu_lock for write, otherwise concurrent aging threads could theoretically get
> stuck competing for KVM_RMAP_LOCKED. Which is silly, because they don't actually
> need to take a lock of any kind. I.e. it's not super trivial?
>
> Wait, duh. It is trivial if mmu_lock is held, because then KVM can operate on
> rmaps without any KVM_RMAP_LOCKED shenanigans. I wouldn't test this because it
> might break horribly, but I think this?
So you drop the bit spinlock and rely on kvm->mmu_lock instead? No sure
why it should break horribly but it looks reasonable.
Sebastian
next prev parent reply other threads:[~2026-08-28 10:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 21:13 KVM: x86/mmu: __kvm_rmap_lock() preemption assert trips on PREEMPT_RT David Woodhouse
2026-08-27 21:47 ` Sean Christopherson
2026-08-27 21:58 ` David Woodhouse
2026-08-27 22:17 ` Sean Christopherson
2026-08-28 10:45 ` Sebastian Andrzej Siewior [this message]
2026-08-28 11:16 ` David Woodhouse
2026-08-28 14:23 ` Sean Christopherson
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=20260828104537.pXtV2G8D@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=dwmw2@infradead.org \
--cc=jthoughton@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
/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