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 E6FA99476 for ; Sat, 21 Feb 2026 00:49:12 +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=1771634954; cv=none; b=FPOuUS1GbKR0olCKNTDRrES8pZECkYobowWtn5PnmBtitS6SVlPpC9UbCWX3r0KqlKZ3a5FORhq+hzArE1BorAFdYAm8UrZqaSviTlu8W3Yf/0+ehrblU15V2204X3s41hZPaIJ96NMaskq9ubeYQVDDmOtKA6uwbiSS1tiEvjU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771634954; c=relaxed/simple; bh=T7zTvaIxgBfhy5lDDPQ1TN1ZokP0oSGzQHGYLXZ6Qac=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=uOZBQC3o/aYZkGdPBfYw+xh9jrREtcVafC51a3HRGVfvTPogQ/bTNURP7nLnDwFDbS6AOeUhiAjI5Qk3LQDlBuzBUCf7du8f32wM63kSRPw5e+mWtXbMxWrsofmRGLeRFaiAoT45uMbkeW3mmD03ud7JtATT8Ly2OpVyBb14QqA= 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=hBbLJYj9; 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="hBbLJYj9" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-3561f5bd22eso2307189a91.2 for ; Fri, 20 Feb 2026 16:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771634952; x=1772239752; 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=CWr0HuJWiATaTNOSdTyLvXYll6+nwgjSWjXAo4M2MD4=; b=hBbLJYj9kNOP80gZpkZRKO+9CjodSRfdlu0m3octLGCbArzU0xZ0Ed9ajL0G6jdT28 yjUOOItYHQLjqh/2X3Xn3xWHSl/5C9MOgS9ysLndUdLNNRhsMhnMzPjXdqfHUqhA1mt7 ekKnbiWW64+wNOhzJrY4OmeoVlbV/v4NtaE4fugUq55OTEtcnOPOxSYihixow3W9A3hh POKWO6cBqmSakZEd3nb0RPRCN5OQKx8i4WQi0RSeO1zZPDFF0DwQOX0N2HlGKY7LX1JF AettkAHM2r4zqMC8Bbf37Ia0fHiQqjTyZl7q2Gkl0ioy0cD9Ch/a8xuVamdO0ij6a9/D 8ygg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771634952; x=1772239752; 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=CWr0HuJWiATaTNOSdTyLvXYll6+nwgjSWjXAo4M2MD4=; b=i4gZfQxvLkeiA5qQyqkf/dyCioXDg6OQ23T4XXtoRp9qrpu6SHOr6E13XKXqpTkDLf syIgfWHfdR07QW/B7UAkYS3/PqF7ZcPKtNarcMYPvXDwLWGUUOjOI3v+WergXW1AGwEU C8LoIla7THyJV5m2vsxokBDontgpolhhus+n1hB8tsl8tGmtzksrop/Ek0WyFkwCKquK qEo8/g/qvc6fKxSxIN/Fe+yaxaDoOCMDUisMLm6Ux9W+MfJiaR+1R2pL8ZBjoNCakUki k+RsNkZEOiyYaKAj5d/AWvAFqH0VD0jZVI9tmZukCIplpF8TfMmTRycO3dbz/GCr7DF4 INRA== X-Forwarded-Encrypted: i=1; AJvYcCWxqA/FptTEW6TIlXjxz0r/JyHOWaD5sls43qKjqEPUqXnpQcmT4CngaN+XYR/aEvxffIRJmEyJeWjj4i8=@vger.kernel.org X-Gm-Message-State: AOJu0YyOf/hTLAFel6itNFK1RaDFHeAEGk+UY/S7SoVyUV+yurldTb8s fVMTFAOnoPAzRXlqtUNbyVGf3KB01s+dQp08QeTXr5XeWpxz1AORfRtuMhkuDVf1s6eXDRnx6IV nVvfSXw== X-Received: from pjbnc3.prod.google.com ([2002:a17:90b:37c3:b0:354:c63c:5ed6]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:17c3:b0:354:e86a:3066 with SMTP id 98e67ed59e1d1-358ae6b4f77mr1024277a91.0.1771634952017; Fri, 20 Feb 2026 16:49:12 -0800 (PST) Date: Fri, 20 Feb 2026 16:49:10 -0800 In-Reply-To: <7986057373abcb20585c916804422a13f51d5e55.camel@intel.com> 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: "pbonzini@redhat.com" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Yan Y Zhao , "yosry.ahmed@linux.dev" Content-Type: text/plain; charset="us-ascii" On Sat, Feb 21, 2026, Rick P Edgecombe wrote: > On Wed, 2026-02-18 at 16:22 -0800, Sean Christopherson wrote: > > +static void reset_tdp_unmappable_mask(struct kvm_mmu *mmu) > > +{ > > + int max_addr_bit; > > + > > + switch (mmu->root_role.level) { > > + case PT64_ROOT_5LEVEL: > > + max_addr_bit = 52; > > + break; > > + case PT64_ROOT_4LEVEL: > > + max_addr_bit = 48; > > + break; > > + case PT32E_ROOT_LEVEL: > > + max_addr_bit = 32; > > + break; > > + default: > > + WARN_ONCE(1, "Unhandled root level %u\n", mmu->root_role.level); > > + mmu->unmappable_mask = 0; > > Would it be better to set max_addr_bit to 0 and let rsvd_bits() set it below? > Then the unknown case is safer about rejecting things. No, because speaking from experience, rejecting isn't safer (I had a brain fart and thought legacy shadow paging was also affected). There's no danger to the host (other than the WARN itself), and so safety here is all about the guest. Setting unmappable_mask to -1ull is all but guaranteed to kill the guest, because KVM will reject all faults. Setting unmappable_mask to 0 is only problematic if the guest and/or userspace is misbehaving, and even then, the worst case scenario isn't horrific, all things considered. > > + return; > > + } > > + > > + mmu->unmappable_mask = rsvd_bits(max_addr_bit, 63); > > +} > > + > > Gosh, this forced me to expand my understanding of how the guest and host page > levels get glued together. Hopefully this is not too far off... > > In the patch this function is passed both guest_mmu and root_mmu. So sometimes > it's going to be L1 GPA address, and sometimes (for AMD nested?) it's going to > be an L2 GVA. For the GVA case I don't see how PT32_ROOT_LEVEL can be omitted. > It would hit the warning? No, it's always a GPA. root_mmu translates L1 GPA => L0 GPA and L1 GVA => GPA*; guest_mmu translates L2 GPA => L0 GPA; nested_mmu translates L2 GVA => L2 GPA. Note! The asterisk is that root_mmu is also used when L2 is active if L1 is NOT using TDP, either because KVM isn't using TDP, or because the L1 hypervisor decided not to. In those cases, L2 GPA == L1 GPA from KVM's perspective, because the L1 hypervisor is responsible for shadowing L2 GVA => L1 GPA. And root_mmu can also translate L2 GPA => L0 GPA and L2 GVA => L2 GPA (again, L1 GPA == L2 GPA). > 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. > And that the TDP side uses 4 and 5 specifically, so the PT64_ just happens to > match. No, it's not a coincidence. The "truncation" to 52 bits is an architectural quirk. Long ago, people decided 52 bits of PA were enough for anyone, and so repurposed bits 63:52 for e.g. NX, SUPPRESS_VE, and software-available bits. I.e. conceptually, 5-level paging allows for 57 bits of addressing, but EPT and NPT and NPT define bits 63:52 to be other things. > So I'd think this needs a version for GVA and one for GPA. No, see the last paragraph in the changelog. Side topic, if you have _any_ idea for better names than guest_mmu vs. nested_mmu, speak up. This is like the fifth? time I've had a discussion about how awful those names are, but we've yet to come up with names that suck less.