linux-kernel - Re: [PATCH V4 0/1] KVM: TDX: Decrease TDX VM shutdown time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aHGWI5_BsFg1JJCx@google.com>
Date: Fri, 11 Jul 2025 15:54:27 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Xiaoyao Li <xiaoyao.li@...el.com>, Chao Gao <chao.gao@...el.com>, 
	Kai Huang <kai.huang@...el.com>, 
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, Reinette Chatre <reinette.chatre@...el.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, Adrian Hunter <adrian.hunter@...el.com>, 
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"tony.lindgren@...ux.intel.com" <tony.lindgren@...ux.intel.com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Yan Y Zhao <yan.y.zhao@...el.com>
Subject: Re: [PATCH V4 0/1] KVM: TDX: Decrease TDX VM shutdown time

On Fri, Jul 11, 2025, Rick P Edgecombe wrote:
> On Fri, 2025-07-11 at 07:19 -0700, Sean Christopherson wrote:
> > > > Bugger, you're right.  It's sitting at the top of 'kvm-x86 vmx', so it
> > > > should be
> > > > easy enough to tack on a capability.
> > > > 
> > > > This?
> > > 
> > > I'm wondering if we need a TDX centralized enumeration interface, e.g., new
> > > field in struct kvm_tdx_capabilities. I believe there will be more and more
> > > TDX new features, and assigning each a KVM_CAP seems wasteful.
> > 
> > Oh, yeah, that's a much better idea.  In addition to not polluting KVM_CAP,
> 
> How do you guys see it as wasteful? The highest cap is currently 242. For 32 bit
> KVM that leaves 2147483405 caps. If we create an interface we grow some code and
> docs, and get 64 additional ones for TDX only.

It bleeds TDX details into arch neutral code.

> The less interfaces the better I say, so KVM_CAP_TDX_TERMINATE_VM seems better.

But we already have KVM_TDX_CAPABILITIES.  This isn't really a new interface, it's
a new field in a pre-existing interface.

> Xiaoyao, is this something QEMU needs? Or more of a completeness kind of thing?

Required by VMMs.  KVM always needs to be able enumerate its new features.  We
absolutely do not want userspace making guesses based on e.g. kernel version.