linux-toradex.git/include/linux/vfio.h, branch v6.0-rc1

vfio: Replace phys_pfn with pages for vfio_pin_pages()

2022-07-25T19:41:22+00:00

Most of the callers of vfio_pin_pages() want "struct page *" and the
low-level mm code to pin pages returns a list of "struct page *" too.
So there's no gain in converting "struct page *" to PFN in between.

Replace the output parameter "phys_pfn" list with a "pages" list, to
simplify callers. This also allows us to replace the vfio_iommu_type1
implementation with a more efficient one.

And drop the pfn_valid check in the gvt code, as there is no need to
do such a check at a page-backed struct page pointer.

For now, also update vfio_iommu_type1 to fit this new parameter too.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Kirti Wankhede 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Kevin Tian 
Acked-by: Eric Farman 
Tested-by: Terrence Xu 
Tested-by: Eric Farman 
Signed-off-by: Nicolin Chen 
Link: https://lore.kernel.org/r/20220723020256.30081-11-nicolinc@nvidia.com
Signed-off-by: Alex Williamson

vfio: Rename user_iova of vfio_dma_rw()

2022-07-25T19:41:22+00:00

Following the updated vfio_pin/unpin_pages(), use the simpler "iova".

Reviewed-by: Christoph Hellwig 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Kevin Tian 
Tested-by: Terrence Xu 
Tested-by: Eric Farman 
Signed-off-by: Nicolin Chen 
Link: https://lore.kernel.org/r/20220723020256.30081-9-nicolinc@nvidia.com
Signed-off-by: Alex Williamson

vfio: Pass in starting IOVA to vfio_pin/unpin_pages API

2022-07-25T19:41:22+00:00

The vfio_pin/unpin_pages() so far accepted arrays of PFNs of user IOVA.
Among all three callers, there was only one caller possibly passing in
a non-contiguous PFN list, which is now ensured to have contiguous PFN
inputs too.

Pass in the starting address with "iova" alone to simplify things, so
callers no longer need to maintain a PFN list or to pin/unpin one page
at a time. This also allows VFIO to use more efficient implementations
of pin/unpin_pages.

For now, also update vfio_iommu_type1 to fit this new parameter too,
while keeping its input intact (being user_iova) since we don't want
to spend too much effort swapping its parameters and local variables
at that level.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Kirti Wankhede 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Kevin Tian 
Reviewed-by: Tony Krowiak 
Acked-by: Eric Farman 
Tested-by: Terrence Xu 
Tested-by: Eric Farman 
Signed-off-by: Nicolin Chen 
Link: https://lore.kernel.org/r/20220723020256.30081-6-nicolinc@nvidia.com
Signed-off-by: Alex Williamson

vfio: Make vfio_unpin_pages() return void

2022-07-23T13:29:10+00:00

There's only one caller that checks its return value with a WARN_ON_ONCE,
while all other callers don't check the return value at all. Above that,
an undo function should not fail. So, simplify the API to return void by
embedding similar WARN_ONs.

Also for users to pinpoint which condition fails, separate WARN_ON lines,
yet remove the "driver->ops->unpin_pages" check, since it's unreasonable
for callers to unpin on something totally random that wasn't even pinned.
And remove NULL pointer checks for they would trigger oops vs. warnings.
Note that npage is already validated in the vfio core, thus drop the same
check in the type1 code.

Suggested-by: Christoph Hellwig 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Kirti Wankhede 
Tested-by: Terrence Xu 
Signed-off-by: Nicolin Chen 
Link: https://lore.kernel.org/r/20220723020256.30081-2-nicolinc@nvidia.com
Signed-off-by: Alex Williamson

vfio: Replace the iommu notifier with a device list

2022-07-20T17:57:59+00:00

Instead of bouncing the function call to the driver op through a blocking
notifier just have the iommu layer call it directly.

Register each device that is being attached to the iommu with the lower
driver which then threads them on a linked list and calls the appropriate
driver op at the right time.

