From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.210.197 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794326017; b=XzQXj+6KJTLjkJmlbIhX+I9BpMWODIEfKv13ViIW7HJR3qfl2tQejkd6unvRKZaTyftX 2drzMM2Ki2X7plzfzt0jf0+Dmz0SVhcHMGfJY8HHqn36ZV5Q/1Vlq+3M2gBR4DTBug9Sx q9bpibpMjj9JHRu9Dx/FYVATaNXQt4gnkN6+B4uxxDsXId2PygcBDJRaH4xbZduU5IEbP CBjhg/Gz8AEKl/rdwYPkQC5EcmadkyAkucXqEzgqj2eETp1iliO57QLd5pz1FZiNbqyqL 66+2VHfzRaDYKi5jfFtCGHcGNvzgv+ltrPc+EBCltVk1bw82u1SrlHYongJTkpjCn6A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794326017; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Received:Date:In-Reply-To: Mime-Version:References:Message-ID:Subject:From:To:Cc:Content-Type; bh=Mb0MdDBCZew5k3777cm9fQD62/5KwOz3NQ1SfeT9BE8=; b=UjzWNON7LgRx1bO5g8/Wfs3qIPTxop07zACiCSQ4639PDmAwQqf4xLU60r6YwBXr7qPT 13Vz243vVVOwqlddhZdlfDbRylHdOSHQng3HxMoNPDCVvcxWwi0ExJJAwikSueXaRQ1nd NPpIDj/wcDsvR7Af4MudALmGC4ejj8I/1eQaZY7wN+oa9c4ffz1DE0tVJb8lriPoFH+xb k8zemOpJC3hX72EEeAEpr4LbaOYapBhP9P6HwOMplMjf940I5phqCy0GXF3ddSEm02Fqu 9/sJcWVhcl51XmaFECEw4UKWO2X2dRc/FYviecHEYbIvh7WkIGgThKkqpn3cWIj3nlw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20260707 header.b=KdYgOstJ; arc=none smtp.remote-ip=209.85.210.197 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (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 17D55606A31C for ; Tue, 10 Nov 2026 15:53:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 17D55606A31C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20260707 header.b=KdYgOstJ Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-8a59717b0c0so1633891b3a.3 for ; Tue, 10 Nov 2026 07:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20260707; t=1794326016; x=1794930816; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Mb0MdDBCZew5k3777cm9fQD62/5KwOz3NQ1SfeT9BE8=; b=KdYgOstJ7KLq1UQCYnD9H+1JdC2fwddQe0d1osd1pI5CkONyb4xd30ewS/w0DolsYJ knbje4zjcRXc95NT2DxIGHuvwMxO8wzqB2goyjWWKKuO21kBp2M85q2UxpXKZHBVQ+KE gQGPicw5TyoImAIIqGWTJcQ+yAWfiv+RkAXUWMMA5R6pZd66vTfGFHN4aVnJ9iT08lxB 6LFkqs9sZzB4bPQCxaZFImj4SoLcVp5AEDD2ablOsfa3ZhpVdtGiYZPlb8HRE0wv1wSt /pdnHBlpmOYLmcaUAeGn2XjRl3F72aYJb8n0YZaS8OOQvnPs3RLVUMuj4yVD+B8tEHej /qTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794326016; x=1794930816; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Mb0MdDBCZew5k3777cm9fQD62/5KwOz3NQ1SfeT9BE8=; b=FZ4emhwcP0lkrlMZAIcHMozV4G9YVbKlV1d8cekMkc2ttqoRDXTJQ5p8x6D6NBaJdd 8/+3HnUHNj8O5ZUTJmyK9sbb4qSt8UGNUO6AebUFLbC0Zkz8wyX5aY8HYMelQ3yXkAAE WFesfF/5ryyxkXUQd6twlEARrquHUH4gIq+dmYB9N/ggJiMP+iikzj+nQOadamcnbRMF 6p4Qh0C/VlIIlTNH4nsM6xg7rKHcjAaPQ4CK2hEOpuowDJFwOYK9whD4CQvok0DeO6tP qsRSI2dUajv8eEBKT2YLRczf+LZp8kxJuHthPfM56Kiu3KbomHXFaHjjwGFt6RgR5CLm naAA== X-Forwarded-Encrypted: i=1; AL+hErF3MB94zWfTQ+dF4r1XhfvBL0WgWcTBmZiZdxZSfAEAQvW0CreoGUT5CXny77zsho1qrE/EQg1Mf+9t5Oc=@vger.kernel.org X-Gm-Message-State: APuU4Z9XbCsx/VGEpcVqQepFGr94s8qaXEOPBYFRVHVu5LUBVo5hCiHG ZdzwdzhahKO3WicDvCVY3RChgGGR5GG/ApJilGxu7aues4DjPwCKgAFASjNyWfmHXZgHF41MnRQ K5TJfjA== X-Received: from pfwp56.prod.google.com ([2002:a05:6a00:26f8:b0:89e:861c:6b39]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2402:b0:899:3439:c8d5 with SMTP id d2e1a72fcca58-8ba862ccf23mr3397440b3a.14.1794326016155; Tue, 10 Nov 2026 07:53:36 -0800 (PST) Date: Tue, 10 Nov 2026 07:53:35 -0800 In-Reply-To: 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 References: <20261110110724.3614412-1-fuad.tabba@linux.dev> <20261110110724.3614412-3-fuad.tabba@linux.dev> Message-ID: Subject: Re: [PATCH 2/2] KVM: selftests: Test KVM_PRE_FAULT_MEMORY against a full dirty ring From: Sean Christopherson To: Fuad Tabba Cc: "Lorenzo Stoakes (ARM)" , Paolo Bonzini , 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 , Marc Zyngier , Oliver Upton , kvmarm@lists.linux.dev, Wei-Lin Chang , Will Deacon Content-Type: text/plain; charset="us-ascii" On Tue, Nov 10, 2026, Fuad Tabba wrote: > Hi Lorenzo, > > On Tue, 10 Nov 2026 14:38:27 +0000, "Lorenzo Stoakes (ARM)" > wrote: > > On Tue, Nov 10, 2026 at 11:07:24AM +0000, Fuad Tabba wrote: > > > Pre-fault more populated, dirty-logged pages than the vCPU's dirty ring > > > holds, and check that each call stops before the ring overflows, that a > > > retry returns ENOSPC without progress, and that the harvested entries > > > are the pages in order. A read pre-fault can map a page read-only, or > > > > Are we asserting an invariant that prefaulting happens in address order > > here? Is that explicitly presumed in the prefault API, or just how it > > happens to pan out? > > > > I wonder if we might decide for whatever reason in future to do things > > differently there. Bit nitty I know, but wonder if it's asserting an > > implementation detail? > > Yes, the API doesn't guarantee an order. I'll assert that every page > is reported exactly once instead. > > [...] > > > diff --git a/tools/testing/selftests/kvm/pre_fault_memory_test.c b/tools/testing/selftests/kvm/pre_fault_memory_test.c > [...] > > > +static void test_pre_fault_dirty_ring(void) > [...] > > > + /* Populate the pages, so that pre-faulting can map them writable. */ > > > > Reviewed below, but I wonder how x86 could then read fault these? > > KVM_PRE_FAULT_MEMORY is defined as a read fault, but x86 maps the page > writable when the host page is, and marks it dirty, unless it falls > back to access tracking (below). Populating the pages makes sure they > aren't backed by the zero page. Before we effectively solidify the behavior, I think we should have an explicit discussion about the desired behavior of KVM_PRE_FAULT_MEMORY when dirty logging is enabled. E.g. the only reason I kept the existing behavior in my auto-prefault series was because I couldn't think of a good reason to change it. But we never made a concious decision in the first place, i.e. we never considered what would happen if prefaulting collided with dirty logging (as evidenced by this bug).