From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E82C3E8C6F for ; Tue, 2 Jun 2026 14:35:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780410956; cv=none; b=T/L7mNETCM6I1Fyo2YyG1E3FrwbdC74UfaL3LflkeZ1ADbi5JuiROEPryKkb7wiM0vvmftK33dIJP6Ikx0+QHR2FRDbMIoMKezqons4WU/ffT1zCUJOVhnLWftqG08OXLzrYlNobSucE7fSTAdjt8pG0Xc7aEZif/bh7IjCM/tY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780410956; c=relaxed/simple; bh=ifhBtlQccMTOl1OtyDUz4oMtXUzGOAAtYYQc1i4voz4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=DBCQ2Sa0XI6SVmvuPMpVdGj7ijkeqfw+/uIrb+Az/kAfzKDo5UB7B3am0MOdsYeDrFutC2VM2HH0eQE86M8YmAH4v4o/QI9LBJa2noPq5EFtno1i/81cZxok59U5CGtPUc1qZ3+TnU9PgP7WCHggUOyxNtcN/8C/Qi/aMiL9IEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=bqXbdZdS; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=jwEPqrq7; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="bqXbdZdS"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="jwEPqrq7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780410954; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ifhBtlQccMTOl1OtyDUz4oMtXUzGOAAtYYQc1i4voz4=; b=bqXbdZdSL4Yf/bjoRij1tv/+ivQA2oiA12ZJ0lgzL5tZVz1C3DY542u+l+SejxOr+0ByHG Lm25Tez9pAUbt0+OIAW2ZKZ1/QhwS79yCRsOlhCooZkpY+Wae4M9GiY4oBs9ILOza3TQvS 4BuNkiVPVmC6fSdsZQlZN2RmAtOGUyg= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-576-6vy8ySQUNS-lhbRJ9GC6HA-1; Tue, 02 Jun 2026 10:35:53 -0400 X-MC-Unique: 6vy8ySQUNS-lhbRJ9GC6HA-1 X-Mimecast-MFC-AGG-ID: 6vy8ySQUNS-lhbRJ9GC6HA_1780410952 Received: by mail-ua1-f69.google.com with SMTP id a1e0cc1a2514c-963d7670e38so2371841241.1 for ; Tue, 02 Jun 2026 07:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780410952; x=1781015752; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=ifhBtlQccMTOl1OtyDUz4oMtXUzGOAAtYYQc1i4voz4=; b=jwEPqrq7ebA3XK1yTkasEJP7koBEjrFLttNETZWkpXMvXMim6wL5GlT/Mc9sT6Y7DU n1ohzYHL+M1c67Bu9x4THhVsMTL2IROX1nm67g8alAIGITsEEUXQ0N/E5xoxanOAYBVR Eq2n+vaqycr3DsTkUclJc30zfmSU22HglstKWXer2kWAftTH6mOwT0JeknKBMHGsx7oz uuGqrLGSSx15UyxFVaeD9AU/WHHbtEpGHD/J9tS5QUBl3B29xiNhU3vIKI3nsn86fZit zWMqOEdhGh1rnRT9ck/Sdu6QAUYJvmOBDuEiS1uWuTpBnPtYaApL4IPwMFeBDLjHIqHv FB/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780410952; x=1781015752; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ifhBtlQccMTOl1OtyDUz4oMtXUzGOAAtYYQc1i4voz4=; b=E/V6xxncP08lWat0y8CELJmaY77f5IpAU5aRqMNUMkzS2RNS8Q/K0ndfgyKgiQpbmf nm1YTiXiRMlT21j3obcWPBtunsLtVUQUDu6ytwE8QicJfhlHL05q95rmcLdig5sPHAtE jMLakR/UHY+YC9o7uXl8v7WPAkHNtNANektCakfKo2BR37fYPmkM6vdYDzod4LfQVm+E 8kXpoDEyG86myXPIZG7VIYaSlhCNMwpWPdbKAk2nNap7uE0n0iS0vUhdofZuQi21krdB cq0WK2hTA+kIYFirYz13WevrxmtnfVK7bJzP0R9u2GfkZkqUTOxNW6Hi62OIT7+7QcQC uTdA== X-Forwarded-Encrypted: i=1; AFNElJ+VqMXccNXqB6ey6DyTCMgfS5+3j2sAuNXY4C4JJ1UkBGtgpf9f9P/lI5o1Z5JsfoAsaahihIirM+a3qxc=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+b0vRyPbLdyoNzlaOQw676j9Bc1XjBu61KbcamaY0XRs63KoK R6TI8TDBOfZA+swXdL8I4lfhaVzNyyV9QkAgwUscem2vcxu9av/gpz0dpDP+GICmAukRsyEUo2l 4dAXVhNE9pUGecpQ12Ha5aaZN0UmiRhOXgUiHWL1RFbwgxFIQhHnzVyxgblWvAFDLkxEPevIPjg == X-Gm-Gg: Acq92OE52/67P5nvkvGSTJqGbgN4uPoUEPGxLBpe5sc9hDghKTccNLxTPVaFmUMTPUb 8jXWtoswdp4s5kIks9Nt5wxL3BtnSeBE5tYKc5P3fxFOjcvduXYBUNZnFDgUZYgMV5/H4HwsXHB ATAXCAqX7VNBaCrUeSADRsoAztR34GePTAcpEYiDIJEe3Un5Utkb0V6dG/LboN1zhwsN8JD7X8/ WD0EO5jiijAe8nYaWx9CswKogWmOYfNEYAVTa3+Cr8z7oXfAEN6q4ikYtra223art15M+jAhitU cmJe+ZEVKFfpBIvaeDDSk+PCgC7ixK75/yn6Vve41aI00oHZgeo9nykfDxHBcvGjo2FuaDsLL4C /QWV+dPKM5cV4bBnr2s5NW5VZB1iPpXiZuEdawV8= X-Received: by 2002:a67:e9d4:0:b0:6cd:23a8:3a31 with SMTP id ada2fe7eead31-6e170691d7fmr1469878137.1.1780410952500; Tue, 02 Jun 2026 07:35:52 -0700 (PDT) X-Received: by 2002:ad4:4ead:0:b0:8cc:3546:2625 with SMTP id 6a1803df08f44-8cebf421b3emr57130996d6.9.1780410628709; Tue, 02 Jun 2026 07:30:28 -0700 (PDT) Received: from intellaptop.lan ([2607:fea8:fc01:88aa:f1de:f35:7935:804f]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ccea202609sm120880346d6.36.2026.06.02.07.30.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 07:30:27 -0700 (PDT) Message-ID: Subject: Re: [PATCH 24/28] KVM: x86/mmu: hard code more bits in kvm_init_shadow_npt_mmu From: mlevitsk@redhat.com To: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: d.riley@proxmox.com, jon@nutanix.com Date: Tue, 02 Jun 2026 10:30:26 -0400 In-Reply-To: <20260505195226.563317-25-pbonzini@redhat.com> References: <20260505195226.563317-1-pbonzini@redhat.com> <20260505195226.563317-25-pbonzini@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.4 (3.52.4-2.fc40) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-05-05 at 21:52 +0200, Paolo Bonzini wrote: > The host CR0 does not really reflect onto the NPT format because =20 > hCR0.PG=3D1 must be set and hCR0.WP is ignored.=C2=A0 Carve that in stone= =20 > by removing the cr0 argument from kvm_init_shadow_npt_mmu. =20 > =20 > Pass in WP=3D1 as well; it does not matter for GMET disabled because =20 > PFERR_USER_MASK is always set, but a cleared W bit in the nested page = =20 > tables cannot be overridden in supervisor mode when GMET is enabled, =20 > either.=C2=A0 In fact, since CR0.WP=3D0 is the weird "extra accesses allo= wed" =20 > mode, it is acutally easier think about it being always set. =20 > =20 > Likewise, clear X86_CR4_SMAP to avoid that KVM erroneously faults on =20 > supervisor accesses to an U=3D1 page. Hi! Minor nitpick: This all makes sense but can we also add the same comment to= the code? =20 Commit messages tend to get lost after a while, when new layer of refactori= ng =20 replaces them in git blame. > Signed-off-by: Paolo Bonzini <[[pbonzini@redhat.com](mailto:pbonzini@redh= at.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com))> =20 > --- =20 > =C2=A0arch/x86/kvm/mmu.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 4 ++= -- =20 > =C2=A0arch/x86/kvm/mmu/mmu.c=C2=A0=C2=A0=C2=A0 | 8 ++++---- =20 > =C2=A0arch/x86/kvm/svm/nested.c | 2 +- =20 > =C2=A03 files changed, 7 insertions(+), 7 deletions(-) =20 > =20 > diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h =20 > index e1e3869f568b..1b354e1f2d81 100644 =20 > --- a/arch/x86/kvm/mmu.h =20 > +++ b/arch/x86/kvm/mmu.h =20 > @@ -96,8 +96,8 @@ void kvm_mmu_set_me_spte_mask(u64 me_value, u64 me_mask= ); =20 > =C2=A0void kvm_mmu_set_ept_masks(bool has_ad_bits); =20 > =C2=A0 =20 > =C2=A0void kvm_init_mmu(struct kvm_vcpu *vcpu); =20 > -void kvm_init_shadow_npt_mmu(struct kvm_vcpu *vcpu, unsigned long cr0, = =20 > - =C2=A0=C2=A0=C2=A0=C2=A0 unsigned long cr4, u64 efer, gpa_t nested_cr3)= ; =20 > +void kvm_init_shadow_npt_mmu(struct kvm_vcpu *vcpu, unsigned long cr4, = =20 > + =C2=A0=C2=A0=C2=A0=C2=A0 u64 efer, gpa_t nested_cr3); =20 > =C2=A0void kvm_init_shadow_ept_mmu(struct kvm_vcpu *vcpu, bool execonly, = =20 > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 int huge_page_level, bool accessed_dirty,= =20 > =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 bool mbec, gpa_t new_eptp); =20 > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c =20 > index 912c8e97ef61..5a796ae8c396 100644 =20 > --- a/arch/x86/kvm/mmu/mmu.c =20 > +++ b/arch/x86/kvm/mmu/mmu.c =20 > @@ -5939,13 +5939,13 @@ static void kvm_init_shadow_mmu(struct kvm_vcpu *= vcpu, =20 > =C2=A0 shadow_mmu_init_context(vcpu, context, cpu_role, root_role); =20 > =C2=A0} =20 > =C2=A0 =20 > -void kvm_init_shadow_npt_mmu(struct kvm_vcpu *vcpu, unsigned long cr0, = =20 > - =C2=A0=C2=A0=C2=A0=C2=A0 unsigned long cr4, u64 efer, gpa_t nested_cr3)= =20 > +void kvm_init_shadow_npt_mmu(struct kvm_vcpu *vcpu, unsigned long cr4, = =20 > + =C2=A0=C2=A0=C2=A0=C2=A0 u64 efer, gpa_t nested_cr3) =20 > =C2=A0{ =20 > =C2=A0 struct kvm_mmu *context =3D &vcpu->arch.guest_mmu; =20 > =C2=A0 struct kvm_mmu_role_regs regs =3D { =20 > - .cr0 =3D cr0, =20 > - .cr4 =3D cr4 & ~X86_CR4_PKE, =20 > + .cr0 =3D X86_CR0_PG | X86_CR0_WP, =20 > + .cr4 =3D cr4 & ~(X86_CR4_PKE | X86_CR4_SMAP), Nitpick: If we assume that EFER.NX is always true for NPT, as I suggested i= n the previous patch, =20 we can drop CR4.SMEP from .cr4, which could clarify that =20 NPT doesn't depend on host CR4.SMEP either. What do you think? > =C2=A0 .efer =3D efer, =20 > =C2=A0 }; =20 > =C2=A0 union kvm_cpu_role cpu_role =3D kvm_calc_cpu_role(vcpu, ®s); = =20 > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c =20 > index df232153eb24..a1cffd274000 100644 =20 > --- a/arch/x86/kvm/svm/nested.c =20 > +++ b/arch/x86/kvm/svm/nested.c =20 > @@ -93,7 +93,7 @@ static void nested_svm_init_mmu_context(struct kvm_vcpu= *vcpu) =20 > =C2=A0 * when called via KVM_SET_NESTED_STATE, that state may _not_ match= current =20 > =C2=A0 * vCPU state.=C2=A0 CR0.WP is explicitly ignored, while CR0.PG is = required. =20 > =C2=A0 */ =20 > - kvm_init_shadow_npt_mmu(vcpu, X86_CR0_PG, svm->vmcb01.ptr->save.cr4, = =20 > + kvm_init_shadow_npt_mmu(vcpu, svm->vmcb01.ptr->save.cr4, =20 > =C2=A0 svm->vmcb01.ptr->save.efer, =20 > =C2=A0 svm->nested.ctl.nested_cr3); =20 > =C2=A0 vcpu->arch.mmu->get_guest_pgd=C2=A0=C2=A0=C2=A0=C2=A0 =3D nested_s= vm_get_tdp_cr3; Best regards, =20 Maxim Levitsky