From: Fuad Tabba <fuad.tabba@linux.dev>
To: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Isaku Yamahata <isaku.yamahata@intel.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Lorenzo Stoakes <ljs@kernel.org>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
kvmarm@lists.linux.dev, Wei-Lin Chang <weilin.chang@arm.com>,
Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>
Subject: [PATCH 0/2] KVM: Bound KVM_PRE_FAULT_MEMORY by the vCPU's dirty ring
Date: Tue, 10 Nov 2026 11:07:22 +0000 [thread overview]
Message-ID: <20261110110724.3614412-1-fuad.tabba@linux.dev> (raw)
Hi folks,
KVM_PRE_FAULT_MEMORY never checks the vCPU's dirty ring, so one call
over enough populated, dirty-logged pages overflows it. The first patch
stops the loop at the soft limit, as KVM_RUN does. A stopped call
returns its partial progress, or, if it stopped before any, -ENOSPC
rather than the retryable -EAGAIN, since no retry can succeed until the
ring is harvested. The second patch adds the case to
pre_fault_memory_test.
On x86 a read fault normally maps a host-writable page writable and logs
it at once, so pre-faulting overflows the ring. Sean's auto-prefetch
series [1] keeps that behaviour for a pre-fault, so this series bounds
the loop rather than have x86 write-protect a pre-faulted page. On
arm64, which gained the ioctl in 7.4, pre-faulting RAM logged with the
ring alone overflows it too, until Wei-Lin's fix [2] is in mainline.
Pre-faulting isn't the only ioctl that can push past the ring's
reserve. On x86, KVM_SET_MSRS does too when it writes the wall clock or
the Hyper-V hypercall page: up to a few hundred entries in a single
call, with no bound across calls. KVM_SET_MSRS can't take the same
stop, since a short count from it means the MSR failed and QEMU asserts
on it.
What those paths should do when the ring fills is an open question for
the dirty ring API, which I don't think belongs in this series.
Pre-faulting a large logged range is a supported use of the ioctl, so
the loop should handle a full ring rather than lose entries.
Tested on x86 and arm64 under QEMU: without the first patch, the new
case hits the WARN on both.
Based on Linux 7.4-rc2 (7475ea8b58616).
Cheers,
/fuad
[1] https://lore.kernel.org/all/20261028202607.1844883-1-seanjc@google.com/
[2] https://lore.kernel.org/all/20261029175238.3214788-2-weilin.chang@arm.com/
Fuad Tabba (2):
KVM: Stop KVM_PRE_FAULT_MEMORY when the vCPU's dirty ring is full
KVM: selftests: Test KVM_PRE_FAULT_MEMORY against a full dirty ring
Documentation/virt/kvm/api.rst | 9 +-
include/linux/kvm_dirty_ring.h | 6 ++
.../selftests/kvm/pre_fault_memory_test.c | 85 +++++++++++++++++++
virt/kvm/dirty_ring.c | 2 +-
virt/kvm/kvm_main.c | 6 ++
5 files changed, 105 insertions(+), 3 deletions(-)
base-commit: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
--
2.47.3
next reply other threads:[~2026-11-10 11:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 11:07 Fuad Tabba [this message]
2026-11-10 11:07 ` [PATCH 1/2] KVM: Stop KVM_PRE_FAULT_MEMORY when the vCPU's dirty ring is full Fuad Tabba
2026-11-10 14:22 ` Lorenzo Stoakes (ARM)
2026-11-10 15:48 ` Sean Christopherson
2026-11-10 11:07 ` [PATCH 2/2] KVM: selftests: Test KVM_PRE_FAULT_MEMORY against a full dirty ring Fuad Tabba
2026-11-10 14:38 ` Lorenzo Stoakes (ARM)
2026-11-10 15:37 ` Fuad Tabba
2026-11-10 15:53 ` Sean Christopherson
2026-11-10 16:02 ` Lorenzo Stoakes (ARM)
2026-11-10 15:57 ` Lorenzo Stoakes (ARM)
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=20261110110724.3614412-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=corbet@lwn.net \
--cc=isaku.yamahata@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=skhan@linuxfoundation.org \
--cc=tabba@google.com \
--cc=weilin.chang@arm.com \
--cc=will@kernel.org \
/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
all inboxes | Powered by JetHome®