From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Kevin Cheng <chengkev@google.com>
Subject: Re: [PATCH v4 3/5] KVM: SVM: Fix nested NPF injection of PFERR_GUEST_{PAGE,FINAL}_MASK bits
Date: Wed, 27 May 2026 11:14:13 -0700 [thread overview]
Message-ID: <ahc0dRxHXMqOK-D5@google.com> (raw)
In-Reply-To: <CAO9r8zMGwUszi1xvi4WU1M85ZZWTDTfbQacjBfNDw8+QS4WDOw@mail.gmail.com>
On Tue, May 26, 2026, Yosry Ahmed wrote:
> > > > + vmcb->control.exit_code = SVM_EXIT_NPF;
> > > > + vmcb->control.exit_info_1 = fault_stage |
> > > > + (fault->error_code & ~PFERR_GUEST_FAULT_STAGE_MASK);
> > >
> > > Do we need to do this in the common path?
> >
> > What do you mean by "this"? Pulling flags from fault->error_code?
>
> Yes, sorry if that wasn't clear.
>
> >
> > > If from_hardware=true, can the fault injected by KVM have different flags
> > > from the one produced by hardware?
> >
> > Flags, yes. fault_stage, no.
>
> Right, I meant the flags.
>
> >
> > > I guess the answer is yes, (e.g. if KVM is doing write-protection?). Might be
> > > worth a comment.
> >
> > Or if L1 has modified its TDP PTEs in memory, but hasn't yet flushed TLBs. In
> > that case, KVM's software walker can see the updated PTEs, while hardware may
> > have seen something else.
>
> Makes sense. A comment would be helpful for laymans like myself.
I elected to not add a comment for now, because I'm not 100% confident the nSVM
code is correct, and so didn't want to stealth in a comment that wasn't correct
either. It's certainly much better than it was, but especially with GMET in play,
I need to stare more to convince myself it handles all the edge cases correctly.
next prev parent reply other threads:[~2026-05-27 18:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 23:26 [PATCH v4 0/5] KVM: X86: Fix nested TDP error code info Sean Christopherson
2026-05-22 23:26 ` [PATCH v4 1/5] KVM: x86: Widen x86_exception's error_code to 64 bits Sean Christopherson
2026-05-22 23:26 ` [PATCH v4 2/5] KVM: x86: Tell ->inject_page_fault() whether or a fault came from hardware Sean Christopherson
2026-05-26 18:18 ` Yosry Ahmed
2026-05-26 18:48 ` Sean Christopherson
2026-05-26 18:52 ` Yosry Ahmed
2026-05-27 18:11 ` Sean Christopherson
2026-05-22 23:26 ` [PATCH v4 3/5] KVM: SVM: Fix nested NPF injection of PFERR_GUEST_{PAGE,FINAL}_MASK bits Sean Christopherson
2026-05-26 18:31 ` Yosry Ahmed
2026-05-26 18:44 ` Sean Christopherson
2026-05-26 18:50 ` Yosry Ahmed
2026-05-27 18:14 ` Sean Christopherson [this message]
2026-05-22 23:27 ` [PATCH v4 4/5] KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits Sean Christopherson
2026-05-22 23:27 ` [PATCH v4 5/5] KVM: selftests: Add nested page fault injection test Sean Christopherson
2026-05-27 18:10 ` [PATCH v4 0/5] KVM: X86: Fix nested TDP error code info 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=ahc0dRxHXMqOK-D5@google.com \
--to=seanjc@google.com \
--cc=chengkev@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yosry@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.