All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Rick P Edgecombe <rick.p.edgecombe@intel.com>,
	Yilun Xu <yilun.xu@intel.com>,
	 Elena Reshetova <elena.reshetova@intel.com>,
	Binbin Wu <binbin.wu@intel.com>,
	 Vishal Annapurve <vannapurve@google.com>,
	"kas@kernel.org" <kas@kernel.org>,
	 "pbonzini@redhat.com" <pbonzini@redhat.com>,
	Peter Fang <peter.fang@intel.com>,
	 "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: TDG quote analysis
Date: Mon, 21 Sep 2026 16:46:29 -0700	[thread overview]
Message-ID: <arHB1SACk4Z9kJq3@google.com> (raw)
In-Reply-To: <2df88806-4583-4bf8-b699-43eb6217399b@intel.com>

On Mon, Sep 21, 2026, Dave Hansen wrote:
> On 9/21/26 16:19, Sean Christopherson wrote:
> > On Mon, Sep 21, 2026, Dave Hansen wrote:
> >> On 9/18/26 14:32, Sean Christopherson wrote:
> >>> By creating these system-wide thread pools, TDX has effectively created a bizarre
> >>> M:N scheduling problem, *and* introduced a completely avoidable noisy-neighbor
> >>> problem.
> >> To be honest, I just want to chop all of the complexity out of this.
> >>
> >> I want to assume that the TDX module can do one quote at a time. If that
> >> quote takes too long, software kills it and lets the next guy do a quote.
> >>
> >> I don't even want to know that the TDX module *can* have 1 or 10 or 100
> >> quoting threads. I just want one which I can make sane rules around
> >> because 1 is *FINE*.
> > I'm not remotely convinced one per system is fine.  I'm all for one per VM, but
> > I'm pretty sure the SEAMCALL alone will have a measurable performance impact,
> > especially when factoring in that it will require a VMCS shootdown to do VMCLEAR
> > on the previous pCPU.  Mix in a few (tens of?) thousand more cycles, and any use
> > case that's trying to boot a decent number of TDX guests in parallel will be sad.
> 
> Sad, but way less sad than the folks who decided to offload their
> quoting to an Arduino attached over a fancy serial port. ;)
> 
> I do think we can _start_ with one. One needs no ABI and no policy bike
> shedding. If my crystal ball is right, we can stop there. If yours is
> right, then we can go build the stuff we need to make it scale.

My preference *was* to not have to find out, because those types of scaling issues
tend to lead to a mad scramble and angry customers.  But...

> Oh, and folks can _theoretically_ do one quoting instance per VM. But I
> think the overhead per quoting instance is in 100MB ballpark. 

MB with an M!?!?!  What!?!?   How?  I was assuming my 32KiB threshold was fairly
conservative; what is the TDX Module doing that it needs 100MiB?  That's insane.
That's literally 3x the footprint of some full-blown VMMs.

If it really is 100MiB per instance, that definitely changes things.  I'm much
more willing to roll the dice and hope quoting is never a bottleneck in practice
if it means saving 100MiB per VM.  Yeesh.

> So a bit rotund to be per-TD in practice.

LOL, yeah, a "bit".

  reply	other threads:[~2026-09-21 23:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  0:48 TDG quote analysis Edgecombe, Rick P
2026-09-16 18:00 ` Sean Christopherson
2026-09-16 18:49   ` Edgecombe, Rick P
2026-09-16 19:27     ` Sean Christopherson
2026-09-16 22:31       ` Edgecombe, Rick P
2026-09-16 23:00         ` Peter Fang
2026-09-16 23:57           ` Sean Christopherson
2026-09-17  0:56             ` Edgecombe, Rick P
2026-09-17 13:37               ` Sean Christopherson
2026-09-17 18:12                 ` Edgecombe, Rick P
2026-09-17 19:57                   ` Sean Christopherson
2026-09-17 21:32                     ` Edgecombe, Rick P
2026-09-18  0:04                       ` Sean Christopherson
2026-09-18  2:39                         ` Edgecombe, Rick P
2026-09-18 13:13                           ` Sean Christopherson
2026-09-18 18:12                             ` Edgecombe, Rick P
2026-09-18 21:32                               ` Sean Christopherson
2026-09-21 23:00                                 ` Peter Fang
2026-09-21 23:06                                   ` Dave Hansen
2026-09-23  4:09                                     ` Vishal Annapurve
2026-09-24  0:03                                       ` Vishal Annapurve
2026-09-24  0:18                                         ` Sean Christopherson
2026-09-24  0:44                                           ` Edgecombe, Rick P
2026-09-24 16:28                                             ` Sean Christopherson
2026-09-21 23:04                                 ` Dave Hansen
2026-09-21 23:19                                   ` Sean Christopherson
2026-09-21 23:36                                     ` Dave Hansen
2026-09-21 23:46                                       ` Sean Christopherson [this message]
2026-09-22  0:03                                         ` Dave Hansen
2026-09-22  6:48                                           ` Reshetova, Elena
2026-09-22 17:07                                             ` Edgecombe, Rick P
2026-09-23  8:50                                               ` Reshetova, Elena
2026-09-23 22:50                                                 ` Peter Fang

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=arHB1SACk4Z9kJq3@google.com \
    --to=seanjc@google.com \
    --cc=binbin.wu@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=elena.reshetova@intel.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.fang@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=vannapurve@google.com \
    --cc=yilun.xu@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.