linux.git/drivers/vfio, branch v5.2-rc2

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46+00:00

Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

mm/gup: change GUP fast to use flags rather than a write 'bool'

2019-05-14T16:47:46+00:00

To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.

This patch does not change any functionality.  New functionality will
follow in subsequent patches.

Some of the get_user_pages_fast() call sites were unchanged because they
already passed FOLL_WRITE or 0 for the write parameter.

NOTE: It was suggested to change the ordering of the get_user_pages_fast()
arguments to ensure that callers were converted.  This breaks the current
GUP call site convention of having the returned pages be the final
parameter.  So the suggestion was rejected.

Link: http://lkml.kernel.org/r/20190328084422.29911-4-ira.weiny@intel.com
Link: http://lkml.kernel.org/r/20190317183438.2057-4-ira.weiny@intel.com
Signed-off-by: Ira Weiny 
Reviewed-by: Mike Marshall 
Cc: Aneesh Kumar K.V 
Cc: Benjamin Herrenschmidt 
Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: "David S. Miller" 
Cc: Heiko Carstens 
Cc: Ingo Molnar 
Cc: James Hogan 
Cc: Jason Gunthorpe 
Cc: John Hubbard 
Cc: "Kirill A. Shutemov" 
Cc: Martin Schwidefsky 
Cc: Michal Hocko 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Ralf Baechle 
Cc: Rich Felker 
Cc: Thomas Gleixner 
Cc: Yoshinori Sato 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/gup: replace get_user_pages_longterm() with FOLL_LONGTERM

2019-05-14T16:47:45+00:00

Pach series "Add FOLL_LONGTERM to GUP fast and use it".

HFI1, qib, and mthca, use get_user_pages_fast() due to its performance
advantages.  These pages can be held for a significant time.  But
get_user_pages_fast() does not protect against mapping FS DAX pages.

Introduce FOLL_LONGTERM and use this flag in get_user_pages_fast() which
retains the performance while also adding the FS DAX checks.  XDP has also
shown interest in using this functionality.[1]

In addition we change get_user_pages() to use the new FOLL_LONGTERM flag
and remove the specialized get_user_pages_longterm call.

[1] https://lkml.org/lkml/2019/3/19/939

"longterm" is a relative thing and at this point is probably a misnomer.
This is really flagging a pin which is going to be given to hardware and
can't move.  I've thought of a couple of alternative names but I think we
have to settle on if we are going to use FL_LAYOUT or something else to
solve the "longterm" problem.  Then I think we can change the flag to a
better name.

Secondly, it depends on how often you are registering memory.  I have
spoken with some RDMA users who consider MR in the performance path...
For the overall application performance.  I don't have the numbers as the
tests for HFI1 were done a long time ago.  But there was a significant
advantage.  Some of which is probably due to the fact that you don't have
to hold mmap_sem.

Finally, architecturally I think it would be good for everyone to use
*_fast.  There are patches submitted to the RDMA list which would allow
the use of *_fast (they reworking the use of mmap_sem) and as soon as they
are accepted I'll submit a patch to convert the RDMA core as well.  Also
to this point others are looking to use *_fast.

As an aside, Jasons pointed out in my previous submission that *_fast and
*_unlocked look very much the same.  I agree and I think further cleanup
will be coming.  But I'm focused on getting the final solution for DAX at
the moment.

This patch (of 7):

This patch starts a series which aims to support FOLL_LONGTERM in
get_user_pages_fast().  Some callers who would like to do a longterm (user
controlled pin) of pages with the fast variant of GUP for performance
purposes.

Rather than have a separate get_user_pages_longterm() call, introduce
FOLL_LONGTERM and change the longterm callers to use it.

This patch does not change any functionality.  In the short term
"longterm" or user controlled pins are unsafe for Filesystems and FS DAX
in particular has been blocked.  However, callers of get_user_pages_fast()
were not "protected".

FOLL_LONGTERM can _only_ be supported with get_user_pages[_fast]() as it
requires vmas to determine if DAX is in use.

