lkml.org 
[lkml]   [2020]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 5/7] x86/mmu: Allocate/free PASID
    Date
    "Jacob Pan (Jun)" <jacob.jun.pan@intel.com> writes:
    > On Sun, 26 Apr 2020 16:55:25 +0200
    > Thomas Gleixner <tglx@linutronix.de> wrote:
    >> Fenghua Yu <fenghua.yu@intel.com> 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 outstanding request with the PASID
    >> of a process then tearing down the process address space and freeing
    >> the PASID (which might be reused) is fundamentally broken.
    >>
    > Device driver unbind PASID is tied to FD release. So when a process
    > exits, FD close causes driver to do the following:
    >
    > 1. stops DMA
    > 2. unbind PASID (clears the PASID entry in IOMMU, flush all TLBs, drain
    > in flight page requests)

    Fair enough. Explaining that somewhere might be helpful.

    > For bare metal SVM, if the last mmdrop always happens after FD release,
    > we can ensure no outstanding requests at the point of ioasid_free().
    > Perhaps this is a wrong assumption?

    If fd release cleans up then how should there be something in flight at
    the final mmdrop?

    > For guest SVM, there will be more users of a PASID. I am also
    > working on adding refcounting to ioasid. ioasid_free() will not release
    > the PASID back to the pool until all references are dropped.

    What does more users mean?

    >> > + if (mm && mm->context.pasid && !(flags &
    >> > SVM_FLAG_PRIVATE_PASID)) {
    >> > + /*
    >> > + * Once a PASID is allocated for this mm, the PASID
    >> > + * stays with the mm until the mm is dropped. Reuse
    >> > + * the PASID which has been already allocated for
    >> > the
    >> > + * mm instead of allocating a new one.
    >> > + */
    >> > + ioasid_set_data(mm->context.pasid, svm);
    >>
    >> So if the PASID is reused several times for different SVMs then every
    >> time ioasid_data->private is set to a different SVM. How is that
    >> supposed to work?
    >>
    > For the lifetime of the mm, there is only one PASID. svm_bind/unbind_mm
    > could happen many times with different private data: intel_svm.
    > Multiple devices can bind to the same PASID as well. But private data
    > don't change within the first bind and last unbind.

    Ok. I read through that spaghetti of intel_svm_bind_mm() again and now I
    start to get an idea how that is supposed to work. What a mess.

    That function really wants to be restructured in a way so it is
    understandable to mere mortals.

    Thanks,

    tglx

    \
     
     \ /
      Last update: 2020-04-28 20:54    [W:6.860 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site