All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jon Kohler <jon@nutanix.com>
Cc: Nikolay Borisov <nik.borisov@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] KVM: nVMX: Decouple EPT RWX bits from EPT Violation protection bits
Date: Thu, 27 Feb 2025 19:34:21 +0000	[thread overview]
Message-ID: <Z8C-PRStaoikVlGx@google.com> (raw)
In-Reply-To: <88E181D6-323E-4352-8E4C-7B7191707611@nutanix.com>

On Thu, Feb 27, 2025, Jon Kohler wrote:
> > On Feb 27, 2025, at 1:52 AM, Nikolay Borisov <nik.borisov@suse.com> wrote:
> > 
> > !-------------------------------------------------------------------|
> > CAUTION: External Email

Noted.  :-D

> > |-------------------------------------------------------------------!
> > 
> > On 27.02.25 г. 2:07 ч., Sean Christopherson wrote:
> >> Define independent macros for the RWX protection bits that are enumerated
> >> via EXIT_QUALIFICATION for EPT Violations, and tie them to the RWX bits in
> >> EPT entries via compile-time asserts.  Piggybacking the EPTE defines works
> >> for now, but it creates holes in the EPT_VIOLATION_xxx macros and will
> >> cause headaches if/when KVM emulates Mode-Based Execution (MBEC), or any
> >> other features that introduces additional protection information.
> >> Opportunistically rename EPT_VIOLATION_RWX_MASK to EPT_VIOLATION_PROT_MASK
> >> so that it doesn't become stale if/when MBEC support is added.
> >> No functional change intended.
> >> Cc: Jon Kohler <jon@nutanix.com>
> >> Cc: Nikolay Borisov <nik.borisov@suse.com>
> >> Signed-off-by: Sean Christopherson <seanjc@google.com>
> > 
> > Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> 
> LGTM, but any chance we could hold this until I get the MBEC RFC out? 

No?  It's definitely landing before the MBEC support, and IOM it works quite nicely
with the MBEC support (my diff at the bottom).  I don't see any reason to delay
or change this cleanup.

> My apologies on the delay, I caught a terrible chest cold after we met about
> it, followed by a secondary case of strep!

Ow.  Don't rush on behalf of upstream, KVM has lived without MBEC for a long time,
it's not going anywhere.o

---
 arch/x86/include/asm/vmx.h     | 4 +++-
 arch/x86/kvm/mmu/paging_tmpl.h | 9 +++++++--
 arch/x86/kvm/vmx/vmx.c         | 7 +++++++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index d7ab0ad63be6..61e31e915e46 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -587,9 +587,11 @@ enum vm_entry_failure_code {
 #define EPT_VIOLATION_PROT_READ		BIT(3)
 #define EPT_VIOLATION_PROT_WRITE	BIT(4)
 #define EPT_VIOLATION_PROT_EXEC		BIT(5)
+#define EPT_VIOLATION_PROT_USER_EXEC	BIT(6)
 #define EPT_VIOLATION_PROT_MASK		(EPT_VIOLATION_PROT_READ  | \
 					 EPT_VIOLATION_PROT_WRITE | \
-					 EPT_VIOLATION_PROT_EXEC)
+					 EPT_VIOLATION_PROT_EXEC  | \
+					 EPT_VIOLATION_PROT_USER_EXEC)
 #define EPT_VIOLATION_GVA_IS_VALID	BIT(7)
 #define EPT_VIOLATION_GVA_TRANSLATED	BIT(8)
 
diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 68e323568e95..ede8207bf4d7 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -181,8 +181,9 @@ static inline unsigned FNAME(gpte_access)(u64 gpte)
 	unsigned access;
 #if PTTYPE == PTTYPE_EPT
 	access = ((gpte & VMX_EPT_WRITABLE_MASK) ? ACC_WRITE_MASK : 0) |
-		((gpte & VMX_EPT_EXECUTABLE_MASK) ? ACC_EXEC_MASK : 0) |
-		((gpte & VMX_EPT_READABLE_MASK) ? ACC_USER_MASK : 0);
+		 ((gpte & VMX_EPT_EXECUTABLE_MASK) ? ACC_EXEC_MASK : 0) |
+		 ((gpte & VMX_EPT_USER_EXECUTABLE_MASK) ? ACC_USER_EXEC_MASK : 0) |
+		 ((gpte & VMX_EPT_READABLE_MASK) ? ACC_USER_MASK : 0);
 #else
 	BUILD_BUG_ON(ACC_EXEC_MASK != PT_PRESENT_MASK);
 	BUILD_BUG_ON(ACC_EXEC_MASK != 1);
@@ -511,6 +512,10 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
 		 * ACC_*_MASK flags!
 		 */
 		walker->fault.exit_qualification |= EPT_VIOLATION_RWX_TO_PROT(pte_access);
+		/* This is also wrong.*/
+		if (vcpu->arch.pt_guest_exec_control &&
+		    (pte_access & VMX_EPT_USER_EXECUTABLE_MASK))
+			walker->fault.exit_qualification |= EPT_VIOLATION_PROT_USER_EXEC;
 	}
 #endif
 	walker->fault.address = addr;
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 0db64f4adf2a..4684647ef063 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -5806,6 +5806,13 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
 
 	exit_qualification = vmx_get_exit_qual(vcpu);
 
+	/*
+	 * The USER_EXEC flag is undefined if MBEC is disabled.
+	 * Note, this is wrong, MBEC should be a property of the MMU.
+	 */
+	if (!vcpu->arch.pt_guest_exec_control)
+		exit_qualification &= ~EPT_VIOLATION_PROT_USER_EXEC;
+
 	/*
 	 * EPT violation happened while executing iret from NMI,
 	 * "blocked by NMI" bit has to be set before next VM entry.

base-commit: 67983df09fc3f96d0d6107fe1a99d29460bab481
-- 


  reply	other threads:[~2025-02-27 19:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27  0:07 [PATCH v2 0/2] KVM: VMX: Clean up EPT_VIOLATIONS_xxx #defines Sean Christopherson
2025-02-27  0:07 ` [PATCH v2 1/2] KVM: VMX: Remove EPT_VIOLATIONS_ACC_*_BIT defines Sean Christopherson
2025-02-27  0:07 ` [PATCH v2 2/2] KVM: nVMX: Decouple EPT RWX bits from EPT Violation protection bits Sean Christopherson
2025-02-27  6:52   ` Nikolay Borisov
2025-02-27 19:05     ` Jon Kohler
2025-02-27 19:34       ` Sean Christopherson [this message]
2025-02-27 19:40         ` Jon Kohler
2025-02-27 19:51           ` Sean Christopherson
2025-02-28 23:40 ` [PATCH v2 0/2] KVM: VMX: Clean up EPT_VIOLATIONS_xxx #defines Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z8C-PRStaoikVlGx@google.com \
    --to=seanjc@google.com \
    --cc=jon@nutanix.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.