NOTE: In merging with the CMA changes we opt to change the
get_user_pages() call in check_and_migrate_cma_pages() to a call of
__get_user_pages_locked() on the newly migrated pages.  This makes the
code read better in that we are calling __get_user_pages_locked() on the
pages before and after a potential migration.

As a side affect some of the interfaces are cleaned up but this is not the
primary purpose of the series.

In review[1] it was asked:


> This I don't get - if you do lock down long term mappings performance
> of the actual get_user_pages call shouldn't matter to start with.
>
> What do I miss?

A couple of points.

First "longterm" is a relative thing and at this point is probably a
misnomer.  This is really flagging a pin which is going to be given to
hardware and can't move.  I've thought of a couple of alternative names
but I think we have to settle on if we are going to use FL_LAYOUT or
something else to solve the "longterm" problem.  Then I think we can
change the flag to a better name.

Second, It depends on how often you are registering memory.  I have spoken
with some RDMA users who consider MR in the performance path...  For the
overall application performance.  I don't have the numbers as the tests
for HFI1 were done a long time ago.  But there was a significant
advantage.  Some of which is probably due to the fact that you don't have
to hold mmap_sem.

Finally, architecturally I think it would be good for everyone to use
*_fast.  There are patches submitted to the RDMA list which would allow
the use of *_fast (they reworking the use of mmap_sem) and as soon as they
are accepted I'll submit a patch to convert the RDMA core as well.  Also
to this point others are looking to use *_fast.

As an asside, Jasons pointed out in my previous submission that *_fast and
*_unlocked look very much the same.  I agree and I think further cleanup
will be coming.  But I'm focused on getting the final solution for DAX at
the moment.



[1] https://lore.kernel.org/lkml/20190220180255.GA12020@iweiny-DESK2.sc.intel.com/T/#md6abad2569f3bf6c1f03686c8097ab6563e94965

[ira.weiny@intel.com: v3]
  Link: http://lkml.kernel.org/r/20190328084422.29911-2-ira.weiny@intel.com
Link: http://lkml.kernel.org/r/20190328084422.29911-2-ira.weiny@intel.com
Link: http://lkml.kernel.org/r/20190317183438.2057-2-ira.weiny@intel.com
Signed-off-by: Ira Weiny 
Reviewed-by: Andrew Morton 
Cc: Aneesh Kumar K.V 
Cc: Michal Hocko 
Cc: John Hubbard 
Cc: "Kirill A. Shutemov" 
Cc: Peter Zijlstra 
Cc: Jason Gunthorpe 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: "David S. Miller" 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Rich Felker 
Cc: Yoshinori Sato 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Dan Williams 
Cc: Mike Marshall 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'iommu-updates-v5.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2019-05-13T13:23:18+00:00

Pull IOMMU updates from Joerg Roedel:

 - ATS support for ARM-SMMU-v3.

 - AUX domain support in the IOMMU-API and the Intel VT-d driver. This
   adds support for multiple DMA address spaces per (PCI-)device. The
   use-case is to multiplex devices between host and KVM guests in a
   more flexible way than supported by SR-IOV.

 - the rest are smaller cleanups and fixes, two of which needed to be
   reverted after testing in linux-next.

* tag 'iommu-updates-v5.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (45 commits)
  Revert "iommu/amd: Flush not present cache in iommu_map_page"
  Revert "iommu/amd: Remove the leftover of bypass support"
  iommu/vt-d: Fix leak in intel_pasid_alloc_table on error path
  iommu/vt-d: Make kernel parameter igfx_off work with vIOMMU
  iommu/vt-d: Set intel_iommu_gfx_mapped correctly
  iommu/amd: Flush not present cache in iommu_map_page
  iommu/vt-d: Cleanup: no spaces at the start of a line
  iommu/vt-d: Don't request page request irq under dmar_global_lock
  iommu/vt-d: Use struct_size() helper
  iommu/mediatek: Fix leaked of_node references
  iommu/amd: Remove amd_iommu_pd_list
  iommu/arm-smmu: Log CBFRSYNRA register on context fault
  iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel
  iommu/arm-smmu-v3: Disable tagged pointers
  iommu/arm-smmu-v3: Add support for PCI ATS
  iommu/arm-smmu-v3: Link domains and devices
  iommu/arm-smmu-v3: Add a master->domain pointer
  iommu/arm-smmu-v3: Store SteamIDs in master
  iommu/arm-smmu-v3: Rename arm_smmu_master_data to arm_smmu_master
  ACPI/IORT: Check ATS capability in root complex nodes
  ...

