From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
Vishal Annapurve <vannapurve@google.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
Adrian Hunter <adrian.hunter@intel.com>,
"maz@kernel.org" <maz@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/5] KVM: TDX: Exit with MEMORY_FAULT on unexpected pending S-EPT Violation
Date: Tue, 29 Jul 2025 16:08:30 -0700 [thread overview]
Message-ID: <aIlUbpQlYqaSO6wr@google.com> (raw)
In-Reply-To: <e45806c6ae3eef2c707f0c3886cb71015341741b.camel@intel.com>
On Tue, Jul 29, 2025, Rick P Edgecombe wrote:
> On Tue, 2025-07-29 at 15:54 -0700, Sean Christopherson wrote:
> > > The vm_dead was added because mirror EPT will KVM_BUG_ON() if there is an
> > > attempt to set the mirror EPT entry when it is already present. And the
> > > unaccepted memory access will trigger an EPT violation for a mirror PTE
> > > that is already set. I think this is a better solution irrespective of
> > > the vm_dead changes.
> >
> > In that case, this change will expose KVM to the KVM_BUG_ON(), because nothing
> > prevents userspace from re-running the vCPU.
>
> If userspace runs the vCPU again then an EPT violation gets triggered again,
> which again gets kicked out to userspace. The new check will prevent it from
> getting into the fault handler, right?
Yes? But I'm confused about why you mentioned vm_dead, and why you're calling
this a "new check". This effectively does two things: drops kvm_vm_dead() and
switches from EOI => EFAULT. _If_ setting vm_dead was necessary, then we have a
problem.
I assume by "The vm_dead was added" you really mean "forcing an exit to userspace",
and that kvm_vm_dead()+EIO was a somewhat arbitrary way of forcing an exit?
> > Which KVM_BUG_ON() exactly gets hit?
>
> Should be:
>
> static int __must_check set_external_spte_present(struct kvm *kvm, tdp_ptep_t
> sptep,
> gfn_t gfn, u64 old_spte,
> u64 new_spte, int level)
> {
> bool was_present = is_shadow_present_pte(old_spte);
> bool is_present = is_shadow_present_pte(new_spte);
> bool is_leaf = is_present && is_last_spte(new_spte, level);
> kvm_pfn_t new_pfn = spte_to_pfn(new_spte);
> int ret = 0;
>
> KVM_BUG_ON(was_present, kvm);
Yeah, I don't see how that can be reach in this scenario.
next prev parent reply other threads:[~2025-07-29 23:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 19:33 [PATCH 0/5] KVM: Drop vm_dead, pivot on vm_bugged for -EIO Sean Christopherson
2025-07-29 19:33 ` [PATCH 1/5] KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests Sean Christopherson
2025-07-29 19:33 ` [PATCH 2/5] KVM: TDX: Exit with MEMORY_FAULT on unexpected pending S-EPT Violation Sean Christopherson
2025-07-29 22:27 ` Edgecombe, Rick P
2025-07-29 22:54 ` Sean Christopherson
2025-07-29 22:58 ` Edgecombe, Rick P
2025-07-29 23:08 ` Sean Christopherson [this message]
2025-07-29 23:13 ` Edgecombe, Rick P
2025-07-30 5:45 ` Yan Zhao
2025-07-30 5:55 ` Yan Zhao
2025-07-30 12:59 ` Edgecombe, Rick P
2025-07-30 2:07 ` Xiaoyao Li
2025-07-30 6:04 ` Yan Zhao
2025-07-29 19:33 ` [PATCH 3/5] KVM: Reject ioctls only if the VM is bugged, not simply marked dead Sean Christopherson
2025-07-30 1:20 ` Chao Gao
2025-07-29 19:33 ` [PATCH 4/5] KVM: selftests: Use for-loop to handle all successful SEV migrations Sean Christopherson
2025-07-29 19:33 ` [PATCH 5/5] KVM: TDX: Add sub-ioctl KVM_TDX_TERMINATE_VM Sean Christopherson
2025-08-01 13:56 ` Adrian Hunter
2025-08-01 16:44 ` Sean Christopherson
2025-08-03 17:41 ` Adrian Hunter
2025-08-06 6:06 ` Chao Gao
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=aIlUbpQlYqaSO6wr@google.com \
--to=seanjc@google.com \
--cc=adrian.hunter@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=nik.borisov@suse.com \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=vannapurve@google.com \
--cc=xiaoyao.li@intel.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.