linux-kernel - Re: [PATCH v4 04/16] x86/virt/tdx: Allocate page bitmap for Dynamic PAMT

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: <94b619208022ee29812d871eeacab4f979e51d85.camel@intel.com>
Date: Tue, 6 Jan 2026 17:00:48 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "yilun.xu@...ux.intel.com" <yilun.xu@...ux.intel.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "Huang, Kai" <kai.huang@...el.com>, "Li,
 Xiaoyao" <xiaoyao.li@...el.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"Zhao, Yan Y" <yan.y.zhao@...el.com>, "Wu, Binbin" <binbin.wu@...el.com>,
	"kas@...nel.org" <kas@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"mingo@...hat.com" <mingo@...hat.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>, "Yamahata,
 Isaku" <isaku.yamahata@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "Gao, Chao" <chao.gao@...el.com>, "bp@...en8.de"
	<bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v4 04/16] x86/virt/tdx: Allocate page bitmap for Dynamic
 PAMT

On Tue, 2026-01-06 at 12:01 +0800, Xu Yilun wrote:
> Yes the extra indentation is unconventional, but everything here is,
> and we know we will eventually change them all. So I more prefer
> simple changes based on:
> 
>   if (!ret && !(ret = read_sys_metadata_field(0xABCDEF, &val)))
> 
> rather than neat but more LOC (when both are easy to read).

This whole code style was optimized to be verifiable, not for LOC. Kai
originally had several macro based solution that had a bunch of code
reuse before this style got settled on as part of the code gen. It
would definitely be a good thing to review the previous versions before
working on yet another solution to metadata reading.

> 
> Anyway, this is trivial concern. I have more optional fields to add
> and will follow the final decision.

This is the kind of thing that shouldn't need a clever solution. There
*should* be a way to more simply copy structured data from the TDX
module.

I do think this is a good area for cleanup, but let's not overhaul it
just to get a small incremental benefit. If we need a new interface in
the TDX module, let's explore it and actually get to something simple.