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.
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox