From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.65 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794308849; b=gzcI5K79EsbanYVa4FrL1lSoYHpiXqTlVmx0UbCqVH55uiGlmshNvAR00ZCt2UORKzEq 7Eu8cSuRhuzh353gUKn8+HDX2o/5W7l0pQVNsBUysbHKvM/imSYd1kuOji3XXSdkGaDRQ pYk60wCNQTaFRAOzn8jMkTEF3DxFbfMx86klhJD4O7eLOTDjdM2W9cTcbkWRYcuioXzXo s4AqazYyXxudI8AT/ngdFJ26JsYlqiaHf6ihwQ8c+9hN56KNIJJvet+2YZ+b0PugWSuQU /f9irhyVFIwUXCx02dZeDJytWDTq4xfHLM+xWG1L6qmBp2Qb779QRvrNYegxOb+xXaA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794308849; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-ID: X-Mailer:MIME-Version:Content-Transfer-Encoding; bh=+WuNPbw52lAW5nlPUrA1jkhNZsabep1sDeJA5piAoms=; b=q+31NQ/m9iOzHaWYeBNa9ZjnuevNwwbQpdSWxndK1JxhbzDVjCxDIwVlrVg6ua9JY3lA 63jd6DIGiLAed/tP+rU8m7x/yTYkMiyTUJKpHRyEDQMtssRvWn/5hY3VNVWmyk3cKNAu/ PQWERPYmdnmShiVusXlzXCX6YtGtKt3X20hyPTG0hfRFJ8GayZvHCm6MVo8AlbpLpbIzO Wf49tm3MTJM16+XKnD1DBBh7+kHPdzk2XOyEOaeUWrVR8DS5gA+Kt2ih/RFFXhbBAR7lH nMRkxsmVUOqNBFnPpVcjQEmexkG8RsMbxJv8PrLQBa4HL37u8WDXUyM1iAEO/c1ldQQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=BwrYfzBq; arc=none smtp.remote-ip=95.215.58.65 Received: from mta1.migadu.com (out-65.mta1.migadu.com [95.215.58.65]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF0DD606A325 for ; Tue, 10 Nov 2026 11:07:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BF0DD606A325 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=BwrYfzBq X-Envelope-To: linux-doc@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=36LRZfyr2OW4sVBNO3Dr02OzqJxkojxqpAlVuG8gQtI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1794308845; v=1; x=1794913645; b=BwrYfzBqy01tK58Abn2QpNMEP9IAl7aiaY7r5v6sXKr+oYs6igvVm2u5bDqeUaOX/ql42fMV /t3Hf17CBNKq9zx0809S+p4C0Yj8uilC0pBh0q/Kqgw1aaH17P6P5875OFUlnM63qiTdDlCKrOQ 4d3Tp/GwlVmzKDgt3I5Feh3A= X-Envelope-To: linux-doc@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 6358020379288e82; Tue, 10 Nov 2026 11:07:25 +0000 X-Mizu-Trace-ID: 6358020379288e82 X-Migadu-Flow: FLOW_OUT From: Fuad Tabba To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Jonathan Corbet , Shuah Khan , Isaku Yamahata , Rick Edgecombe , Lorenzo Stoakes , Marc Zyngier , Oliver Upton , kvmarm@lists.linux.dev, Wei-Lin Chang , Will Deacon , Fuad Tabba 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 Message-ID: <20261110110724.3614412-1-fuad.tabba@linux.dev> X-Mailer: git-send-email 2.47.3 X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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