From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.136 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794308848; b=LCAh2pTzoTrEEfrAqpiiUKB73Vl2TTaprhZJGIy86rV/J5QUO91NF4tngi9WRbFritGQ RwbjeqUW5g6EiPcF1ux4Ah/xAPafuBC7mNAGqOR/vej3kmKR0eZH2jhEYn+z6WJ/OdCWl rWyfns2XKjaUSSB7sv4bNQPLi2oNzfKCcqwEDyFS+E10YC3d+vvvVNuqBeS87KZKPIxzD QEm2YaeUiC6pRAAXuJZw8YI+fFUc0gIlOZK9DNgTmfEM54ug9aB2w9C3wyI2Uj0ZD3Gej dFmHNBY8jX/SkPlRZIX1ZQt/VctV43tb2PLbXrb825MxdXPAPy+EtXfL60Acj1gE3Tw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794308848; 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=D8QtZnsyUDWDcZRjk09aiVLw7I6k4/3J70Ro3sjH0h0pEjNszm00iZ0EuSYKOOW8k/rh QmmeuEvP+VvEL3iMqEuSAseLdWWBxzGcpMMDPUatLyjZCFCjB2mDQTdF8HBLm5w26ylEZ 8clTaO3oys60VN1uVCCiqgT1+f+QVqoIKFw6VN1+0CJ6+GQdBp/wioU64TMtcGswtxqoK yRby8GIHnmXwQ7i6ByTK3Eo96RJDIn7dNM/aizEcyXgo6PlCEDVqPNhUIiwhBOvtbe4g2 6Yd4RDIW09w6OcUk7dmKdBMoY6LqmvhugIeXtpWLRVXMNZdmi1dNXUZY1KjrD8OTqhA== 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=91.218.175.136 Received: from mta0.migadu.com (out-136.mta0.migadu.com [91.218.175.136]) (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 AEE1A606A321 for ; Tue, 10 Nov 2026 11:07:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org AEE1A606A321 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: kvm@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: kvm@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: kvm@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