[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F7F6094E2@ORSMSX115.amr.corp.intel.com>
Date: Tue, 28 Apr 2020 22:32:43 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Pan, Jacob jun" <jacob.jun.pan@...el.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>,
David Woodhouse <dwmw2@...radead.org>,
Lu Baolu <baolu.lu@...ux.intel.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Jiang, Dave" <dave.jiang@...el.com>,
"Mehta, Sohil" <sohil.mehta@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: RE: [PATCH 5/7] x86/mmu: Allocate/free PASID
> There are two users of a PASID, mm and device driver(FD). If
> either one is not done with the PASID, it cannot be reclaimed. As you
> mentioned, it could take a long time for the driver to abort. If the
> abort ends *after* mmdrop, we are in trouble.
> If driver drops reference after abort/drain PASID is done, then we are
> safe.
I don't think there should be an abort ... suppose the application requested
the DSA to copy some large block of important results from DDR4 to
persistent memory. Driver should wait for that copy operation to complete.
Note that for the operation to succeed, the kernel should still be processing
and fixing page faults for the "mm" (some parts of the data that the user wanted
to save to persistent memory may have been paged out).
The wait by the DSA diver needs to by synchronous ... the "mm" cannot be
freed until DSA says all the pending operations have completed.
Even without persistent memory, there are cases where you want the operations
to complete (mmap'd files, shared memory with other processes).
-Tony
Powered by blists - more mailing lists