Message-ID: <ee9c649eed3893d852c3d20fb96bdc4904b7c295.camel@intel.com>
Date: Thu, 22 Jan 2026 17:35:58 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "ackerleytng@...gle.com" <ackerleytng@...gle.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>
CC: "david@...nel.org" <david@...nel.org>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"svens@...ux.ibm.com" <svens@...ux.ibm.com>, "jgross@...e.com"
	<jgross@...e.com>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"surenb@...gle.com" <surenb@...gle.com>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"riel@...riel.com" <riel@...riel.com>, "pfalcato@...e.de" <pfalcato@...e.de>,
	"x86@...nel.org" <x86@...nel.org>, "rppt@...nel.org" <rppt@...nel.org>,
	"thuth@...hat.com" <thuth@...hat.com>, "borntraeger@...ux.ibm.com"
	<borntraeger@...ux.ibm.com>, "maz@...nel.org" <maz@...nel.org>,
	"palmer@...belt.com" <palmer@...belt.com>, "ast@...nel.org" <ast@...nel.org>,
	"pjw@...nel.org" <pjw@...nel.org>, "alex@...ti.fr" <alex@...ti.fr>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "hca@...ux.ibm.com"
	<hca@...ux.ibm.com>, "willy@...radead.org" <willy@...radead.org>,
	"wyihan@...gle.com" <wyihan@...gle.com>, "ryan.roberts@....com"
	<ryan.roberts@....com>, "yang@...amperecomputing.com"
	<yang@...amperecomputing.com>, "jolsa@...nel.org" <jolsa@...nel.org>,
	"jmattson@...gle.com" <jmattson@...gle.com>, "luto@...nel.org"
	<luto@...nel.org>, "aneesh.kumar@...nel.org" <aneesh.kumar@...nel.org>,
	"haoluo@...gle.com" <haoluo@...gle.com>, "patrick.roy@...ux.dev"
	<patrick.roy@...ux.dev>, "peterx@...hat.com" <peterx@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "coxu@...hat.com"
	<coxu@...hat.com>, "mhocko@...e.com" <mhocko@...e.com>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"mlevitsk@...hat.com" <mlevitsk@...hat.com>, "jgg@...pe.ca" <jgg@...pe.ca>,
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, "song@...nel.org"
	<song@...nel.org>, "Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>,
	"oupton@...nel.org" <oupton@...nel.org>, "kernel@...0n.name"
	<kernel@...0n.name>, "lorenzo.stoakes@...cle.com"
	<lorenzo.stoakes@...cle.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
	"martin.lau@...ux.dev" <martin.lau@...ux.dev>, "jthoughton@...gle.com"
	<jthoughton@...gle.com>, "jhubbard@...dia.com" <jhubbard@...dia.com>, "Yu,
 Yu-cheng" <yu-cheng.yu@...el.com>, "kvmarm@...ts.linux.dev"
	<kvmarm@...ts.linux.dev>, "eddyz87@...il.com" <eddyz87@...il.com>,
	"hpa@...or.com" <hpa@...or.com>, "yonghong.song@...ux.dev"
	<yonghong.song@...ux.dev>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "shuah@...nel.org" <shuah@...nel.org>,
	"chenhuacai@...nel.org" <chenhuacai@...nel.org>, "prsampat@....com"
	<prsampat@....com>, "kevin.brodsky@....com" <kevin.brodsky@....com>,
	"maobibo@...ngson.cn" <maobibo@...ngson.cn>, "shijie@...amperecomputing.com"
	<shijie@...amperecomputing.com>, "suzuki.poulose@....com"
	<suzuki.poulose@....com>, "itazur@...zon.co.uk" <itazur@...zon.co.uk>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "yuzenghui@...wei.com"
	<yuzenghui@...wei.com>, "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
	"dev.jain@....com" <dev.jain@....com>, "daniel@...earbox.net"
	<daniel@...earbox.net>, "jackabt@...zon.co.uk" <jackabt@...zon.co.uk>,
	"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>, "andrii@...nel.org"
	<andrii@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, "joey.gouly@....com"
	<joey.gouly@....com>, "derekmn@...zon.com" <derekmn@...zon.com>,
	"xmarcalx@...zon.co.uk" <xmarcalx@...zon.co.uk>, "linux-s390@...r.kernel.org"
	<linux-s390@...r.kernel.org>, "kpsingh@...nel.org" <kpsingh@...nel.org>,
	"kalyazin@...zon.co.uk" <kalyazin@...zon.co.uk>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "sdf@...ichev.me" <sdf@...ichev.me>,
	"jackmanb@...gle.com" <jackmanb@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
	"corbet@....net" <corbet@....net>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "jannh@...gle.com" <jannh@...gle.com>,
	"john.fastabend@...il.com" <john.fastabend@...il.com>, "kas@...nel.org"
	<kas@...nel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"will@...nel.org" <will@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>
Subject: Re: [PATCH v9 07/13] KVM: guest_memfd: Add flag to remove from direct
 map

On Thu, 2026-01-22 at 08:44 -0800, Ackerley Tng wrote:
> 
> Can we disable direct map removal for errata systems using TDX only,
> instead of all TDX?
> 
> If it's complicated to figure that out, we can disable direct map
> removal for TDX for now and figure that out later.

In theory, but it still would require changes to TDX code since it does
the clflush unconditionally today. To know whether clflush is needed
(it's a different thing to the errata), you need to check a TDX module
flag. (CLFLUSH_BEFORE_ALLOC)

Gosh, you know what, I should double check that we don't need the
clflush from the vm shutdown optimization. It should be a different
thing, but for we gave scrutiny to the whole Linux flow when we did
that. So I'd have to double check nothing relied on it. We can follow
up here.

> 
> > Then there is the clfush. It is not actually required for the most
> > part. There is a TDX flag to check to see if you need to do it, so
> > we could probably remove the direct map accesses for some systems
> > and avoid temporary mappings.
> > 
> > So long term, I don't see a problem. For the old systems it would
> > have extra cost of temporary mappings at shutdown, but I would have
> > imagined direct map removal would have been costly too.
> 
> Is there a way to check if the code is running on the errata system
> and set up the temporary mappings only for those?

The TDX code today doesn't do any remapping because the direct map is
reliably present. There isn't a flag or anything to just do the
remapping automatically. We would have to do some vmalloc mapping or
temporary_mm or something.

Can you explain what the use case is for unmapping encrypted TDX
private memory from the host direct map?

Powered by blists - more mailing lists