From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 7A88C23C8AE for ; Tue, 24 Feb 2026 01:49:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771897763; cv=none; b=jMyIpfvSyPdZllSjh44Ao/okoNTyo4RRjYCm2M70TamiB8xhYnGePEqwNkqe+eVdK17q1h+T7KpEddcv8fXo8eqhCDn+Sww+uQW6lKc2bhTznzT5BOBG0mr+eT/qrEJMqyDGeY8u12EBqxxeablB1ypLlZHaJvppVxEAHFG5jaY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771897763; c=relaxed/simple; bh=IM/dFotgxCBntq2RASsz3TTaWI3IzsV8R9xfptDQtlQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=EzSsn5szPEDGrY2k6ADjRdwzJydD7ihHAbl75Keh8OrxQh0pjiOLK8lGuOFfB7j22thlK/HqrOU0ipCvns/1maQPIheA5oe8luuNs5/FUUXsnXYyUAlXWQBMIa9zrvMQTZj3SrVtoo2bvGmaG+ENPgCTlXc+V08mWrtPkW1oYvk= 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=RuvunU56; arc=none smtp.client-ip=209.85.216.74 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="RuvunU56" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-358dc09b43eso311269a91.2 for ; Mon, 23 Feb 2026 17:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771897762; x=1772502562; 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=hCd5yhTyb7AdeCfY90uFmMReNGClYsEIW1vYQS0KNyw=; b=RuvunU56H8EcVDvgJq0DSEANAMTB+kTFtBKQ9rzW14qAMB0JmqhUFxQ2Uxe7xbLeH3 nRfaZMLCJMYIAguRfCxflhGqXqbO6IBijdv6Fjeph27TQO5HfqcSEojn2SPtK7oVZlxk opU2HH5v6FpWO3NGc425ppCb9a1w9Nn4u49cOQJh4A661FowUUnmlf06x3E1gyzs4Tg3 UxU9OaJpi+NODCWQmtJwjD+uLAOiFB8kFP1/cuZwY21EsvsVoCu1d9vjPkG8I1sli0zG 7rFrbuNszAW7w0v+PlSlsyYdrRep6FYbC/bumxyaaZk6W7BkiiuL2wH8RNrbtoHMrDSG sxsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771897762; x=1772502562; 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=hCd5yhTyb7AdeCfY90uFmMReNGClYsEIW1vYQS0KNyw=; b=A6u8NWSXupB7ANgLBQmbVBKNOU3KbMBnFkwEF/DJo7VrHSdHOHe68kl5IHIJjjf7uf pwrU/oPlF3G9Sf4LP7g+kzPdQvpG1SuAsg6X2eq0eW4foLCPpynP577SKUJckSd5Qb0t JiQOrMM5oJrzCkKe6x8ezOgas/ZA/ixw+YMMpBHCiCHtUvwLaTpIlJ9v4kOSs6XEWNgJ rRpyMNicfVXcWRSgDK5seWM+YuSlNmLttDz3AEWQWYMYpRePLNSZ5HDErxtCElZc/9Po /S/kd31IfMtcQzfuR3Ir3ptXABehShXrj4CuMODZ1Fmxs/zYI/urkvKk3c2fobuYJi+8 vyRA== X-Forwarded-Encrypted: i=1; AJvYcCViXVzNABDG5lkiIODKQnohSyW+UrTIm3W8nTlSBZWZiALRLeYbbsbdJIwiWKpa7bbZ8wSf17WJAAYH7fg=@vger.kernel.org X-Gm-Message-State: AOJu0YxY3u11/XAHVint/nbzc0/xL2oo3I2RPpmIm1GTyimT+2dDVJTn yVYFUe1PC7B2BPk8Xfvk+AwM3EFhUbWDMmN6ua4o8aCbyeOsCkKu0fo2uTf6lS9YFt863bWGfKQ dj8m+hA== X-Received: from pjog6.prod.google.com ([2002:a17:90a:8f06:b0:352:d1c1:470]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2c85:b0:352:c995:808a with SMTP id 98e67ed59e1d1-358ae7fe4a4mr10565462a91.14.1771897761656; Mon, 23 Feb 2026 17:49:21 -0800 (PST) Date: Mon, 23 Feb 2026 17:49:20 -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: <20260219002241.2908563-1-seanjc@google.com> <7986057373abcb20585c916804422a13f51d5e55.camel@intel.com> Message-ID: Subject: Re: [PATCH] KVM: x86/mmu: Don't create SPTEs for addresses that aren't mappable From: Sean Christopherson To: Rick P Edgecombe Cc: "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , Yan Y Zhao , "yosry.ahmed@linux.dev" Content-Type: text/plain; charset="us-ascii" On Mon, Feb 23, 2026, Rick P Edgecombe wrote: > On Fri, 2026-02-20 at 16:49 -0800, Sean Christopherson wrote: > > > But also the '5' case is weird because as a GVA the max addresse > > > bits should be 57 and a GPA is should be 54. > > > > 52, i.e. the architectural max MAXPHYADDR. > > Oops yes I meant 52. But if it is always max physical address and not > trying to handle VA's too, why is PT32E_ROOT_LEVEL 32 instead of > 36? Setting aside how any nNPT with a 32-bit kernel works for the moment, it would be 52, not 36. PT32E_ROOT_LEVEL is PAE, which per the SDM can address 52 bits of physical address space: PAE paging translates 32-bit linear addresses to 52-bit physical addresses. PSE-36, a.k.a. 2-level 32-bit paging with CR4.PSE=1, is the horror that can address 36 bits of physical address space by abusing reserved bits in the "offset" portion of a huge 4MiB page. Somewhat of an aside, KVM always uses 64-bit paging or PAE paging for its MMU (or EPT, but that's basically 64-bit), and so when running on 32-bit kernel, KVM requires a PAE-enabled kernel to enable NPT, because hCR4 isn't changed on VMRUN, i.e. the paging mode for KVM's MMU is tightly coupled to the host kernel's paging mode. Which is one of several reasons why nNPT is a mess. /* * KVM's MMU doesn't support using 2-level paging for itself, and thus * NPT isn't supported if the host is using 2-level paging since host * CR4 is unchanged on VMRUN. */ if (!IS_ENABLED(CONFIG_X86_64) && !IS_ENABLED(CONFIG_X86_PAE)) npt_enabled = false; As for how running a 32-bit PAE nNPT "works", I suspect it simply doesn't from an architectural perspective. 32-bit KVM-on-KVM works (though I haven't check in a few years...) because Linux doesn't allocate kernel memory out of high memory, i.e. L1 KVM won't feed "bad" addresses to L0 KVM, and presumably QEMU doesn't manage to either. I might be forgetting something though? If I get bored, or more likely when my curiousity gets the best of me, I'll see how hardware behaves.