Re: [PATCH v2 20/20] KVM: x86: Use gfn_to_pfn_cache for record_steal_time

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On Tue, 2026-06-02 at 13:29 +0100, David Woodhouse wrote:
> 
> > [Severity: High]
> > Can this cause an ABBA deadlock in the scheduler on PREEMPT_RT?
> > 
> > kvm_steal_time_set_preempted() is called during a vCPU context switch
> > via kvm_sched_out(), which is a preempt notifier hook. This runs with
> > the local CPUs runqueue lock (rq->lock) held.
> > 
> > While the code correctly uses a trylock to avoid sleeping when acquiring
> > the lock, the CLASS macro destructor will implicitly call read_unlock()
> > at the end of the function. On PREEMPT_RT kernels, unlocking an rt_rwlock
> > can wake up a waiting writer, such as a concurrent kvm_gpc_refresh().
> 
> This one is more fun, and the problem already exists on RT for the Xen
> runstate update so it's not even really new with this patch.
> 
> I think the gpc lock needs to be a raw_rwlock_t, so that it remains a
> true spinning lock even on PREEMPT_RT. The writer side
> (kvm_gpc_refresh) only holds the lock briefly to swap in the new
> pfn/khva after doing the heavyweight work, so it should be fine as a
> raw lock.

Alternatively, since *most* uses of GPC are per-vCPU, a spinlock might
suffice. The exception is the Xen shared_info page, which is accessed
by all vCPUs.

We probably *could* turn that into a GPC per vCPU all pointing at the
same GFN, I suppose... but as someone pointed out fairly recently,
rwlocks don't scale that well as all the readers contend on the same
cache line anyway, so a spinlock might not turn out to be that much
worse even for the shared_info page.

Or maybe we should do a KVM_GPC_LOCK along the lines of KVM_MMU_LOCK,
which selects between rwlock_t and spinlock_t based on PREEMPT_RT?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]