[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241017171010.GK3559746@nvidia.com>
Date: Thu, 17 Oct 2024 14:10:10 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Peter Xu <peterx@...hat.com>
Cc: David Hildenbrand <david@...hat.com>,
Ackerley Tng <ackerleytng@...gle.com>, tabba@...gle.com,
quic_eberman@...cinc.com, roypat@...zon.co.uk, rientjes@...gle.com,
fvdl@...gle.com, jthoughton@...gle.com, seanjc@...gle.com,
pbonzini@...hat.com, zhiquan1.li@...el.com, fan.du@...el.com,
jun.miao@...el.com, isaku.yamahata@...el.com, muchun.song@...ux.dev,
erdemaktas@...gle.com, vannapurve@...gle.com, qperret@...gle.com,
jhubbard@...dia.com, willy@...radead.org, shuah@...nel.org,
brauner@...nel.org, bfoster@...hat.com, kent.overstreet@...ux.dev,
pvorel@...e.cz, rppt@...nel.org, richard.weiyang@...il.com,
anup@...infault.org, haibo1.xu@...el.com, ajones@...tanamicro.com,
vkuznets@...hat.com, maciej.wieczor-retman@...el.com,
pgonda@...gle.com, oliver.upton@...ux.dev,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
kvm@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH 26/39] KVM: guest_memfd: Track faultability within a
struct kvm_gmem_private
On Thu, Oct 17, 2024 at 01:05:34PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> >
> > > My question was more torwards whether gmemfd could still expose the
> > > possibility to be used in VA forms to other modules that may not support
> > > fd+offsets yet.
> >
> > I keep hearing they don't want to support page pinning on a guestmemfd
> > mapping, so VA based paths could not work.
>
> Do you remember the reasoning of it? Is it because CoCo still needs to
> have a bounded time window to convert from shared back to private?
I think so
> If so, maybe that's a non-issue for non-CoCo, where the VM object /
> gmemfd object (when created) can have a flag marking that it's
> always shared and can never be converted to private for any page
> within.
What is non-CoCo? Does it include the private/shared concept?
> So how would VFIO's DMA work even with iommufd if pages cannot be pinned?
> Is some form of bounce buffering required, then?
We can do some kind of atomic replace during a private/shared
exchange. In some HW cases the iommu table doesn't even need an
update.
It will be tricky stuff.
Jason
Powered by blists - more mailing lists