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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