Allows telling a mkey to use PCI ATS for DMA that flows through it.
Signed-off-by: Jason Gunthorpe
---
include/linux/mlx5/mlx5_ifc.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 4acd5610e96bc0
of these cases revolve around optimizing PCI P2P
transfers and avoiding bad cases where the bus just doesn't work.
Signed-off-by: Jason Gunthorpe
---
drivers/infiniband/hw/mlx5/devx.c| 37
drivers/infiniband/hw/mlx5/mlx5_ib.h | 36 +++
drivers
else stays the same.
Signed-off-by: Jason Gunthorpe
---
drivers/infiniband/hw/mlx5/devx.c| 24 +---
include/uapi/rdma/mlx5_user_ioctl_cmds.h | 1 +
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/devx.c
b/drivers/infiniba
This uses the same passing protocol as UVERBS_ATTR_FD (eg len = 0 data_s64
= fd), except that the FD is not required to be a uverbs object and the
core code does not covert the FD to an object handle automatically.
Access to the int fd is provided by uverbs_get_raw_fd().
Signed-off-by: Jason
..@nvidia.com
Cc: linux-r...@vger.kernel.org
Cc: Oded Gabbay
Cc: Christian König
Cc: Daniel Vetter
Cc: Leon Romanovsky
Cc: Maor Gottlieb
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jason Gunthorpe
Jason Gunthorpe (4):
dma-buf: Add dma_buf_try_get()
vfio: Add vfio_device_get()
Used to increment the refcount of the dma buf's struct file, only if the
refcount is not zero. Useful to allow the struct file's lifetime to
control the lifetime of the dmabuf while still letting the driver to keep
track of created dmabufs.
Signed-off-by: Jason Gunthorpe
---
include/linux/dma
triggered when
MMIO access returns. As both close and reset are under userspace control
it is expected that userspace will suspend use of the dma-buf before doing
these operations, the revoke is purely for kernel self-defense against a
hostile userspace.
Signed-off-by: Jason Gunthorpe
---
driver
FLR triggered by an emulated config space write should not behave
differently from a FLR triggered by VFIO_DEVICE_RESET, currently the
config space path misses the power management.
Consolidate all the call sites to invoke a single function.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci
To increment a reference the caller already holds. Export
vfio_device_put() to pair with it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio_main.c | 3 ++-
include/linux/vfio.h | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers
vice life cycle helpers
> vfio: Add struct device to vfio_device
Other than my small remarks this all looked good to me - for every patch:
Reviewed-by: Jason Gunthorpe
Thanks,
Jason
\:01.0/vfio-dev/vfio0
>
> It is also a preparatory step toward adding cdev for supporting future
> device-oriented uAPI.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Yi Liu
> Signed-off-by: Kevin Tian
> ---
> drivers/vfio/vfio_main.c | 70
On Sun, Aug 28, 2022 at 01:10:32AM +0800, Kevin Tian wrote:
> From: Yi Liu
>
> Export symbol of vfio_release_device_set() so fsl-mc @init can handle
> the error path cleanly instead of assuming certain vfio core API can
> help release device_set afterwards.
I think you should leave it as is,
On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote:
> On Sun, 28 Aug 2022 01:10:37 +0800
> Kevin Tian wrote:
>
> > From: Yi Liu
> >
> > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> > sysfs path of the parent, indicating the device is bound to a vfio
> >
On Tue, Aug 30, 2022 at 09:42:42AM -0400, Anthony Krowiak wrote:
> > +/*
> > + * Alloc and initialize vfio_device so it can be registered to vfio
> > + * core.
> > + *
> > + * Drivers should use the wrapper vfio_alloc_device() for allocation.
> > + * @size is the size of the structure to be
On Mon, Aug 29, 2022 at 01:04:05PM +0800, Yan Zhao wrote:
> > +static struct sg_table *
> > +vfio_pci_dma_buf_map(struct dma_buf_attachment *attachment,
> > +enum dma_data_direction dir)
> > +{
> > + size_t sgl_size = dma_get_max_seg_size(attachment->dev);
> > + struct
On Sun, Aug 21, 2022 at 04:51:34PM +0300, Oded Gabbay wrote:
> > +static void vfio_pci_dma_buf_unmap(struct dma_buf_attachment *attachment,
> > + struct sg_table *sgt,
> > + enum dma_data_direction dir)
> > +{
> > + struct
On Thu, Aug 18, 2022 at 03:37:01PM +0200, Christian König wrote:
> Am 18.08.22 um 15:16 schrieb Jason Gunthorpe:
> > On Thu, Aug 18, 2022 at 02:58:10PM +0200, Christian König wrote:
> >
> > > > > The only thing I'm not 100% convinced of is dma_buf_t
On Thu, Aug 18, 2022 at 01:07:16PM +0200, Christian König wrote:
> Am 17.08.22 um 18:11 schrieb Jason Gunthorpe:
> > dma-buf has become a way to safely acquire a handle to non-struct page
> > memory that can still have lifetime controlled by the exporter. Notably
> > RDMA c
On Fri, Aug 19, 2022 at 03:33:04PM +0200, Christian König wrote:
> > > > So we could delete the try_buf and just rely on move being safe on
> > > > partially destroyed dma_buf's as part of the API design.
> > > I think that might be the more defensive approach. A comment on the
> > >
On Thu, Aug 18, 2022 at 02:58:10PM +0200, Christian König wrote:
> > > The only thing I'm not 100% convinced of is dma_buf_try_get(), I've seen
> > > this incorrectly used so many times that I can't count them any more.
> > >
> > > Would that be somehow avoidable? Or could you at least explain
On Wed, Aug 17, 2022 at 01:11:38PM -0300, Jason Gunthorpe wrote:
> dma-buf has become a way to safely acquire a handle to non-struct page
> memory that can still have lifetime controlled by the exporter. Notably
> RDMA can now import dma-buf FDs and build them into MRs which allows for
FLR triggered by an emulated config space write should not behave
differently from a FLR triggered by VFIO_DEVICE_RESET, currently the
config space path misses the power management.
Consolidate all the call sites to invoke a single function.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci
triggered when
MMIO access returns. As both close and reset are under userspace control
it is expected that userspace will suspend use of the dma-buf before doing
these operations, the revoke is purely for kernel self-defense against a
hostile userspace.
Signed-off-by: Jason Gunthorpe
---
driver
To increment a reference the caller already holds. Export
vfio_device_put() to pair with it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio_main.c | 3 ++-
include/linux/vfio.h | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers
ux/commits/vfio_dma_buf
Jason Gunthorpe (4):
dma-buf: Add dma_buf_try_get()
vfio: Add vfio_device_get()
vfio_pci: Do not open code pci_try_reset_function()
vfio/pci: Allow MMIO regions to be exported through dma-buf
drivers/vfio/pci/Makefile | 1 +
drivers/vfio/pci/vfio_pc
Used to increment the refcount of the dma buf's struct file, only if the
refcount is not zero. Useful to allow the struct file's lifetime to
control the lifetime of the dmabuf while still letting the driver to keep
track of created dmabufs.
Signed-off-by: Jason Gunthorpe
---
include/linux/dma
On Tue, Aug 09, 2022 at 02:46:36PM +0200, Arnd Bergmann wrote:
> On Tue, Aug 9, 2022 at 2:18 PM Jason Gunthorpe wrote:
> > On Tue, Aug 09, 2022 at 10:32:27AM +0200, Arnd Bergmann wrote:
> > > On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig
> > > wrote:
>
On Mon, Aug 08, 2022 at 11:26:11PM +0300, Oded Gabbay wrote:
> So if you want a common uAPI and a common userspace library to use it,
> you need to expose the same device character files for every device,
> regardless of the driver. e.g. you need all devices to be called
> /dev/accelX and not
On Tue, Aug 09, 2022 at 10:32:27AM +0200, Arnd Bergmann wrote:
> On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig wrote:
> > On Tue, Aug 09, 2022 at 08:23:27AM +0200, Greg Kroah-Hartman wrote:
> > > > This is different from the number of FDs pointing at the struct file.
> > > > Userpsace can
On Mon, Aug 08, 2022 at 08:10:22AM +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 07, 2022 at 02:25:33PM +0300, Oded Gabbay wrote:
> > 2. Common code to handle drivers that want to allow a single user at a
> > time to run open the device char file.
>
> Note, that's an impossible request, and one
On Sun, Aug 07, 2022 at 09:43:40AM +0300, Oded Gabbay wrote:
> 1. If there is a subsystem which is responsible for creating and
> exposing the device character files, then there should be some code
> that connects between each device driver to that subsystem.
> i.e. There should be functions that
On Thu, Aug 04, 2022 at 08:48:28PM +0300, Oded Gabbay wrote:
> > The flip is true of DRM - DRM is pretty general. I bet I could
> > implement an RDMA device under DRM - but that doesn't mean it should
> > be done.
> >
> > My biggest concern is that this subsystem not turn into a back door
> > for
On Thu, Aug 04, 2022 at 10:43:42AM +0300, Oded Gabbay wrote:
> After all, memory management services, or common device chars handling
> I can get from other subsystems (e.g. rdma) as well. I'm sure I could
> model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI
> there as well),
On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote:
> ie. we don't need the gfn, we only need the iova.
Right, that makes sense
> However then I start to wonder why we're passing in 1 for the number of
> pages because this previously notifier, now callback is called for the
>
On Wed, Jul 20, 2022 at 09:47:12AM +0200, Cornelia Huck wrote:
> > If the FSM trapped in a bad state here, such as
> > VFIO_CCW_STATE_NOT_OPER, then it means it should have already unpinned
> > the pages and this is considered a success for this purpose
>
> A rather pathological case would be a
is
mandatory
- Move dma_unmap call loop to vfio_notify_dma_unmap()
- Document why the double mutex is being used and why the mutex lock is
dropped when calling dma_unmap
v1:
https://lore.kernel.org/r/0-v1-896844109f36+a-vfio_unmap_notif_...@nvidia.com
Signed-off-by: Jason Gunthorpe
Jason
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
---
drivers/vfio/vfio.c | 41
Reviewed-by: Eric Farman
Reviewed-by: Zhenyu Wang
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h| 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 75 ---
drivers/s390/cio/vfio_ccw_ops.c | 39 ++--
drivers/s390/cio/vfio_ccw_private.h | 2 -
drivers
On Thu, Jul 07, 2022 at 03:37:16PM -0600, Alex Williamson wrote:
> On Mon, 4 Jul 2022 21:59:03 -0300
> Jason Gunthorpe wrote:
> > diff --git a/drivers/s390/cio/vfio_ccw_ops.c
> > b/drivers/s390/cio/vfio_ccw_ops.c
> > index b49e2e9db2dc6f..09e0ce7b72324c 100644
&g
On Thu, Jul 07, 2022 at 10:12:41AM -0700, Nicolin Chen wrote:
> On Thu, Jul 07, 2022 at 08:42:28AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Nicolin Chen
> > > Sent: Wednesday, July 6, 2022 2:28 PM
> > >
> > > There's only one
crypto/vfio_ap_ops.c | 6 +++---
> drivers/vfio/vfio.c | 8
> drivers/vfio/vfio.h | 2 +-
> drivers/vfio/vfio_iommu_type1.c | 19 +++
> include/linux/vfio.h | 2 +-
> 8 files changed, 36 insertions(+), 41 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
a security purpose. In
> this patch, add kmap_local_page() to prepare for that.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
> drivers/s390/cio/vfio_ccw_cp.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
d, 4 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
me all
> "pfn_array" strings to "page_array", so as to simplify the code.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/s390/cio/vfio_ccw_cp.c | 135 -
> 1 file changed, 64 insertions(+), 71 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
AGE_SHIFT)))
> return -EINVAL;
This existing code is fishy. nib is either an IOVA passed to
vfio_pin_pages() or a GFN passed to gfn_to_hva(). These are not the
same thing and are not interchangable - writing code like this assumes
that the guest is running with iommu=pt or no iommu.
Someone should look at it..
Otherwise it looks OK
Reviewed-by: Jason Gunthorpe
Jason
n_pages(>vfio_device, _gfn, 1);
> - }
> + vfio_unpin_pages(>vfio_device, gfn << PAGE_SHIFT,
> + roundup(size, PAGE_SIZE) / PAGE_SIZE);
These maths are DIV_ROUND_UP()
Otherwise,
Reviewed-by: Jason Gunthorpe
Jason
tually create
non-continuities. Also the loop in copy_from_iova() should ideally be
using the much faster 'rw' interface, and not a pin/unpin cycle just
to memcpy.
If I guess right these changes would significantly speed this driver
up.
Anyhow,
Reviewed-by: Jason Gunthorpe
Jason
| 2 +-
> drivers/s390/crypto/vfio_ap_ops.c | 7 ---
> 3 files changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
.h | 2 +-
> drivers/vfio/vfio_iommu_type1.c | 16 ++---
> include/linux/vfio.h | 4 ++--
> 6 files changed, 23 insertions(+), 30 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
and why the mutex lock is
dropped when calling dma_unmap
v1:
https://lore.kernel.org/r/0-v1-896844109f36+a-vfio_unmap_notif_...@nvidia.com
Signed-off-by: Jason Gunthorpe
Jason Gunthorpe (2):
vfio: Replace the DMA unmapping notifier with a callback
vfio: Replace the iommu notifier
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
---
drivers/vfio/vfio.c | 41
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h| 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 75 ---
drivers/s390/cio/vfio_ccw_ops.c | 41 ++--
drivers/s390/cio/vfio_ccw_private.h | 2 -
drivers/s390/crypto/vfio_ap_ops.c
On Tue, Jun 28, 2022 at 10:54:58AM -0700, Kees Cook wrote:
> which must also be assuming it's a header. So probably better to just
> drop the driver_data field? I don't see anything using it (that I can
> find) besides as a sanity-check that the field exists and is at the end
> of the struct.
On Tue, Jun 28, 2022 at 04:21:29AM +0200, Gustavo A. R. Silva wrote:
> > > Though maybe we could just switch off
> > > -Wgnu-variable-sized-type-not-at-end during configuration ?
> We need to think in a different strategy.
I think we will need to switch off the warning in userspace - this is
On Mon, Jun 27, 2022 at 08:27:37PM +0200, Daniel Borkmann wrote:
> On 6/27/22 8:04 PM, Gustavo A. R. Silva wrote:
> > There is a regular need in the kernel to provide a way to declare
> > having a dynamically sized set of trailing elements in a structure.
> > Kernel code should always use
On Fri, Jun 24, 2022 at 01:12:56PM -0700, Nicolin Chen wrote:
> > The kmap_local_page() arose because the code doing memcpy had to be
> > updated to go from a struct page to a void * for use with memcpy and
> > the kmap_local_page() is the correct API to use for that.
> >
> > The existing code
On Fri, Jun 24, 2022 at 12:22:36PM -0700, Nicolin Chen wrote:
> On Fri, Jun 24, 2022 at 10:56:15AM -0300, Jason Gunthorpe wrote:
>
> > > How about the updated commit log below? Thanks.
> > >
> > > The pinned PFN list returned from vfio_pin_pages() is conver
On Tue, Jun 21, 2022 at 02:21:22PM -0700, Nicolin Chen wrote:
> On Sun, Jun 19, 2022 at 11:32:07PM -0700, Christoph Hellwig wrote:
> > On Sun, Jun 19, 2022 at 11:57:26PM -0300, Jason Gunthorpe wrote:
> > > The remark about io memory is because on s390 memcpy() will crash even
&
On Sun, Jun 19, 2022 at 11:32:07PM -0700, Christoph Hellwig wrote:
> > This helps because we now block io memory from ever getting into these
> > call paths. I'm pretty sure this is a serious security bug, but would
> > let the IBM folks remark as I don't know it all that well..
>
> Prevent as
On Sun, Jun 19, 2022 at 11:37:47PM -0700, Christoph Hellwig wrote:
> On Sun, Jun 19, 2022 at 10:51:47PM -0700, Christoph Hellwig wrote:
> > On Mon, Jun 20, 2022 at 12:00:46AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 17, 2022 at 01:54:05AM -0700, Chris
On Fri, Jun 17, 2022 at 01:54:05AM -0700, Christoph Hellwig wrote:
> There is a bunch of code an comments in the iommu type1 code that
> suggest we can pin memory that is not page backed.
AFAIK you can.. The whole follow_pte() mechanism allows raw PFNs to be
loaded into the type1 maps and the
On Fri, Jun 17, 2022 at 01:44:30AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 16, 2022 at 04:52:11PM -0700, Nicolin Chen wrote:
> > The pinned PFN list returned from vfio_pin_pages() is simply converted
> > using page_to_pfn() without protection, so direct access via memcpy()
> > will crash on
On Wed, Jun 08, 2022 at 11:50:31AM -0400, Eric Farman wrote:
> > --- a/drivers/s390/cio/vfio_ccw_private.h
> > +++ b/drivers/s390/cio/vfio_ccw_private.h
> > @@ -98,7 +98,6 @@ struct vfio_ccw_private {
> > struct completion *completion;
> > atomic_tavail;
> >
On Wed, Jun 08, 2022 at 03:47:12AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, June 8, 2022 7:02 AM
> >
> > Instead of bouncing the function call to the driver op through a blocking
> > notifier just have the iommu layer call it directly.
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
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915
-off-by: Jason Gunthorpe
Jason Gunthorpe (2):
vfio: Replace the DMA unmapping notifier with a callback
vfio: Replace the iommu notifier with a device list
drivers/gpu/drm/i915/gvt/gvt.h| 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 75 +-
drivers/s390/cio
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.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 42 -
drivers/vfio/vfio.h | 14 ++---
drivers
On Tue, Jun 07, 2022 at 08:57:52AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 07, 2022 at 07:39:55AM +0200, Christoph Hellwig wrote:
>
> > > +static int vfio_iommu_notifier(struct notifier_block *nb, unsigned long
> > > action,
> > > +vo
On Tue, Jun 07, 2022 at 07:39:55AM +0200, Christoph Hellwig wrote:
> > +static int vfio_iommu_notifier(struct notifier_block *nb, unsigned long
> > action,
> > + void *data)
> > +{
> > + struct vfio_device *vfio_device =
> > + container_of(nb, struct
On Tue, Jun 07, 2022 at 07:44:37AM +0200, Christoph Hellwig wrote:
> On Mon, Jun 06, 2022 at 09:34:36PM -0300, Jason Gunthorpe wrote:
> > + if (!list_empty(>device_list)) {
> > + mutex_lock(>device_list_lock);
> > +
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.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 39 -
drivers/vfio/vfio.h | 14 ++-
drivers
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
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h| 1
This is the last notifier toward the drivers, replace it with a simple op
callback in the vfio_device_ops.
Jason Gunthorpe (2):
vfio: Replace the DMA unmapping notifier with a callback
vfio: Replace the iommu notifier with a device list
drivers/gpu/drm/i915/gvt/gvt.h| 1 -
drivers
On Thu, May 12, 2022 at 05:33:44PM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 5/11/2022 1:50 PM, Jason Gunthorpe wrote:
> > On Thu, May 05, 2022 at 04:34:36PM -0500, Alex Sierra wrote:
> >
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > ind
On Thu, May 05, 2022 at 04:34:36PM -0500, Alex Sierra wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index 76e3af9639d9..892c4cc54dc2 100644
> +++ b/mm/memory.c
> @@ -621,6 +621,13 @@ struct page *vm_normal_page(struct vm_area_struct *vma,
> unsigned long addr,
> if
:
https://lore.kernel.org/r/0-v1-a8faf768d202+125dd-vfio_mdev_no_group_...@nvidia.com
Jason Gunthorpe (7):
vfio: Make vfio_(un)register_notifier accept a vfio_device
vfio/ccw: Remove mdev from struct channel_program
vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()
vfio
vfio_pin/unpin_pages().
Reviewed-by: Christoph Hellwig
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h | 4 ++--
drivers/vfio/vfio.c| 24 +++-
include/linux/vfio.h | 2 +-
3 files changed, 14 insertions
-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
--
FIXME: vfio_group_put_external_user() is removable too when combined with the
KVM series
---
drivers/vfio/vfio.c | 151 ---
include/linux/vfio.h | 11
2 files changed, 162 deletions(-)
diff --git a/drivers
The next patch wants the vfio_device instead. There is no reason to store
a pointer here since we can container_of back to the vfio_device.
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_cp.c | 47 -
drivers/s390/cio
() op to check device->open_count so always leave it elevated
while calling the op.
Reviewed-by: Christoph Hellwig
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 80 ++---
1 file changed, 17 insertions(+), 63 deleti
All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().
Acked-by: Eric Farman
Reviewed-by: Jason J. Herne
Reviewed-by: Tony Krowiak
Reviewed-by: Kevin Tian
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason
-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h | 1 -
drivers/gpu/drm/i915/gvt/kvmgt.c | 27 ++-
2 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 5a28ee965b7f3e..2af4c83e733c6c 100644
-by: Eric Farman
Reviewed-by: Jason J. Herne
Reviewed-by: Tony Krowiak
Reviewed-by: Kevin Tian
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 4 +-
drivers/s390/cio/vfio_ccw_cp.c| 6 +--
drivers/s390/crypto/vfio_ap_ops.c | 9
On Fri, Apr 29, 2022 at 02:28:20PM -0600, Alex Williamson wrote:
> On Thu, 21 Apr 2022 13:28:38 -0300
> Jason Gunthorpe wrote:
>
> > When the open_device() op is called the container_users is incremented and
> > held incremented until close_device(). Thus, so long as drive
On Thu, Apr 21, 2022 at 01:28:31PM -0300, Jason Gunthorpe wrote:
> Prior series have transformed other parts of VFIO from working on struct
> device or struct vfio_group into working directly on struct
> vfio_device. Based on that work we now have vfio_device's readily
> avai
On Tue, Apr 26, 2022 at 07:58:59AM +, Wang, Zhi A wrote:
> Hi folks:
>
> Here is the pull of gvt-next which fixs the compilation error when i915 debug
> is open after the GVT-g refactor patches.
>
> Thanks so much for the efforts.
>
> Thanks,
> Zhi.
>
> The following changes since commit
On Tue, Apr 26, 2022 at 08:42:25AM +, Wang, Zhi A wrote:
> On 4/26/22 8:37 AM, Jani Nikula wrote:
> > On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
> >> Hi folks:
> >>
> >> Here is the pull of gvt-next which fixs the compilation error when i915
> >> debug
> >> is open after the GVT-g refactor
On Sat, Apr 23, 2022 at 07:15:52AM +0200, Christoph Hellwig wrote:
> On Fri, Apr 22, 2022 at 05:56:51PM -0300, Jason Gunthorpe wrote:
> > On Fri, Apr 22, 2022 at 08:22:32AM +0200, Christoph Hellwig wrote:
> > > Nit: why do some of these patches that don't touch the md
On Fri, Apr 22, 2022 at 08:22:32AM +0200, Christoph Hellwig wrote:
> Nit: why do some of these patches that don't touch the mdev code
> mdev in the subject?
I consider these APIs to be 'mdev apis' because only mdev drivers
should call them.
Jason
On Fri, Apr 22, 2022 at 02:11:27AM +, Tian, Kevin wrote:
> > mutex_lock(>dev_set->lock);
> > - if (!--device->open_count && device->ops->close_device)
> > + vfio_assert_device_open(device);
> > + if (device->open_count == 1 && device->ops->close_device)
> >
On Fri, Apr 22, 2022 at 01:50:00AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, April 22, 2022 12:29 AM
> >
> > Every caller has a readily available vfio_device pointer, use that instead
> > of passing in a generic struct device.
On Fri, Apr 22, 2022 at 01:39:09AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, April 22, 2022 12:29 AM
> >
> > All callers have a struct vfio_device trivially available, pass it in
> > directly and avoid calling the exp
On Thu, Apr 21, 2022 at 05:32:32PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Here is the PR of gvt-next. Thanks so much for the patience.
>
> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting
> the GVT-g with the
> new MDEV interfaces:
>
> - Separating the MMIO table
-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h | 4 ++--
drivers/vfio/vfio.c| 24 +++-
include/linux/vfio.h | 2 +-
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
reason to use a group interface here, kvmgt has easy access to a
vfio_device.
Delete kvmgt_vdev::vfio_group since these calls were the last users.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.h | 1
.
Acked-by: Eric Farman
Reviewed-by: Jason J. Herne
Reviewed-by: Tony Krowiak
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 24
drivers/s390/cio/vfio_ccw_ops.c | 7 +++
drivers/s390/crypto/vfio_ap_ops.c | 14 +++---
drivers/vfio/vfio.c
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 78 +
1 file changed, 15 insertions(+), 63 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index ba6fae9ec7..b566ae3d320b36 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers
-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 151 ---
include/linux/vfio.h | 11
2 files changed, 162 deletions(-)
vfio_group_put_external_user() is removable too when combined with the KVM
series
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
-by: Eric Farman
Reviewed-by: Jason J. Herne
Reviewed-by: Tony Krowiak
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 4 +-
drivers/s390/cio/vfio_ccw_cp.c| 6 +--
drivers/s390/crypto/vfio_ap_ops.c | 9 ++---
drivers/vfio/vfio.c
The next patch wants the vfio_device instead. There is no reason to store
a pointer here since we can container_of back to the vfio_device.
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_cp.c | 47 -
drivers/s390/cio
301 - 400 of 1609 matches
Mail list logo
