linux-kernel - Re: [PATCH v19 062/130] KVM: x86/tdp_mmu: Support TDX private mapping for TDP MMU

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: <26486ffd7ee198a397ae2b854a6d3cc100987595.camel@intel.com>
Date: Fri, 19 Apr 2024 18:55:50 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Yamahata, Isaku" <isaku.yamahata@...el.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "Yuan, Hang" <hang.yuan@...el.com>,
	"Huang, Kai" <kai.huang@...el.com>, "Chen, Bo2" <chen.bo@...el.com>,
	"sagis@...gle.com" <sagis@...gle.com>, "isaku.yamahata@...ux.intel.com"
	<isaku.yamahata@...ux.intel.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Aktas, Erdem" <erdemaktas@...gle.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>, "Zhao, Yan Y"
	<yan.y.zhao@...el.com>
Subject: Re: [PATCH v19 062/130] KVM: x86/tdp_mmu: Support TDX private mapping
 for TDP MMU

On Tue, 2024-03-26 at 11:06 -0700, Isaku Yamahata wrote:
> > I was wondering about something limited to the operations that iterate over
> > the roots. So not
> > keeping private_root_hpa in the list of roots where it has to be carefully
> > protected from getting
> > zapped or get its gfn adjusted, and instead open coding the private case in
> > the higher level zapping
> > operations. For normal VM's the private case would be a NOP.
> > 
> > Since kvm_tdp_mmu_map() already grabs private_root_hpa manually, it wouldn't
> > change in this idea. I
> > don't know how much better it would be though. I think you are right we
> > would have to create them
> > and compare. 
> 
> Given the large page support gets complicated, it would be worthwhile to try,
> I think.

Circling back here, let's keep things as is for the MMU breakout series. We
didn't get any maintainer comments on the proposed refactor, and we might get
some on the smaller MMU breakout series. Then we can just have the smaller less
controversial changes already incorporated for the discussion. We can mention
the idea in the coverletter.