All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Bjoern Doebel <doebel@amazon.de>
Cc: stable@vger.kernel.org, pbonzini@redhat.com, kvm@vger.kernel.org,
	 Kevin Cheng <chengkev@google.com>
Subject: Re: [PATCH 6.18.y 3/3] KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits
Date: Mon, 2 Nov 2026 09:32:46 -0800	[thread overview]
Message-ID: <aujJPohZEMZMdWFW@google.com> (raw)
In-Reply-To: <20261030103643.573356-4-doebel@amazon.de>

On Fri, Oct 30, 2026, Bjoern Doebel wrote:
> From: Kevin Cheng <chengkev@google.com>
> 
> [ Upstream commit 96b067b59ad9ccede585fcadab27543188353bff ]
> 
> When injecting an EPT Violation into L2 in response to a fault detected
> while emulating an L2 GVA access, synthesize the GVA_IS_VALID and
> GVA_TRANSLATED bits using information provided by the walker, instead of
> pulling the bits from vmcs02.EXIT_QUALIFICATION.  The information in
> vmcs02.EXIT_QUALIFICATION is valid/correct if and only if the fault being
> injected into L1 is the direct result of an EPT Violation VM-Exit from L2.
> 
> E.g. if KVM is emulating an I/O instruction and the memory operand's
> translation through L1's EPT fails, using vmcs02.EXIT_QUALIFICATION is
> wrong as the semantics for EXIT_QUALIFICATION would be for an I/O exit,
> not an EPT Violation exit.
> 
> Opportunistically clean up the formatting for creating the mask of bits
> to pull from vmcs02.EXIT_QUALIFICATION.
> 
> Signed-off-by: Kevin Cheng <chengkev@google.com>
> [sean: use plumbed in @access bits, massage changelog]
> Link: https://patch.msgid.link/20260522232701.3671446-5-seanjc@google.com
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> [doebel: no advanced EPT vmexit info here, so the mask keeps only the two
> GVA bits; set GVA_TRANSLATED via !(access & PFERR_GUEST_PAGE_MASK)]

...

> @@ -509,6 +509,21 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
>  		if (fetch_fault)
>  			walker->fault.exit_qualification |= EPT_VIOLATION_ACC_INSTR;
>  
> +		/*
> +		 * KVM doesn't emulate features that access GPAs directly, e.g.
> +		 * Intel Processor Trace.  Assume the GVA is always valid; when
> +		 * propagating faults from hardware, KVM will discard this info
> +		 * and use the EXIT_QUALIFICATION bits from the VMCS.
> +		 */
> +		walker->fault.exit_qualification |= EPT_VIOLATION_GVA_IS_VALID;
> +
> +		/*
> +		 * Accesses to guest paging structures are not the translation of
> +		 * a guest linear address, i.e. GVA_TRANSLATED must be left clear.
> +		 */
> +		if (!(access & PFERR_GUEST_PAGE_MASK))
> +			walker->fault.exit_qualification |= EPT_VIOLATION_GVA_TRANSLATED;

Yeesh, I was going to say I'd prefer to keep the original:

		/*
		 * Accesses to guest paging structures are either "reads" or
		 * "read+write" accesses, so consider them the latter if write_fault
		 * is true.
		 */
		if (access & PFERR_GUEST_PAGE_MASK)
			walker->fault.exit_qualification |= EPT_VIOLATION_ACC_READ;
		else
			walker->fault.exit_qualification |= EPT_VIOLATION_GVA_TRANSLATED;

but I don't really want to decipher whether or not that's needed and/or correct
without upstream commit a8827c1961462 ("KVM: x86/mmu: introduce ACC_READ_MASK").
So yeah, this seems like the way to go.

  reply	other threads:[~2026-11-02 17:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 10:36 [PATCH 6.18.y 0/3] Backport nested EPT violation GVA bit fix Bjoern Doebel
2026-10-30 10:36 ` [PATCH 6.18.y 1/3] KVM: x86/mmu: pass PFERR_GUEST_PAGE/FINAL_MASK to kvm_translate_gpa Bjoern Doebel
2026-10-30 10:36 ` [PATCH 6.18.y 2/3] KVM: x86: Tell ->inject_page_fault() whether or a fault came from hardware Bjoern Doebel
2026-10-30 10:36 ` [PATCH 6.18.y 3/3] KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits Bjoern Doebel
2026-11-02 17:32   ` Sean Christopherson [this message]
2026-10-30 20:54 ` [PATCH 6.18.y 0/3] Backport nested EPT violation GVA bit fix Sasha Levin
2026-10-30 21:12   ` Sean Christopherson
2026-11-02 17:32     ` Sean Christopherson
2026-11-03 14:52 ` Sasha Levin

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=aujJPohZEMZMdWFW@google.com \
    --to=seanjc@google.com \
    --cc=chengkev@google.com \
    --cc=doebel@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    /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.