Re: [PATCH v2 00/20] KVM: Use atomic SRCU for gfn-to-pfn cache, reinstate guest mode for x86 nesting

[Sean Christopherson <seanjc@google.com>]

On Tue, Nov 10, 2026, David Woodhouse wrote:
> On Thu, 2026-11-05 at 02:00 +0000, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > 
> > Based on v7.4-rc1 (kvm/next doesn't have the atomic SRCU flavour yet),
> > this series:
> > 
> >  • Converts the GPC to use atomic SRCU, ditching the rwlock which was a
> >    scaling and latency problem, and which PREEMPT_RT hated because it
> >    turned the rwlock into a sleeping lock¹.
> > 
> >  • Fixes the pre-existing bugs which torture-testing that conversion
> >    shook out: a guest-reachable dirty ring overflow from the hypercall
> >    page write (128 pushes of the same gfn against 64 reserved entries,
> >    without PML), and a lost TLB flush request in record_steal_time().
> > 
> >  • Adds KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE, for VMMs which
> >    intercept the guest's MSR write and need to replay it from host
> >    context².
> > 
> >  • Cleans up the intentional lack of dirty-tracking of Xen shinfo and
> >    vcpu_info pages (Sean).
> > 
> >  • Converts steal-time / preempted status to use gfn_to_pfn_cache.
> >    (Carsten)
> > 
> 
> I love it when sashiko-bot finds things which my own local runs don't.
> I'm still iterating on the latter part of the series; I think it
> probably makes sense to merge the first half (patches 1-9 above), and
> the nested parts (below) can come later.
> 
> Sean, what do you think?

Ya, I'm definitely in favor of that.  Even if Sashiko didn't find anything, I
think I'd want to grab the GUEST_USES_PFN stuff separately.