Message-ID: <5decd42b3239d665d5e6c5c23e58c16c86488ca8.camel@intel.com>
Date: Tue, 8 Jul 2025 18:13:04 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "pvorel@...e.cz" <pvorel@...e.cz>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"Miao, Jun" <jun.miao@...el.com>, "palmer@...belt.com" <palmer@...belt.com>,
	"pdurrant@...zon.co.uk" <pdurrant@...zon.co.uk>, "vbabka@...e.cz"
	<vbabka@...e.cz>, "peterx@...hat.com" <peterx@...hat.com>, "x86@...nel.org"
	<x86@...nel.org>, "amoorthy@...gle.com" <amoorthy@...gle.com>,
	"tabba@...gle.com" <tabba@...gle.com>, "quic_svaddagi@...cinc.com"
	<quic_svaddagi@...cinc.com>, "maz@...nel.org" <maz@...nel.org>,
	"vkuznets@...hat.com" <vkuznets@...hat.com>, "anthony.yznaga@...cle.com"
	<anthony.yznaga@...cle.com>, "mail@...iej.szmigiero.name"
	<mail@...iej.szmigiero.name>, "Annapurve, Vishal" <vannapurve@...gle.com>,
	"quic_eberman@...cinc.com" <quic_eberman@...cinc.com>, "Wang, Wei W"
	<wei.w.wang@...el.com>, "Du, Fan" <fan.du@...el.com>, "Wieczor-Retman,
 Maciej" <maciej.wieczor-retman@...el.com>, "Zhao, Yan Y"
	<yan.y.zhao@...el.com>, "ajones@...tanamicro.com" <ajones@...tanamicro.com>,
	"Hansen, Dave" <dave.hansen@...el.com>, "paul.walmsley@...ive.com"
	<paul.walmsley@...ive.com>, "quic_mnalajal@...cinc.com"
	<quic_mnalajal@...cinc.com>, "aik@....com" <aik@....com>,
	"usama.arif@...edance.com" <usama.arif@...edance.com>, "fvdl@...gle.com"
	<fvdl@...gle.com>, "jack@...e.cz" <jack@...e.cz>, "quic_cvanscha@...cinc.com"
	<quic_cvanscha@...cinc.com>, "Shutemov, Kirill" <kirill.shutemov@...el.com>,
	"willy@...radead.org" <willy@...radead.org>, "steven.price@....com"
	<steven.price@....com>, "anup@...infault.org" <anup@...infault.org>,
	"thomas.lendacky@....com" <thomas.lendacky@....com>, "keirf@...gle.com"
	<keirf@...gle.com>, "mic@...ikod.net" <mic@...ikod.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"nsaenz@...zon.es" <nsaenz@...zon.es>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "oliver.upton@...ux.dev"
	<oliver.upton@...ux.dev>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "muchun.song@...ux.dev" <muchun.song@...ux.dev>,
	"Li, Zhiquan1" <zhiquan1.li@...el.com>, "rientjes@...gle.com"
	<rientjes@...gle.com>, "Aktas, Erdem" <erdemaktas@...gle.com>,
	"mpe@...erman.id.au" <mpe@...erman.id.au>, "david@...hat.com"
	<david@...hat.com>, "jgg@...pe.ca" <jgg@...pe.ca>, "hughd@...gle.com"
	<hughd@...gle.com>, "jhubbard@...dia.com" <jhubbard@...dia.com>, "Xu, Haibo1"
	<haibo1.xu@...el.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"jthoughton@...gle.com" <jthoughton@...gle.com>, "rppt@...nel.org"
	<rppt@...nel.org>, "steven.sistare@...cle.com" <steven.sistare@...cle.com>,
	"jarkko@...nel.org" <jarkko@...nel.org>, "quic_pheragu@...cinc.com"
	<quic_pheragu@...cinc.com>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
	"Huang, Kai" <kai.huang@...el.com>, "shuah@...nel.org" <shuah@...nel.org>,
	"bfoster@...hat.com" <bfoster@...hat.com>, "dwmw@...zon.co.uk"
	<dwmw@...zon.co.uk>, "Peng, Chao P" <chao.p.peng@...el.com>,
	"pankaj.gupta@....com" <pankaj.gupta@....com>, "Graf, Alexander"
	<graf@...zon.com>, "nikunj@....com" <nikunj@....com>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "yuzenghui@...wei.com" <yuzenghui@...wei.com>,
	"jroedel@...e.de" <jroedel@...e.de>, "suzuki.poulose@....com"
	<suzuki.poulose@....com>, "jgowans@...zon.com" <jgowans@...zon.com>, "Xu,
 Yilun" <yilun.xu@...el.com>, "liam.merwick@...cle.com"
	<liam.merwick@...cle.com>, "michael.roth@....com" <michael.roth@....com>,
	"quic_tsoni@...cinc.com" <quic_tsoni@...cinc.com>, "Li, Xiaoyao"
	<xiaoyao.li@...el.com>, "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
	"Weiny, Ira" <ira.weiny@...el.com>, "richard.weiyang@...il.com"
	<richard.weiyang@...il.com>, "kent.overstreet@...ux.dev"
	<kent.overstreet@...ux.dev>, "qperret@...gle.com" <qperret@...gle.com>,
	"dmatlack@...gle.com" <dmatlack@...gle.com>, "james.morse@....com"
	<james.morse@....com>, "brauner@...nel.org" <brauner@...nel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"ackerleytng@...gle.com" <ackerleytng@...gle.com>, "pgonda@...gle.com"
	<pgonda@...gle.com>, "quic_pderrin@...cinc.com" <quic_pderrin@...cinc.com>,
	"roypat@...zon.co.uk" <roypat@...zon.co.uk>, "hch@...radead.org"
	<hch@...radead.org>, "will@...nel.org" <will@...nel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [RFC PATCH v2 00/51] 1G page support for guest_memfd

On Tue, 2025-07-08 at 11:03 -0700, Sean Christopherson wrote:
> > I think there is interest in de-coupling it?
> 
> No?

I'm talking about the intra-host migration/reboot optimization stuff. And not
doing a good job, sorry.

>   Even if we get to a point where multiple distinct VMs can bind to a single
> guest_memfd, e.g. for inter-VM shared memory, there will still need to be a
> sole
> owner of the memory.  AFAICT, fully decoupling guest_memfd from a VM would add
> non-trivial complexity for zero practical benefit.

I'm talking about moving a gmem fd between different VMs or something using
KVM_LINK_GUEST_MEMFD [0]. Not advocating to try to support it. But trying to
feel out where the concepts are headed. It kind of allows gmem fds (or just
their source memory?) to live beyond a VM lifecycle.

[0] https://lore.kernel.org/all/cover.1747368092.git.afranji@google.com/
https://lore.kernel.org/kvm/cover.1749672978.git.afranji@google.com/

Powered by blists - more mailing lists