[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8c1fb4092547e2453ddcdcfab97f06e273ad17d8.camel@intel.com>
Date: Fri, 16 Jan 2026 17:51:30 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "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>,
"palmer@...belt.com" <palmer@...belt.com>, "jgross@...e.com"
<jgross@...e.com>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"surenb@...gle.com" <surenb@...gle.com>, "riel@...riel.com"
<riel@...riel.com>, "pfalcato@...e.de" <pfalcato@...e.de>,
"peterx@...hat.com" <peterx@...hat.com>, "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>, "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
"ast@...nel.org" <ast@...nel.org>, "vbabka@...e.cz" <vbabka@...e.cz>,
"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>, "aneesh.kumar@...nel.org"
<aneesh.kumar@...nel.org>, "luto@...nel.org" <luto@...nel.org>,
"haoluo@...gle.com" <haoluo@...gle.com>, "patrick.roy@...ux.dev"
<patrick.roy@...ux.dev>, "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>, "mlevitsk@...hat.com"
<mlevitsk@...hat.com>, "linux-kselftest@...r.kernel.org"
<linux-kselftest@...r.kernel.org>, "jgg@...pe.ca" <jgg@...pe.ca>,
"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, "song@...nel.org"
<song@...nel.org>, "oupton@...nel.org" <oupton@...nel.org>,
"jhubbard@...dia.com" <jhubbard@...dia.com>, "kernel@...0n.name"
<kernel@...0n.name>, "hpa@...or.com" <hpa@...or.com>,
"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "martin.lau@...ux.dev"
<martin.lau@...ux.dev>, "jthoughton@...gle.com" <jthoughton@...gle.com>, "Yu,
Yu-cheng" <yu-cheng.yu@...el.com>, "maobibo@...ngson.cn"
<maobibo@...ngson.cn>, "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
"Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
"peterz@...radead.org" <peterz@...radead.org>, "eddyz87@...il.com"
<eddyz87@...il.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>, "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>, "dev.jain@....com" <dev.jain@....com>,
"gor@...ux.ibm.com" <gor@...ux.ibm.com>, "jackabt@...zon.co.uk"
<jackabt@...zon.co.uk>, "daniel@...earbox.net" <daniel@...earbox.net>,
"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>, "ackerleytng@...gle.com"
<ackerleytng@...gle.com>, "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 Fri, 2026-01-16 at 09:30 -0800, Vishal Annapurve wrote:
> > TDX does some clearing at the direct map mapping for pages that
> > comes from gmem, using a special instruction. It also does some
> > clflushing at the direct map address for these pages. So I think we
> > need to make sure TDs don't pull from gmem fds with this flag.
>
> Disabling this feature for TDX VMs for now seems ok. I assume TDX
> code can establish temporary mappings to the physical memory and
> therefore doesn't necessarily have to rely on direct map.
Can, as in, can be changed to? It doesn't now, because the direct map
is reliable today.
>
> Is it safe to say that we can remove direct map for guest memory for
> TDX VMs (and ideally other CC VMs as well) in future as needed?
Linux code doesn't need to read the cipher text of course, but it does
need to help with memory cleaning on the errata systems. Doing a new
mapping for each page getting reclaimed would add cost to the shutdown
path.
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.
Powered by blists - more mailing lists