All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	Xiaoyao Li <xiaoyao.li@intel.com>,
	 "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Dan J Williams <dan.j.williams@intel.com>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 Rick P Edgecombe <rick.p.edgecombe@intel.com>,
	 "binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>
Subject: Re: [PATCH v2 1/2] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL
Date: Fri, 17 Oct 2025 06:00:06 -0700	[thread overview]
Message-ID: <aPI91kOhPAK_Bkla@google.com> (raw)
In-Reply-To: <2d00cefad4a5316357e76db7292e8d7ac2793eb1.camel@intel.com>

On Fri, Oct 17, 2025, Kai Huang wrote:
> 
> > --- a/arch/x86/kvm/vmx/nested.c
> > +++ b/arch/x86/kvm/vmx/nested.c
> > @@ -6728,6 +6728,14 @@ static bool nested_vmx_l1_wants_exit(struct kvm_vcpu *vcpu,
> >  	case EXIT_REASON_NOTIFY:
> >  		/* Notify VM exit is not exposed to L1 */
> >  		return false;
> > +	case EXIT_REASON_SEAMCALL:
> > +	case EXIT_REASON_TDCALL:
> > +		/*
> > +		 * SEAMCALL and TDCALL unconditionally VM-Exit, but aren't
> > +		 * virtualized by KVM for L1 hypervisors, i.e. L1 should
> > +		 * never want or expect such an exit.
> > +		 */
> > +		return false;
> 
> Sorry for commenting late.
> 
> I think from emulating hardware behaviour's perspective, if L1 doesn't
> support TDX (obviously true), SEAMCALL/TDCALL in L2 should cause VMEXIT to
> L1.  In other words, L1 is expecting a VMEXIT in such case.

No, because from L1's perspective, the opcodes map to undefined instructions and
thus should #UD in L2.  There's no super explicit enumeration, but IMO it's fair
to say that for L1 to think the instructions exists, it would need to observe
IA32_SEAMRR_PHYS_{BASE,MASK} for SEAMCALL, and MSR_IA32_MKTME_KEYID_PARTITIONING
as well for TDCALL.  KVM doesn't emulate any of those instructions, and so L1
should never expect SEAMCALL or TDCALL to do anything other than #UD.

> Whether L1 can handle such VMEXIT is another story -- it may inject a #UD to
> L2 or may not (similar to the current upstream KVM), but it is L1's
> responsibility.
> 
> So I think while this patch certainly honors the correct behaviour for L2,
> it doesn't honor for L1.  But I think ultimately L1 should be the one who
> is responsible for emulating hardware behaviour for L2.
> 
> E.g., assuming we have a KVM selftest in L1 to test SEAMCALL/TDCALL in
> normal VMX L2.  L1 should be able to catch it's own bug when such VMEXIT
> isn't handled correctly.  But with this patch, L1 will never be able to
> catch this IIUC.

  reply	other threads:[~2025-10-17 13:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16 18:21 [PATCH v2 0/2] KVM: VMX: Handle SEAMCALL or TDCALL VM-Exits Sean Christopherson
2025-10-16 18:21 ` [PATCH v2 1/2] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL Sean Christopherson
2025-10-17  2:53   ` Xiaoyao Li
2025-10-17  5:27   ` Binbin Wu
2025-10-17 10:53   ` Huang, Kai
2025-10-17 13:00     ` Sean Christopherson [this message]
2025-10-17 20:34       ` Huang, Kai
2025-10-17 20:34   ` Huang, Kai
2025-10-16 18:21 ` [PATCH v2 2/2] KVM: TDX: WARN if a SEAMCALL VM-Exit makes its way out to KVM Sean Christopherson
2025-10-17  2:56   ` Xiaoyao Li
2025-10-17  5:29   ` Binbin Wu
2025-10-17 10:40   ` Huang, Kai
2025-10-17 17:25     ` Sean Christopherson
2025-10-17 20:58       ` Huang, Kai
2025-10-17 21:11         ` Huang, Kai
2025-10-20  6:10         ` Xiaoyao Li
2025-10-20 15:03           ` Sean Christopherson
2025-11-04 17:45 ` [PATCH v2 0/2] KVM: VMX: Handle SEAMCALL or TDCALL VM-Exits 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=aPI91kOhPAK_Bkla@google.com \
    --to=seanjc@google.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.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.