Message-ID: <ed01838830679880d3eadaf6f11c539b9c72c22d.camel@intel.com>
Date: Thu, 15 Jan 2026 23:04:33 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"kalyazin@...zon.co.uk" <kalyazin@...zon.co.uk>, "kernel@...0n.name"
	<kernel@...0n.name>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>
CC: "david@...nel.org" <david@...nel.org>, "palmer@...belt.com"
	<palmer@...belt.com>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"svens@...ux.ibm.com" <svens@...ux.ibm.com>, "jgross@...e.com"
	<jgross@...e.com>, "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>,
	"maz@...nel.org" <maz@...nel.org>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "ast@...nel.org" <ast@...nel.org>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "borntraeger@...ux.ibm.com"
	<borntraeger@...ux.ibm.com>, "alex@...ti.fr" <alex@...ti.fr>,
	"pjw@...nel.org" <pjw@...nel.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"willy@...radead.org" <willy@...radead.org>, "hca@...ux.ibm.com"
	<hca@...ux.ibm.com>, "wyihan@...gle.com" <wyihan@...gle.com>,
	"ryan.roberts@....com" <ryan.roberts@....com>, "jolsa@...nel.org"
	<jolsa@...nel.org>, "yang@...amperecomputing.com"
	<yang@...amperecomputing.com>, "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>, "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>, "jgg@...pe.ca" <jgg@...pe.ca>, "hpa@...or.com"
	<hpa@...or.com>, "song@...nel.org" <song@...nel.org>, "oupton@...nel.org"
	<oupton@...nel.org>, "peterz@...radead.org" <peterz@...radead.org>,
	"maobibo@...ngson.cn" <maobibo@...ngson.cn>, "lorenzo.stoakes@...cle.com"
	<lorenzo.stoakes@...cle.com>, "Liam.Howlett@...cle.com"
	<Liam.Howlett@...cle.com>, "jthoughton@...gle.com" <jthoughton@...gle.com>,
	"martin.lau@...ux.dev" <martin.lau@...ux.dev>, "jhubbard@...dia.com"
	<jhubbard@...dia.com>, "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
	"Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
	"eddyz87@...il.com" <eddyz87@...il.com>, "yonghong.song@...ux.dev"
	<yonghong.song@...ux.dev>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
	"shuah@...nel.org" <shuah@...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>, "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>,
	"kpsingh@...nel.org" <kpsingh@...nel.org>, "sdf@...ichev.me"
	<sdf@...ichev.me>, "jackmanb@...gle.com" <jackmanb@...gle.com>,
	"bp@...en8.de" <bp@...en8.de>, "corbet@....net" <corbet@....net>,
	"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>, "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 Wed, 2026-01-14 at 13:46 +0000, Kalyazin, Nikita wrote:
> Add GUEST_MEMFD_FLAG_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD()
> ioctl. When set, guest_memfd folios will be removed from the direct map
> after preparation, with direct map entries only restored when the folios
> are freed.
> 
> To ensure these folios do not end up in places where the kernel cannot
> deal with them, set AS_NO_DIRECT_MAP on the guest_memfd's struct
> address_space if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is requested.
> 
> Note that this flag causes removal of direct map entries for all
> guest_memfd folios independent of whether they are "shared" or "private"
> (although current guest_memfd only supports either all folios in the
> "shared" state, or all folios in the "private" state if
> GUEST_MEMFD_FLAG_MMAP is not set). The usecase for removing direct map
> entries of also the shared parts of guest_memfd are a special type of
> non-CoCo VM where, host userspace is trusted to have access to all of
> guest memory, but where Spectre-style transient execution attacks
> through the host kernel's direct map should still be mitigated.  In this
> setup, KVM retains access to guest memory via userspace mappings of
> guest_memfd, which are reflected back into KVM's memslots via
> userspace_addr. This is needed for things like MMIO emulation on x86_64
> to work.

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.

Not that there would be any expected use of the flag for TDs, but it could cause
a crash.

Powered by blists - more mailing lists