linux-kernel - Re: [PATCH 11/25] KVM: TDX: Report kvm_tdx_caps in KVM_TDX

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: <e08e22e6e87497d23dcf0b2dc4c286c7a8e7d132.camel@intel.com>
Date: Wed, 21 Aug 2024 00:06:14 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "nik.borisov@...e.com" <nik.borisov@...e.com>, "Gao, Chao"
	<chao.gao@...el.com>
CC: "seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai"
	<kai.huang@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tony.lindgren@...ux.intel.com" <tony.lindgren@...ux.intel.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>
Subject: Re: [PATCH 11/25] KVM: TDX: Report kvm_tdx_caps in
 KVM_TDX_CAPABILITIES

On Mon, 2024-08-19 at 13:24 +0300, Nikolay Borisov wrote:
> > I wonder why this patch and patch 9 weren't squashed together. Many changes
> > added by patch 9 are removed here.
> 
> As far as I can see this patch depends on the code in patch 10 
> (kvm_tdx_caps) so this patch definitely must come after changes 
> introduced in patch 10. However, patch 9 seems completely independent of 
> patch 10, so I think patch 10 should become patch 9, and patch 9/11 
> should be squashed into one and become patch 10.

Yes, thanks. The patch order needs to be cleaned up. This posting was mostly
intended to try to settle the whole guest CPU feature API design. I probably
should have tagged it RFC instead of just including the coverletter blurb:
   Please feel free to wait for future revisions to spend time trying to correct
   smaller code issues. But I would greatly appreciate discussion on the overall
   design and how we are weighing the tradeoffs for the uAPI.