[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231204234936.GB2692119@nvidia.com>
Date: Mon, 4 Dec 2023 19:49:36 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Yan Zhao <yan.y.zhao@...el.com>, iommu@...ts.linux.dev,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
alex.williamson@...hat.com, pbonzini@...hat.com, joro@...tes.org,
will@...nel.org, robin.murphy@....com, kevin.tian@...el.com,
baolu.lu@...ux.intel.com, dwmw2@...radead.org, yi.l.liu@...el.com
Subject: Re: [RFC PATCH 00/42] Sharing KVM TDP to IOMMU
On Mon, Dec 04, 2023 at 12:11:46PM -0800, Sean Christopherson wrote:
> > could we design the memfd stuff to not have the same challenges with
> > mirroring as normal VMAs?
>
> What challenges in particular are you concerned about? And maybe also define
> "mirroring"? E.g. ensuring that the CPU and IOMMU page tables are synchronized
> is very different than ensuring that the IOMMU page tables can only map memory
> that is mappable by the guest, i.e. that KVM can map into the CPU page tables.
IIRC, it has been awhile, it is difficult to get a new populated PTE
out of the MM side and into an hmm user and get all the invalidation
locking to work as well. Especially when the devices want to do
sleeping invalidations.
kvm doesn't solve this problem either, but pushing populated TDP PTEs
to another observer may be simpler, as perhaps would pushing populated
memfd pages or something like that?
"mirroring" here would simply mean that if the CPU side has a
popoulated page then the hmm side copying it would also have a
populated page. Instead of a fault on use model.
Jason
Powered by blists - more mailing lists