From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EB771E5B70 for ; Tue, 30 Dec 2025 15:43:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767109420; cv=none; b=r6QsDHsqMuFMpL1astq5I/C2eF4uO1VbSeBQuMvIY1T3RHXdhkaAdrEXzDjwhqJ11tNLL56PA3J5oS3U2PpzEIlgunArpZJaURMkhj4sK3jg8bG6Uh+48FguOrV788ONSpVdWHLweBInDmXGhE8X+xfJmYO8W8KE2TV2GP25sMM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767109420; c=relaxed/simple; bh=PVGG7JfzHJEzPAkrsIuaNh4bQsTTEnA0+kchX4fwi94=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=gcp1wH9eKikma+crXNbmE3nx+YZophdLxcQj+PpnvX/RFxDVAyccT2+RtDJhSKvqQ+8A5toodyfF6YwCX0x5xTnEHivmgJhX8IMK4HVy029B3HJN/vebtnTQo6PzUIodxm5dTg9/AYLPB9K2h2TQuO8BdD+kWRkIUQIjvV8SlCE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ckQ+6tDG; arc=none smtp.client-ip=209.85.216.73 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.b="ckQ+6tDG" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-34cc8bf226cso22560630a91.3 for ; Tue, 30 Dec 2025 07:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1767109419; x=1767714219; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=P2FhOAhoEBQ0BETm5QI3cfwMEJYegB0MimKAdHgGgOU=; b=ckQ+6tDGU99cWhYbQbu7plrDtIE9n6lqodfucliHDjpzxEJ0W3nU7EeBMdDVzN8Cfu GoAZtob8IVUw0iYfM40euzHS3QyNEnvB/Q/TEk28+qTmt5TXSDA26wQOo7cyeOjbeBUZ Q9SzfKKcfDEweiQh+0X/K/wHNaE+TiYoEtt7GpQ25lj+xjZwKatcSPeqIizj3Q1GC823 Gjt3cPTpph59olTBuooFDXxB7q32Zzw3QJ2PpIjffGbJWJmCbk3d+jbcAVmQtp4Q68WX BO/5bl7+LGNOTjXuDH0sv64Jj+7G9znkxjzaMk6/csrcMIf3JuLplgCEUnhVJMilTple +6LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767109419; x=1767714219; h=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; bh=P2FhOAhoEBQ0BETm5QI3cfwMEJYegB0MimKAdHgGgOU=; b=BYw6zLwtZPKFB/LrO4wlGVNmp2poPQg5gbWZ72b1BsYNt1r5Zyr9gdjkzm5nvQAJ3s OMqAfMuwJTMXh6T4eh/DyNbj7pqk6PLCXmgE6JaqnxsJGV3KTzAN3WcZfrShsmJimaT3 MsKkRojkd745Z9UJYlQG/EEMrLL9bDEdR/s/Gh9j+UO1zUWdwWtyFNrHMBOFWRLMAQEj tOraRY+/SjeiD6aP+dOb/VIE0qEQZwZARLZSq82noRXoAyfjnpHkyPTSO6OJC48BzRaB SckjSLj8tvoNs2VJYB8aDnbkAIjW4H/mEhufrWtC1iQ4wHkSfg7liZceFt6fVPu8RJ6q EQog== X-Forwarded-Encrypted: i=1; AJvYcCUUr/rsLONMEy61VFQ7D2gQvxphrN+Htu7p06AFx67BmEK6IE6Ykcj7yQAQEjzb1CgZPYd+4bUQGlLTyqg=@vger.kernel.org X-Gm-Message-State: AOJu0YwaEQIBEy/LDfcwYHRmQSB7Wi0kdcPtCR4zy8xTAbl2cJlunna3 WhxfuUejsSBfdV+IwJF23JXkeyKP59YB7RpRCc9C2qd9XYS+a2sRkEgPCupdnB2hCJVVhM77Dtr 5ZjDb/g== X-Google-Smtp-Source: AGHT+IHk01rKNUVNTE/9QLom8LLLSWyyqEEMiirrvuhsmpQc7J1hUNr59x9uT8Jo0uZI0KspWc1dCf8RjPY= X-Received: from pjxx11.prod.google.com ([2002:a17:90b:58cb:b0:34c:6f7a:2ab8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:6c7:b0:34c:a29d:992a with SMTP id 98e67ed59e1d1-34e921d6cbamr24908645a91.34.1767109418785; Tue, 30 Dec 2025 07:43:38 -0800 (PST) Date: Tue, 30 Dec 2025 07:43:37 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251127013440.3324671-1-yosry.ahmed@linux.dev> <20251127013440.3324671-11-yosry.ahmed@linux.dev> <2sw7xjtjh4ianp2dz7p24cht2v6u55wcdac4xlrxn5vjgqti77@4ohtwtywinmi> Message-ID: Subject: Re: [PATCH v3 10/16] KVM: selftests: Reuse virt mapping functions for nested EPTs From: Sean Christopherson To: Yosry Ahmed Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Tue, Dec 30, 2025, Yosry Ahmed wrote: > December 29, 2025 at 4:08 PM, "Sean Christopherson" wrote: > > > > On Tue, Dec 23, 2025, Yosry Ahmed wrote: > > > > > On Tue, Dec 23, 2025 at 03:12:09PM -0800, Sean Christopherson wrote: > > > On Thu, Nov 27, 2025, Yosry Ahmed wrote: > > > > diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h > > > > index fb2b2e53d453..62e10b296719 100644 > > > > --- a/tools/testing/selftests/kvm/include/x86/processor.h > > > > +++ b/tools/testing/selftests/kvm/include/x86/processor.h > > > > @@ -1447,6 +1447,7 @@ struct pte_masks { > > > > uint64_t dirty; > > > > uint64_t huge; > > > > uint64_t nx; > > > > + uint64_t x; > > > > > > To be consistent with e.g. writable, call this executable. > > > > > > Was trying to be consistent with 'nx' :) > > > > > > > > > > uint64_t c; > > > > uint64_t s; > > > > }; > > > > @@ -1464,6 +1465,7 @@ struct kvm_mmu { > > > > #define PTE_DIRTY_MASK(mmu) ((mmu)->pte_masks.dirty) > > > > #define PTE_HUGE_MASK(mmu) ((mmu)->pte_masks.huge) > > > > #define PTE_NX_MASK(mmu) ((mmu)->pte_masks.nx) > > > > +#define PTE_X_MASK(mmu) ((mmu)->pte_masks.x) > > > > #define PTE_C_MASK(mmu) ((mmu)->pte_masks.c) > > > > #define PTE_S_MASK(mmu) ((mmu)->pte_masks.s) > > > > > > > > @@ -1474,6 +1476,7 @@ struct kvm_mmu { > > > > #define pte_dirty(mmu, pte) (!!(*(pte) & PTE_DIRTY_MASK(mmu))) > > > > #define pte_huge(mmu, pte) (!!(*(pte) & PTE_HUGE_MASK(mmu))) > > > > #define pte_nx(mmu, pte) (!!(*(pte) & PTE_NX_MASK(mmu))) > > > > +#define pte_x(mmu, pte) (!!(*(pte) & PTE_X_MASK(mmu))) > > > > > > And then here to not assume PRESENT == READABLE, just check if the MMU even has > > > a PRESENT bit. We may still need changes, e.g. the page table builders actually > > > need to verify a PTE is _writable_, not just present, but that's largely an > > > orthogonal issue. > > > > > > Not sure what you mean? How is the PTE being writable relevant to > > > assuming PRESENT == READABLE? > > > > > Only tangentially, I was try to say that if we ever get to a point where selftests > > support read-only mappings, then the below check won't suffice because walking > > page tables would get false positives on whether or not an entry is usable, e.g. > > if a test wants to create a writable mapping and ends up re-using a read-only > > mapping. > > > > The PRESENT == READABLE thing is much more about execute-only mappings (which > > selftests also don't support, but as you allude to below, don't require new > > hardware functionality). > > Oh okay, thanks for clarifying. Yeah that makes sense, if/when read-only > mappings are ever supported the page table builders will need to be updated > accordingly. > > Although now that you point this out, I think it would be easy to miss. If > new helpers are introduced that just modify existing page tables to remove > the write bit, then we'll probably miss updating the page table builders to > check for writable mappings. Then again, we'll probably only update the leaf > PTEs to be read-only, and the page table builders already do not re-use leaf > entries. Yep, unless we rewrite the KUT access test :-) > We could be paranoid and add some TEST_ASSERT() calls to guard against that > (e.g. in virt_create_upper_pte()), but probably not worth it. Agreed.