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: <08cef2fec1426330d32ada6b2de662d8837f2fb1.camel@intel.com>
Date: Fri, 11 Jul 2025 22:31:01 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>
CC: "Gao, Chao" <chao.gao@...el.com>, "Huang, Kai" <kai.huang@...el.com>,
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>, "Hunter, Adrian"
	<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>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "Zhao, Yan Y" <yan.y.zhao@...el.com>
Subject: Re: [PATCH V4 0/1] KVM: TDX: Decrease TDX VM shutdown time

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.

The less interfaces the better I say, so KVM_CAP_TDX_TERMINATE_VM seems better.
Xiaoyao, is this something QEMU needs? Or more of a completeness kind of thing?