From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.214.197 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794409069; b=PztaPsCOvv5kyNM5NYH5oLY1emBA2euroLnFKyN2+wWFzp9YE2KtwFE+ADDd4pQEYCJe 81R/yEncVeMa4/g4tULjwEzotjEK5Mh6h/53Wb9JLoadEmpOhoJ85x4fG4TDJdBf0y+4I fTr9KZmS/s1UdzCXceIBoxjoFfbwpxLGOgunZyUyKvZLWn6aQgghYNUH/6sfs4w3qPodD AzfVu3Rx9b0NnDMyN0vsZRvUvgbEDCY2+cfuLFWLn0YohozeAp7/49sZTcwaTJYjedTWl 3vWCpJSe6uMkClNHUL6vfZQQKyWXMaRU9OmXc1HUd9MnMJYr8ZuiJ5iNvnXBZjEdOPw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794409069; 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=eAVBx7wFjerY7MFoeOAbmTCOK2sMbdc2RAGG1TuVAr8=; b=0YhhUCKMzbianDhuZE50lkEvs0ijObXDs3xsljpnKahggnceXuUbq/64k0ApppiJIOsk 1+WTfbrlWpYcx3uA0pq+MdQD1CIjaEEyALk75XPWxgsDEqap+AlIXdvWmWKBNSj40UzuG ZhKSWC+Ih2TuhllJZcVnvFw7gmSXNOdxsK0mKo2dSDR3djRmEUg1kGgfmqfB/7VBSBhGN kt+l1Q40kXy8uPIkZ2OtoSbLUYNPj8TwjGINcA3nV7IwRZucNQD0X1nhz4KsW2WtUkdao AugPSIqAqwB2WvNFw6gby+WQqIyltwhFyCUvICP/VVuVfraS6K27dPvy2vgQmRi3EWA== 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=SnDZnbQW; arc=none smtp.remote-ip=209.85.214.197 Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.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 9150F606A32D for ; Wed, 11 Nov 2026 14:57:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 9150F606A32D 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=SnDZnbQW Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2e8e16d22d8so51480085ad.1 for ; Wed, 11 Nov 2026 06:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20260707; t=1794409068; x=1795013868; 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=eAVBx7wFjerY7MFoeOAbmTCOK2sMbdc2RAGG1TuVAr8=; b=SnDZnbQW08z6Fo4oJucBlqSIoq6P3dVOZg3XM1Dl/02agzkA/301/aw2F7NgWhAchy Wrg3nXmwTrMfZdpaRe6LCOV0iBJotVmWkTKtR6lmYksyh9YQT30J1u8TqxL8NSwBEJ82 6s+Kzx8EwS9d4JgM255tB6JnwGGEcH87zaEeSrPuXt3/fVAXl9GgdYWOXnMXxgJj/onR TPukIkcch7Kyq/N/MD4PSICv8FhVaHu01Y7RNzFFNpHWn1Bd+LbJy/xLbKreSZcB2Df4 I4Mu/MsJhKxSLF0dAtCfTtLoDcVSAQFGEqPmyZj2Ia7x9yDNmdOOTpKTQnia1OnqZfqu ceuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794409068; x=1795013868; 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=eAVBx7wFjerY7MFoeOAbmTCOK2sMbdc2RAGG1TuVAr8=; b=DjKT3cjthz3+9bhVanaawPTwpZfHGWKYA13fHCdpFAKYM1j6BDTEmPGxzNjoFxg8Ly n+/wHh8RldKDxFhPs8HSYxLwSEzuVNXCxjmz3K22ZZqV6P2brHKlSfwYDdoPWosQ/LgO lc8abVBMt5yCt/sZWcaau31N14Vi5d0FS1dPVaC37rMHn7K1xFNIy+iLcsqyVAKIBVuX MHuAi1b9Lwul9ToSXmQOs55fSGOP36AXQr8lU+j89KUkxoNFn8+kHC7ECk4N936H+QL+ DIboao6h/mzeFwPcT4cl3qVwFKQrnxHUUW6Evs2GVBgmyVSvoMYgWO/iCal/q7GQT3WY 5/ZA== X-Forwarded-Encrypted: i=1; AL+hErEbU4Dje1FcfeM39gFOmOS6hSNAaMBL/+DAHLbADX+Qn6XKEpEW5sMkZRwXQQGc83Sjk87v2d92kJU=@vger.kernel.org X-Gm-Message-State: APuU4Z+T03JYMJ9KYaqId6w9LtkYipjzVNBpnrlFXaobDtJ9CZcdHmyL m5UIt2Y8Pb+4QRGRNhP9V7QI5kp1uLqAdrZ1LLYUdWHEn0FCMkXBc+q0VZrKcUFuOCcNDpgnoLv EuR9QXQ== X-Received: from plri11.prod.google.com ([2002:a17:903:32cb:b0:2e9:4bf0:5f17]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:b84:b0:2ed:238b:7db8 with SMTP id d9443c01a7336-2edd7bae0fcmr30337835ad.61.1794409067689; Wed, 11 Nov 2026 06:57:47 -0800 (PST) Date: Wed, 11 Nov 2026 06:57:46 -0800 In-Reply-To: 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 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: Alexandru Elisei Cc: "Lorenzo Stoakes (ARM)" , Fuad Tabba , 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 Wed, Nov 11, 2026, Alexandru Elisei wrote: > On Tue, Nov 10, 2026 at 04:02:21PM +0000, Lorenzo Stoakes (ARM) wrote: > > On Tue, Nov 10, 2026 at 07:53:35AM -0800, Sean Christopherson wrote: > > > On Tue, Nov 10, 2026, Fuad Tabba wrote: > > > > > > 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). > > > > Yeah, I do worry about implicit assumptions (also commented re: ordering). > > > > I guess what makes sense, given the general approach for prefaulting = injecting > > a synthetic read fault, is for the expectation to be that it matches the > > behaviour of an ordinary read fault. > > Unfortunately, what happens in this case is not as obvious as it sounds, > because a read fault on a memslot backed by guest_memfd maps the GPA with > read *and* write permission on arm64 (if the memslot is not readonly, > haven't checked what x86 does). Ya, this isn't about read vs. write faults, it's about whether or not *any* "fault" from KVM_PRE_FAULT_MEMORY should be allowed if the target memslot has dirty logging enabled. I'm leaning toward "yes", mainly because I suspect that fully preventing installing writable mappings when dirty logging is enabled across all architectures would be more difficult that ensuring generic code doesn't explode, and in practice I doubt any real VMM usage of KVM_PRE_FAULT_MEMORY will care about dirty logging interactions, i.e. any KVM behavior will be a-ok with userspace.