Currently the only use is if dma_unmap() is defined.

Also, fully lock all the debugging tests on the pinning path that a
dma_unmap is registered.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Kevin Tian 
Signed-off-by: Jason Gunthorpe 
Link: https://lore.kernel.org/r/2-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidia.com
Signed-off-by: Alex Williamson

vfio: Replace the DMA unmapping notifier with a callback

2022-07-20T17:57:59+00:00

Instead of having drivers register the notifier with explicit code just
have them provide a dma_unmap callback op in their driver ops and rely on
the core code to wire it up.

Suggested-by: Christoph Hellwig 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Kevin Tian 
Reviewed-by: Tony Krowiak 
Reviewed-by: Eric Farman 
Reviewed-by: Zhenyu Wang 
Signed-off-by: Jason Gunthorpe 
Link: https://lore.kernel.org/r/1-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidia.com
Signed-off-by: Alex Williamson

vfio: Split migration ops from main device ops

2022-06-30T16:47:22+00:00

vfio core checks whether the driver sets some migration op (e.g.
set_state/get_state) and accordingly calls its op.

However, currently mlx5 driver sets the above ops without regards to its
migration caps.

This might lead to unexpected usage/Oops if user space may call to the
above ops even if the driver doesn't support migration. As for example,
the migration state_mutex is not initialized in that case.

The cleanest way to manage that seems to split the migration ops from
the main device ops, this will let the driver setting them separately
from the main ops when it's applicable.

As part of that, validate ops construction on registration and include a
check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set
in migration_flags.

HISI driver was changed as well to match this scheme.

This scheme may enable down the road to come with some extra group of
ops (e.g. DMA log) that can be set without regards to the other options
based on driver caps.

Fixes: 6fadb021266d ("vfio/mlx5: Implement vfio_pci driver for mlx5 devices")
Reviewed-by: Kevin Tian 
Signed-off-by: Yishai Hadas 
Link: https://lore.kernel.org/r/20220628155910.171454-3-yishaih@nvidia.com
Signed-off-by: Alex Williamson

vfio: de-extern-ify function prototypes

2022-06-27T15:38:02+00:00

The use of 'extern' in function prototypes has been disrecommended in
the kernel coding style for several years now, remove them from all vfio
related files so contributors no longer need to decide between style and
consistency.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Eric Farman 
Reviewed-by: Eric Auger 
Reviewed-by: Cornelia Huck 
Reviewed-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/165471414407.203056.474032786990662279.stgit@omen
Signed-off-by: Alex Williamson

vfio: remove VFIO_GROUP_NOTIFY_SET_KVM

2022-05-24T14:41:18+00:00

Rather than relying on a notifier for associating the KVM with
the group, let's assume that the association has already been
made prior to device_open.  The first time a device is opened
associate the group KVM with the device.

This fixes a user-triggerable oops in GVT.

Reviewed-by: Tony Krowiak 
Reviewed-by: Kevin Tian 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Matthew Rosato 
Reviewed-by: Jason Gunthorpe 
Acked-by: Zhi Wang 
Link: https://lore.kernel.org/r/20220519183311.582380-2-mjrosato@linux.ibm.com
Signed-off-by: Alex Williamson

vfio/pci: Use the struct file as the handle not the vfio_group

2022-05-13T16:14:20+00:00

VFIO PCI does a security check as part of hot reset to prove that the user
has permission to manipulate all the devices that will be impacted by the
reset.

Use a new API vfio_file_has_dev() to perform this security check against
the struct file directly and remove the vfio_group from VFIO PCI.

Since VFIO PCI was the last user of vfio_group_get_external_user() and
vfio_group_put_external_user() remove it as well.

Reviewed-by: Kevin Tian 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
Link: https://lore.kernel.org/r/8-v3-f7729924a7ea+25e33-vfio_kvm_no_group_jgg@nvidia.com
Signed-off-by: Alex Williamson