Message-ID: <20250624130811.GB72557@ziepe.ca>
Date: Tue, 24 Jun 2025 10:08:11 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Alexey Kardashevskiy <aik@....com>
Cc: Vishal Annapurve <vannapurve@...gle.com>, Fuad Tabba <tabba@...gle.com>,
	Ackerley Tng <ackerleytng@...gle.com>, kvm@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-fsdevel@...r.kernel.org, ajones@...tanamicro.com,
	akpm@...ux-foundation.org, amoorthy@...gle.com,
	anthony.yznaga@...cle.com, anup@...infault.org,
	aou@...s.berkeley.edu, bfoster@...hat.com,
	binbin.wu@...ux.intel.com, brauner@...nel.org,
	catalin.marinas@....com, chao.p.peng@...el.com,
	chenhuacai@...nel.org, dave.hansen@...el.com, david@...hat.com,
	dmatlack@...gle.com, dwmw@...zon.co.uk, erdemaktas@...gle.com,
	fan.du@...el.com, fvdl@...gle.com, graf@...zon.com,
	haibo1.xu@...el.com, hch@...radead.org, hughd@...gle.com,
	ira.weiny@...el.com, isaku.yamahata@...el.com, jack@...e.cz,
	james.morse@....com, jarkko@...nel.org, jgowans@...zon.com,
	jhubbard@...dia.com, jroedel@...e.de, jthoughton@...gle.com,
	jun.miao@...el.com, kai.huang@...el.com, keirf@...gle.com,
	kent.overstreet@...ux.dev, kirill.shutemov@...el.com,
	liam.merwick@...cle.com, maciej.wieczor-retman@...el.com,
	mail@...iej.szmigiero.name, maz@...nel.org, mic@...ikod.net,
	michael.roth@....com, mpe@...erman.id.au, muchun.song@...ux.dev,
	nikunj@....com, nsaenz@...zon.es, oliver.upton@...ux.dev,
	palmer@...belt.com, pankaj.gupta@....com, paul.walmsley@...ive.com,
	pbonzini@...hat.com, pdurrant@...zon.co.uk, peterx@...hat.com,
	pgonda@...gle.com, pvorel@...e.cz, qperret@...gle.com,
	quic_cvanscha@...cinc.com, quic_eberman@...cinc.com,
	quic_mnalajal@...cinc.com, quic_pderrin@...cinc.com,
	quic_pheragu@...cinc.com, quic_svaddagi@...cinc.com,
	quic_tsoni@...cinc.com, richard.weiyang@...il.com,
	rick.p.edgecombe@...el.com, rientjes@...gle.com,
	roypat@...zon.co.uk, rppt@...nel.org, seanjc@...gle.com,
	shuah@...nel.org, steven.price@....com, steven.sistare@...cle.com,
	suzuki.poulose@....com, thomas.lendacky@....com,
	usama.arif@...edance.com, vbabka@...e.cz, viro@...iv.linux.org.uk,
	vkuznets@...hat.com, wei.w.wang@...el.com, will@...nel.org,
	willy@...radead.org, xiaoyao.li@...el.com, yan.y.zhao@...el.com,
	yilun.xu@...el.com, yuzenghui@...wei.com, zhiquan1.li@...el.com
Subject: Re: [RFC PATCH v2 04/51] KVM: guest_memfd: Introduce
 KVM_GMEM_CONVERT_SHARED/PRIVATE ioctls

On Tue, Jun 24, 2025 at 06:23:54PM +1000, Alexey Kardashevskiy wrote:

> Now, I am rebasing my RFC on top of this patchset and it fails in
> kvm_gmem_has_safe_refcount() as IOMMU holds references to all these
> folios in my RFC.
> 
> So what is the expected sequence here? The userspace unmaps a DMA
> page and maps it back right away, all from the userspace? The end
> result will be the exactly same which seems useless. And IOMMU TLB
> is going to be flushed on a page conversion anyway (the RMPUPDATE
> instruction does that). All this is about AMD's x86 though.

The iommu should not be using the VMA to manage the mapping. It should
be directly linked to the guestmemfd in some way that does not disturb
its operations. I imagine there would be some kind of invalidation
callback directly to the iommu.

Presumably that invalidation call back can include a reason for the
invalidation (addr change, shared/private conversion, etc)

I'm not sure how we will figure out which case is which but guestmemfd
should allow the iommu to plug in either invalidation scheme..

Probably invalidation should be a global to the FD thing, I imagine
that once invalidation is established the iommu will not be
incrementing page refcounts.

Jason

Powered by blists - more mailing lists