From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.63 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794308849; b=e52NyQY42FVnn/pUuA/FUi3DnJkES2YCbaJqbfi3PylM40VLtSxJ0XT2kwZ8k9xzTRfA BdsqfJ6R3te8kLU1GV3PZG6hHD7FRjiwT97rdCt/QLXxIwkTl1iGTzDdf7y0xpV+bwAFN gY3Paj5bLWUraWNWdJLkQc50U8G21j8ArCE58Cm6FFepXUB7lX/OH8QhFf9FQoCr+2CoF VcRQQTW9P/CKu8FCQQw9Wkt8nZZciBY/Qx/Rh/dgYLIMeFVRDTXDDBGUY2ddQBm3Xnmq8 iR87cvCU1oILqSpm4mYyeRKOwpWZkXEZR4TEWVjQggUUI5wyF9AtZrGaWL6w09gSr9g== 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=eZqa/uoANE9HY/CHaVpBBaSXrZb8QGZKSnrn9B0poBoO1DILH8A6hKly6M/gf+6hQy+l z0eTaCOgzY3t1J5kmfhbfPQ8g6mSjTIzYq5J+v9sXUMnTN/AJM8Sy1MHq3jIxFbqwbBnr 8l4HcS7Zy1F3IuSkKjIZpeY06JPNXt3oulju/8h/r8YsVsHDwA7sRMvskjZn6luYDKvFo NEY99bFFnEuq8cLLG3ZjZPnsCEFLMUlmEOll/ZRUAUTPO6HMivVcxGXAcW3eghvt5KLKL Z7YqeXKnh9ngQiJtmMOwT9UdtG+TxO7uTttbVnwvGXhTc8fsd0eN0pWuaseRiUQUc6g== 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.63 Received: from mta1.migadu.com (out-63.mta1.migadu.com [95.215.58.63]) (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 C5C93606A32A for ; Tue, 10 Nov 2026 11:07:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org C5C93606A32A 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-kernel@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-kernel@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-kernel@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