> 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
On Tue, 28 Apr 2020 13:59:43 -0700
"Luck, Tony" wrote:
> >> So the driver needs to use flush/drain operations to make sure all
> >> the in-flight work has completed before releasing/re-using the
> >> PASID.
> > Are you suggesting we should let driver also hold a reference of the
> > PASID?
>
>> So the driver needs to use flush/drain operations to make sure all
>> the in-flight work has completed before releasing/re-using the PASID.
>>
> Are you suggesting we should let driver also hold a reference of the
> PASID?
The sequence for bare metal is:
process is queuing requests
On Sun, Apr 26, 2020 at 04:55:25PM +0200, Thomas Gleixner wrote:
> Fenghua Yu writes:
> > diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
> > index bdeae9291e5c..137bf51f19e6 100644
> > --- a/arch/x86/include/asm/mmu.h
> > +++ b/arch/x86/include/asm/mmu.h
> > @@ -50,6 +50,10
On Tue, 28 Apr 2020 12:07:25 -0700
"Luck, Tony" wrote:
> > If fd release cleans up then how should there be something in
> > flight at the final mmdrop?
>
> ENQCMD from the user is only synchronous in that it lets the user
> know their request has been added to a queue (or not). Execution of
On Tue, 28 Apr 2020 20:54:01 +0200
Thomas Gleixner wrote:
> "Jacob Pan (Jun)" writes:
> > On Sun, 26 Apr 2020 16:55:25 +0200
> > Thomas Gleixner wrote:
> >> Fenghua Yu writes:
> >> > The PASID is freed when the process exits (so no need to keep
> >> > reference counts on how many SVM
> If fd release cleans up then how should there be something in flight at
> the final mmdrop?
ENQCMD from the user is only synchronous in that it lets the user know their
request has been added to a queue (or not). Execution of the request may happen
later (if the device is busy working on
"Jacob Pan (Jun)" writes:
> On Sun, 26 Apr 2020 16:55:25 +0200
> Thomas Gleixner wrote:
>> Fenghua Yu writes:
>> > The PASID is freed when the process exits (so no need to keep
>> > reference counts on how many SVM devices are sharing the PASID).
>>
>> I'm not buying that. If there is an
On Sun, 26 Apr 2020 16:55:25 +0200
Thomas Gleixner wrote:
> Fenghua Yu writes:
>
> > PASID is shared by all threads in a process. So the logical place
> > to keep track of it is in the "mm". Add the field to the
> > architecture specific mm_context_t structure.
> >
> > A PASID is allocated for
Fenghua Yu writes:
> On Sun, Apr 26, 2020 at 04:55:25PM +0200, Thomas Gleixner wrote:
>> Fenghua Yu writes:
>> > + +#ifdef CONFIG_INTEL_IOMMU_SVM + int pasid;
>>
>> int? It's a value which gets programmed into the MSR along with the valid
>> bit (bit 31) set.
>
> The pasid is defined as "int"
On Sun, Apr 26, 2020 at 04:55:25PM +0200, Thomas Gleixner wrote:
> Fenghua Yu writes:
> > +++ b/arch/x86/include/asm/mmu.h @@ -50,6 +50,10 @@ typedef struct {
> > u16 pkey_allocation_map; s16 execute_only_pkey;
> > #endif
> > + +#ifdef CONFIG_INTEL_IOMMU_SVM + int pasid;
>
> int? It's a
Fenghua Yu writes:
> PASID is shared by all threads in a process. So the logical place to keep
> track of it is in the "mm". Add the field to the architecture specific
> mm_context_t structure.
>
> A PASID is allocated for an "mm" the first time any thread attaches
> to an SVM capable device.
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Add the field to the architecture specific
mm_context_t structure.
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device atatches (whether to
13 matches
Mail list logo
