lkml.org 
[lkml]   [2022]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH v4 11/11] docs: x86: Change documentation for SVA (Shared Virtual Addressing)
    Date
    Since allocating, freeing and fixing up PASID are changed, the
    documentation is updated to reflect the changes.

    Originally-by: Ashok Raj <ashok.raj@intel.com>
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    ---
    v3:
    - Remove PASID refcount description (Thomas).

    v2:
    - Update life cycle info (Tony and Thomas).
    - Update initial PASID value to INVALID_IOASID on fork().

    Documentation/x86/sva.rst | 53 ++++++++++++++++++++++++++++++---------
    1 file changed, 41 insertions(+), 12 deletions(-)

    diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst
    index 076efd51ef1f..1a22020735a3 100644
    --- a/Documentation/x86/sva.rst
    +++ b/Documentation/x86/sva.rst
    @@ -104,18 +104,47 @@ The MSR must be configured on each logical CPU before any application
    thread can interact with a device. Threads that belong to the same
    process share the same page tables, thus the same MSR value.

    -PASID is cleared when a process is created. The PASID allocation and MSR
    -programming may occur long after a process and its threads have been created.
    -One thread must call iommu_sva_bind_device() to allocate the PASID for the
    -process. If a thread uses ENQCMD without the MSR first being populated, a #GP
    -will be raised. The kernel will update the PASID MSR with the PASID for all
    -threads in the process. A single process PASID can be used simultaneously
    -with multiple devices since they all share the same address space.
    -
    -One thread can call iommu_sva_unbind_device() to free the allocated PASID.
    -The kernel will clear the PASID MSR for all threads belonging to the process.
    -
    -New threads inherit the MSR value from the parent.
    +PASID Life Cycle Management
    +==========================
    +
    +PASID is initialized as INVALID_IOASID (-1) when a process is created.
    +
    +Only processes that access SVA-capable devices need to have a PASID
    +allocated. This allocation happens when a process opens/binds an SVA-capable
    +device but finds no PASID for this process. Subsequent binds of the same, or
    +other devices will share the same PASID.
    +
    +Although the PASID is allocated to the process by opening a device,
    +it is not active in any of the threads of that process. It's loaded to the
    +IA32_PASID MSR lazily when a thread tries to submit a work descriptor
    +to a device using the ENQCMD.
    +
    +That first access will trigger a #GP fault because the IA32_PASID MSR
    +has not been initialized with the PASID value assigned to the process
    +when the device was opened. The Linux #GP handler notes that a PASID has
    +been allocated for the process, and so initializes the IA32_PASID MSR
    +and returns so that the ENQCMD instruction is re-executed.
    +
    +On fork(2) or exec(2) the PASID is removed from the process as it no
    +longer has the same address space that it had when the device was opened.
    +
    +On clone(2) the new task shares the same address space, so will be
    +able to use the PASID allocated to the process. The IA32_PASID is not
    +preemptively initialized as the PASID value might not be allocated yet or
    +the kernel does not know whether this thread is going to access the device
    +and the cleared IA32_PASID MSR reduces context switch overhead by xstate
    +init optimization. Since #GP faults have to be handled on any threads that
    +were created before the PASID was assigned to the mm of the process, newly
    +created threads might as well be treated in a consistent way.
    +
    +Due to complexity of freeing the PASID and clearing all IA32_PASID MSRs in
    +all threads in unbind, free the PASID lazily only on mm exit.
    +
    +If a process does a close(2) of the device file descriptor and munmap(2)
    +of the device MMIO portal, then the driver will unbind the device. The
    +PASID is still marked VALID in the PASID_MSR for any threads in the
    +process that accessed the device. But this is harmless as without the
    +MMIO portal they cannot submit new work to the device.

    Relationships
    =============
    --
    2.35.1
    \
     
     \ /
      Last update: 2022-02-08 02:06    [W:4.078 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site