Merge tag 'vfio-v5.2-rc1' of git://github.com/awilliam/linux-vfio

2019-05-11T14:47:46+00:00

Pull VFIO updates from Alex Williamson:

 - Improve dev_printk() usage (Bjorn Helgaas)

 - Fix issue with blocking in !TASK_RUNNING state while waiting for
   userspace to release devices (Farhan Ali)

 - Fix error path cleanup in nvlink setup (Greg Kurz)

 - mdev-core cleanups and fixes in preparation for more use cases (Parav
   Pandit)

 - Cornelia has volunteered as an official vfio reviewer (Cornelia Huck)

* tag 'vfio-v5.2-rc1' of git://github.com/awilliam/linux-vfio:
  vfio: Add Cornelia Huck as reviewer
  vfio/mdev: Avoid inline get and put parent helpers
  vfio/mdev: Fix aborting mdev child device removal if one fails
  vfio/mdev: Follow correct remove sequence
  vfio/mdev: Avoid masking error code to EBUSY
  vfio/mdev: Drop redundant extern for exported symbols
  vfio/mdev: Removed unused kref
  vfio/mdev: Avoid release parent reference during error path
  vfio-pci/nvlink2: Fix potential VMA leak
  vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING"
  vfio: Use dev_printk() when possible

vfio/mdev: Avoid inline get and put parent helpers

2019-05-07T17:23:13+00:00

As section 15 of Documentation/process/coding-style.rst clearly
describes that compiler will be able to optimize code.

Hence drop inline for get and put helpers for parent.

Signed-off-by: Parav Pandit 
Signed-off-by: Alex Williamson

vfio/mdev: Fix aborting mdev child device removal if one fails

2019-05-07T17:23:13+00:00

device_for_each_child() stops executing callback function for remaining
child devices, if callback hits an error.
Each child mdev device is independent of each other.
While unregistering parent device, mdev core must remove all child mdev
devices.
Therefore, mdev_device_remove_cb() always returns success so that
device_for_each_child doesn't abort if one child removal hits error.

While at it, improve remove and unregister functions for below simplicity.

There isn't need to pass forced flag pointer during mdev parent
removal which invokes mdev_device_remove(). So simplify the flow.

mdev_device_remove() is called from two paths.
1. mdev_unregister_driver()
     mdev_device_remove_cb()
       mdev_device_remove()
2. remove_store()
     mdev_device_remove()

Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
Reviewed-by: Maxim Levitsky 
Signed-off-by: Parav Pandit 
Signed-off-by: Alex Williamson

vfio/mdev: Follow correct remove sequence

2019-05-07T17:23:13+00:00

mdev_remove_sysfs_files() should follow exact mirror sequence of a
create, similar to what is followed in error unwinding path of
mdev_create_sysfs_files().

Fixes: 6a62c1dfb5c7 ("vfio/mdev: Re-order sysfs attribute creation")
Reviewed-by: Cornelia Huck 
Reviewed-by: Maxim Levitsky 
Signed-off-by: Parav Pandit 
Signed-off-by: Alex Williamson

vfio/mdev: Avoid masking error code to EBUSY

2019-05-07T17:23:13+00:00

Instead of masking return error to -EBUSY, return actual error
returned by the driver.

Reviewed-by: Cornelia Huck 
Reviewed-by: Maxim Levitsky 
Signed-off-by: Parav Pandit 
Signed-off-by: Alex Williamson

vfio/mdev: Removed unused kref

2019-05-07T17:23:13+00:00

Remove unused kref from the mdev_device structure.

Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
Reviewed-by: Cornelia Huck 
Reviewed-by: Kirti Wankhede 
Reviewed-by: Maxim Levitsky 
Signed-off-by: Parav Pandit 
Signed-off-by: Alex Williamson