On Sun, 21 Apr 2024 23:30:33 -0700
Vivek Kasireddy wrote:
> From 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 can now import dma-buf FDs and build them into MRs which all
On Wed, 6 Sep 2023 11:51:59 +0800
Sui Jingfeng wrote:
> Hi,
>
>
> On 2023/9/5 22:52, Alex Williamson wrote:
> > On Tue, 5 Sep 2023 03:57:15 +0800
> > Sui Jingfeng wrote:
> >
> >> From: Sui Jingfeng
> >>
> >> On a machine with multi
On Wed, 6 Sep 2023 00:21:09 +0800
suijingfeng wrote:
> Hi,
>
> On 2023/9/5 22:52, Alex Williamson wrote:
> > On Tue, 5 Sep 2023 03:57:15 +0800
> > Sui Jingfeng wrote:
> >
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GP
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> On a machine with multiple GPUs, a Linux user has no control over which
> one is primary at boot time. This series tries to solve above mentioned
> problem by introduced the ->be_primary() function stub. The specifi
On Thu, 31 Aug 2023 07:04:10 -0700
Christoph Hellwig wrote:
> On Thu, Aug 31, 2023 at 01:51:11PM +, Ankit Agrawal wrote:
> > Hi Christoph,
> >
> > >Whats the actual consumer running in a qemu VM here?
> > The primary use case in the VM is to run the open source Nvidia
> > driver (https:/
On Mon, 17 Jul 2023 19:12:16 -0300
Jason Gunthorpe wrote:
> On Mon, Jul 17, 2023 at 01:08:31PM -0600, Alex Williamson wrote:
>
> > What would that mechanism be? We've been iterating on getting the
> > serialization and buffering correct, but I don't know of another
On Mon, 17 Jul 2023 10:29:34 +0200
Grzegorz Jaszczyk wrote:
> pt., 14 lip 2023 o 09:05 Christian Brauner napisał(a):
> >
> > On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote:
> > > On Thu, 13 Jul 2023 12:05:36 +0200
> > > Christian Brauner wr
On Thu, 13 Jul 2023 12:05:36 +0200
Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> by removing the count argument which is effectively unused.
We have a patch under review which does in fact make use of the
signaling value:
On Thu, 26 Jan 2023 22:08:31 +0100
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> CONFIG_VFIO_MDEV cannot be selected when VFIO itself is
> disabled, otherwise we get a link failure:
>
> WARNING: unmet direct dependencies detected for VFIO_MDEV
> Depends on [n]: VFIO [=n]
> Selected by [y]
On Sat, 3 Dec 2022 17:12:38 -0700
"m...@lab.how" wrote:
> Hi,
>
> I hope it is ok to reply to this old thread.
It is, but the only relic of the thread is the subject. For reference,
the latest version of this posted is here:
https://lore.kernel.org/all/20220622140134.12763-4-tzimmerm...@suse.
On Fri, 4 Nov 2022 15:20:00 +0100
Eric Farman wrote:
> Hi Alex,
>
> Here's the (last?) update to the vfio-ccw lifecycle changes that I've sent
> recently, and were previously discussed at various points [1][2].
>
> Patches 1-5 rework the behavior of the vfio-ccw driver's private struct.
> In s
On Thu, 10 Nov 2022 06:57:57 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, November 10, 2022 3:53 AM
> >
> > On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
> >
> > > DPDK supports no-iommu mode.
On Tue, 8 Nov 2022 21:05:21 -0400
Jason Gunthorpe wrote:
> On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote:
>
> > > > So why exactly isn't this an issue for VDPA? Are we just burying our
> > > > head in the sand that such platforms exists an
On Tue, 8 Nov 2022 20:54:58 -0400
Jason Gunthorpe wrote:
> On Tue, Nov 08, 2022 at 03:28:31PM -0700, Alex Williamson wrote:
>
> > Perhaps this should have been obvious, but I'm realizing that
> > vfio-noiommu mode is completely missing without VFIO_CONTAINER, which
On Mon, 7 Nov 2022 14:45:59 -0400
Jason Gunthorpe wrote:
> On Mon, Nov 07, 2022 at 11:05:08AM -0700, Alex Williamson wrote:
>
> > After further consideration... I don't think the option on vfio-main
> > makes sense, basically for the same reason that the original option
&
On Mon, 7 Nov 2022 20:52:54 -0400
Jason Gunthorpe wrote:
> Add a kconfig CONFIG_VFIO_CONTAINER that controls compiling the container
> code. If 'n' then only iommufd will provide the container service. All the
> support for vfio iommu drivers, including type1, will not be built.
>
> This allows
On Mon, 7 Nov 2022 11:32:40 -0400
Jason Gunthorpe wrote:
> On Mon, Nov 07, 2022 at 08:18:53AM -0700, Alex Williamson wrote:
> > On Mon, 7 Nov 2022 09:19:43 -0400
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Oct 31, 2022 at 04:45:26PM -0600, Alex Williamson wrote
On Mon, 7 Nov 2022 09:19:43 -0400
Jason Gunthorpe wrote:
> On Mon, Oct 31, 2022 at 04:45:26PM -0600, Alex Williamson wrote:
>
> > > It is one idea, it depends how literal you want to be on "module
> > > parameters are ABI". IMHO it is a weak form of ABI and
elease directly.
Looks like another spin is pending, but the vfio core and collateral
changes in 6 and 7 look good to me. Would this go in through the vfio
or s390 tree? I'd be happy to merge or provide a branch, depending on
the route.
For 6 & 7:
Acked-by: Alex Williamson
Thanks,
Alex
> L
On Fri, 28 Oct 2022 15:44:36 -0300
Jason Gunthorpe wrote:
> On Wed, Oct 26, 2022 at 03:31:33PM -0600, Alex Williamson wrote:
> > On Tue, 25 Oct 2022 15:50:45 -0300
> > Jason Gunthorpe wrote:
> >
> > > If the VFIO container is compiled out, give a kconfig optio
On Fri, 28 Oct 2022 15:40:09 -0300
Jason Gunthorpe wrote:
> On Wed, Oct 26, 2022 at 03:24:42PM -0600, Alex Williamson wrote:
> > On Tue, 25 Oct 2022 15:17:10 -0300
> > Jason Gunthorpe wrote:
> >
> > > This legacy module knob has become uAPI, when set on the vfio
On Tue, 25 Oct 2022 15:50:45 -0300
Jason Gunthorpe wrote:
> If the VFIO container is compiled out, give a kconfig option for iommufd
> to provide the miscdev node with the same name and permissions as vfio
> uses.
>
> The compatibility node supports the same ioctls as VFIO and automatically
> en
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 23c24fe98c00d4..186e33a006d314 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -44,9 +44,8 @@
> #define DRIVER_AUTHOR "Alex Willia
On Thu, 6 Oct 2022 08:37:09 -0300
Jason Gunthorpe wrote:
> On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> > We can't have a .remove callback that does nothing, this breaks
> > removing the device while it's in use. Once we have the
> > vfio_u
On Wed, 5 Oct 2022 14:17:17 -0600
Alex Williamson wrote:
> On Thu, 29 Sep 2022 14:48:35 -0300
> Jason Gunthorpe wrote:
>
> > When converting to directly create the vfio_device the mdev driver has to
> > put a vfio_register_emulated_iommu_dev() in the
add it.
>
> Cc: sta...@vger.kernel.org
> Fixes: 978cf586ac35 ("drm/i915/gvt: convert to use
> vfio_register_emulated_iommu_dev")
> Reported-by: Alex Williamson
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
> 1 file change
add it.
>
> Cc: sta...@vger.kernel.org
> Fixes: 978cf586ac35 ("drm/i915/gvt: convert to use
> vfio_register_emulated_iommu_dev")
> Reported-by: Alex Williamson
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
> 1 file change
On Thu, 29 Sep 2022 14:49:56 -0300
Jason Gunthorpe wrote:
> On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > Hi Kevin,
> >
> > This introduced the regression discovered here:
> >
> > https://lore.kernel.org/all/20220928125650.0a
Hi Kevin,
This introduced the regression discovered here:
https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/
Seems we're not releasing the resources when removing an mdev. This is
a regression, so it needs to be fixed or reverted before the merge
window. Thanks,
A
On Wed, 21 Sep 2022 18:43:46 +0800
Kevin Tian wrote:
> The idea is to let vfio core manage the vfio_device life cycle instead
> of duplicating the logic cross drivers. Besides cleaner code in driver
> side this also allows adding struct device to vfio_device as the first
> step toward adding cdev
On Fri, 9 Sep 2022 18:22:47 +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
> driver, e.g.:
>
> /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
>
> It
On Fri, 9 Sep 2022 18:22:38 +0800
Kevin Tian wrote:
> From: Yi Liu
>
> and manage available ports inside @init/@release.
>
> Signed-off-by: Yi Liu
> Signed-off-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> ---
> samples/vfio-mdev/mtty.c | 67 +++-
> 1
On Thu, 1 Sep 2022 00:46:51 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, September 1, 2022 1:15 AM
> >
> > On Wed, 31 Aug 2022 06:10:51 +
> > "Tian, Kevin" wrote:
> >
> > > > Fro
On Wed, 31 Aug 2022 06:10:51 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, August 31, 2022 7:53 AM
> >
> > On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote:
> > > On Sun, 28 Aug 2022 01:10:37 +0800
> &
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
> driver, e.g.:
>
> /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
>
> It
On Thu, 18 Aug 2022 09:05:24 -0300
Jason Gunthorpe wrote:
> 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 impo
On Thu, 7 Apr 2022 03:19:43 -0400
Zhi Wang wrote:
> From: Zhi Wang
>
> To support the new mdev interfaces and the re-factor patches from
> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> MMIO tracking table needs to be separated from GVT-g.
>
Since this commit I'm
On Fri, 22 Jul 2022 19:02:46 -0700
Nicolin Chen wrote:
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
>
> There's a gap between these two versions: the vfio_iommu_type1 version
On Fri, 22 Jul 2022 17:38:25 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 06:18:00PM -0600, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Fri, 22 Jul 2022 16:12:19 -0700
> > Nicolin Chen wrote:
> &
On Fri, 22 Jul 2022 16:12:19 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
>
> > GVT-g explodes for me with this series on my Broadwell test system,
> > continuously spewing the following:
>
> Thank you for
On Tue, 19 Jul 2022 21:02:47 -0300
Jason Gunthorpe wrote:
> This is the last notifier toward the drivers, replace it with a simple op
> callback in the vfio_device_ops.
>
> v4:
> - Rebase over the CCW series
> v3:
> https://lore.kernel.org/r/0-v3-7593f297c43f+56ce-vfio_unmap_notif_...@nvidia.c
On Fri, 8 Jul 2022 15:44:18 -0700
Nicolin Chen wrote:
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
>
> There's a gap between these two versions: the vfio_iommu_type1 version
>
On Thu, 21 Jul 2022 12:01:47 -0400
Eric Farman wrote:
> On Wed, 2022-07-20 at 17:04 -0600, Alex Williamson wrote:
> > On Wed, 20 Jul 2022 17:08:29 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote:
>
On Wed, 20 Jul 2022 17:08:29 -0300
Jason Gunthorpe wrote:
> 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&#
On Tue, 19 Jul 2022 21:02:48 -0300
Jason Gunthorpe wrote:
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index a7d2a95796d360..bb1a1677c5c230 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1226,34 +1226,14
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
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -44,31 +44,19 @@ static int
On Tue, 21 Jun 2022 13:01:08 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 17.06.22 um 16:12 schrieb Alex Williamson:
> > On Fri, 17 Jun 2022 14:41:01 +0200
> > Thomas Zimmermann wrote:
> >
> >> Hi
> >>
> >> Am 17.06.22 um 14:29 schrieb J
On Tue, 7 Jun 2022 20:02:12 -0300
Jason Gunthorpe wrote:
> 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 the
On Fri, 17 Jun 2022 16:42:30 -0600
Alex Williamson wrote:
> On Tue, 7 Jun 2022 20:02:11 -0300
> Jason Gunthorpe wrote:
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index 61e71c1154be67..f005b644ab9e69 100644
> > --- a/drivers/vfio/vfio.c
>
On Tue, 7 Jun 2022 20:02:11 -0300
Jason Gunthorpe wrote:
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 61e71c1154be67..f005b644ab9e69 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1077,8 +1077,20 @@ static void vfio_device_unassign_container(struct
> vfi
On Fri, 17 Jun 2022 14:41:01 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 17.06.22 um 14:29 schrieb Javier Martinez Canillas:
> > [adding Zack and Alex to Cc list]
> >
> > Hello Thomas,
> >
> > Thanks a lot for tracking this down and figuring out the root cause!
> >
> > On 6/17/22 14:10, Thomas
Suggested-by: Gerd Hoffmann
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index a0d69ddaf90d..5b2a6e9f7cf7 100644
--- a/drivers/vfio/pci
re drivers within
DRM and fbdev, and the VGA text-console driver.
The original DRM interface is kept in place for use by DRM drivers.
Signed-off-by: Thomas Zimmermann
Signed-off-by: Alex Williamson
---
Documentation/driver-api/aperture.rst | 13 +
Documentation/driver-api/index.rst|1
el.org/all/165453797543.3592816.6381793341352595461.stgit@omen/
---
Alex Williamson (1):
vfio/pci: Remove console drivers
Thomas Zimmermann (1):
drm: Implement DRM aperture helpers under video/
Documentation/driver-api/aperture.rst | 13 +
Documentation/driver-api/index.rst| 1 +
drivers/gpu/drm/drm_aperture.c
On Fri, 10 Jun 2022 09:03:15 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 09.06.22 um 23:44 schrieb Alex Williamson:
> > On Thu, 9 Jun 2022 15:41:02 -0600
> > Alex Williamson wrote:
> >
> >> On Thu, 9 Jun 2022 11:13:22 +0200
> >> Thomas Zimmerman
On Thu, 9 Jun 2022 15:41:02 -0600
Alex Williamson wrote:
> On Thu, 9 Jun 2022 11:13:22 +0200
> Thomas Zimmermann wrote:
> >
> > Please have a look at the attached patch. It moves the aperture helpers
> > to a location common to the various possible users (DRM, fb
On Thu, 9 Jun 2022 11:13:22 +0200
Thomas Zimmermann wrote:
>
> Please have a look at the attached patch. It moves the aperture helpers
> to a location common to the various possible users (DRM, fbdev, vfio).
> The DRM interfaces remain untouched for now. The patch should provide
> what you ne
Hi Thomas,
On Wed, 8 Jun 2022 13:11:21 +0200
Thomas Zimmermann wrote:
> Hi Alex
>
> Am 06.06.22 um 19:53 schrieb Alex Williamson:
> > Console drivers can create conflicts with PCI resources resulting in
> > userspace getting mmap failures to memory BARs. This is especi
On Tue, 7 Jun 2022 19:40:40 +0200
Javier Martinez Canillas wrote:
> Hello Alex,
>
> On 6/6/22 19:53, Alex Williamson wrote:
> > Users attempting to enable vfio PCI device assignment with a GPU will
> > often block the default PCI driver from the device to avoid conflict
initialization.
Reported-by: Laszlo Ersek
Tested-by: Laszlo Ersek
Suggested-by: Gerd Hoffmann
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_core.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
split out and export the necessary DRM apterture support and
mirror the framebuffer and VGA support.
I'd be happy to pull this series in through the vfio branch if
approved by the DRM maintainers. Thanks,
Alex
---
Alex Williamson (2):
drm/aperture: Split conflicting platform driver re
features.
Reported-by: Laszlo Ersek
Tested-by: Laszlo Ersek
Suggested-by: Gerd Hoffmann
Signed-off-by: Alex Williamson
---
drivers/gpu/drm/drm_aperture.c | 33 -
include/drm/drm_aperture.h |2 ++
2 files changed, 26 insertions(+), 9 deletions(-)
diff
On Thu, 5 May 2022 21:08:38 -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
> available in all the drivers.
>
On Fri, 29 Apr 2022 14:31:49 -0300
Jason Gunthorpe wrote:
> 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
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 drivers call
> functions within their open_device()/close_device() region they do not
> need to worry ab
On Thu, 28 Apr 2022 15:35:58 -0600
Alex Williamson wrote:
> On Tue, 26 Apr 2022 08:52:58 -0300
> Jason Gunthorpe wrote:
>
> > On Tue, Apr 26, 2022 at 08:42:25AM +, Wang, Zhi A wrote:
> > > On 4/26/22 8:37 AM, Jani Nikula wrote:
> > > > On Tu
On Tue, 26 Apr 2022 08:52:58 -0300
Jason Gunthorpe wrote:
> 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 compi
On Wed, 20 Apr 2022 13:43:51 -0300
Jason Gunthorpe wrote:
> On Wed, Apr 20, 2022 at 04:34:47PM +, 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
> > th
On Fri, 10 Sep 2021 10:38:50 -0300
Jason Gunthorpe wrote:
> On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> > On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> > > Every driver just emits a static string, simply feed it through the ops
> > > and provide a s
On Thu, 5 Aug 2021 22:18:56 -0300
Jason Gunthorpe wrote:
> This is in support of Max's series to split vfio-pci. For that to work the
> reflck concept embedded in vfio-pci needs to be sharable across all of the
> new VFIO PCI drivers which motivated re-examining how this is
> implemented.
>
> A
On Thu, 5 Aug 2021 08:47:01 -0300
Jason Gunthorpe wrote:
> On Tue, Aug 03, 2021 at 10:52:25AM -0600, Alex Williamson wrote:
> > On Tue, 3 Aug 2021 13:41:52 -0300
> > Jason Gunthorpe wrote:
> > > On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrot
On Tue, 3 Aug 2021 13:41:52 -0300
Jason Gunthorpe wrote:
> On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrote:
> > I think the vfio_pci_find_reset_target() function needs to be re-worked
> > to just tell us true/false that it's ok to reset the provided device,
On Wed, 28 Jul 2021 21:49:18 -0300
Jason Gunthorpe wrote:
> Keep track of all the vfio_devices that have been added to the device set
> and use this list in vfio_pci_try_bus_reset() instead of trying to work
> backwards from the pci_device.
>
> The dev_set->lock directly prevents devices from jo
On Tue, 20 Jul 2021 19:49:55 -0300
Jason Gunthorpe wrote:
> On Tue, Jul 20, 2021 at 04:01:27PM -0600, Alex Williamson wrote:
> > On Tue, 20 Jul 2021 14:42:48 -0300
> > Jason Gunthorpe wrote:
> >
> > > Compared to mbochs_remove() two cases are missing from the
On Tue, 20 Jul 2021 14:42:48 -0300
Jason Gunthorpe wrote:
> Compared to mbochs_remove() two cases are missing from the
> vfio_register_group_dev() unwind. Add them in.
>
> Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()")
> Reported-by: Cornelia Huck
> Signed-off-by:
On Thu, 15 Jul 2021 19:11:49 -0300
Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 03:00:55PM -0600, Alex Williamson wrote:
> > On Wed, 14 Jul 2021 21:20:38 -0300
> > Jason Gunthorpe wrote:
> > > +/*
> > > + * We need to get memory_lock for each device, but d
On Wed, 14 Jul 2021 21:20:38 -0300
Jason Gunthorpe wrote:
> +/*
> + * We need to get memory_lock for each device, but devices can share
> mmap_lock,
> + * therefore we need to zap and hold the vma_lock for each device, and only
> then
> + * get each memory_lock.
> + */
> +static int vfio_hot_res
On Tue, 22 Jun 2021 21:05:50 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 17, 2021 at 04:22:08PM +0200, Christoph Hellwig wrote:
> > This is my alternative take on this series from Jason:
> >
> > https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
> >
> > The mdev/vfio parts are exactl
On Tue, 15 Jun 2021 15:35:13 +0200
Christoph Hellwig wrote:
> @@ -547,10 +538,9 @@ static int call_driver_probe(struct device *dev, struct
> device_driver *drv)
>
> static int really_probe(struct device *dev, struct device_driver *drv)
> {
> - int local_trigger_count = atomic_read(&defer
On Tue, 15 Jun 2021 15:35:09 +0200
Christoph Hellwig wrote:
> This is my alternative take on this series from Jason:
>
> https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
>
> The mdev/vfio parts are exactly the same, but this solves the driver core
> changes for the direct probing
On Tue, 4 May 2021 16:11:31 +0200
Greg Kurz wrote:
> On Tue, 4 May 2021 15:30:15 +0200
> Greg Kroah-Hartman wrote:
>
> > On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> > > On Tue, 4 May 2021 14:59:07 +0200
> > > Greg Kroah-Hartman wrote:
> > >
> > > > On Tue, May 04, 2021 at
On Tue, 27 Apr 2021 19:20:26 -0300
Jason Gunthorpe wrote:
> On Tue, Apr 27, 2021 at 03:30:42PM -0600, Alex Williamson wrote:
>
> > It'd be really helpful if you could consistently copy at least one
> > list, preferably one monitored by patchwork, for an entire serie
On Mon, 26 Apr 2021 17:00:02 -0300
Jason Gunthorpe wrote:
> The mdev bus's core part for managing the lifecycle of devices is mostly
> as one would expect for a driver core bus subsystem.
>
> However instead of having a normal 'struct device_driver' and binding the
> actual mdev drivers through
On Fri, 23 Apr 2021 09:07:09 -0300
Jason Gunthorpe wrote:
> On Fri, Apr 23, 2021 at 11:54:26AM +0800, Zhenyu Wang wrote:
> > On 2021.04.22 10:58:10 -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 22, 2021 at 03:35:33PM +0200, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > > >
> > > >
On Thu, 15 Apr 2021 10:08:55 -0300
Jason Gunthorpe wrote:
> On Thu, Apr 15, 2021 at 04:47:34PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the vfio tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gvt/gvt.c
> >
> > between commit:
> >
> > 9ff06c38530
On Tue, 6 Apr 2021 16:40:23 -0300
Jason Gunthorpe wrote:
> vfio_mdev has a number of different objects: mdev_parent, mdev_type and
> mdev_device.
>
> Unfortunately the types of these have been erased in various places
> throughout the API, and this makes it very hard to understand this code or
On Mon, 12 Apr 2021 19:41:41 +1000
Michael Ellerman wrote:
> Alex Williamson writes:
> > On Fri, 26 Mar 2021 07:13:10 +0100
> > Christoph Hellwig wrote:
> >
> >> This driver never had any open userspace (which for VFIO would include
> >> VM kernel driv
On Fri, 26 Mar 2021 07:13:10 +0100
Christoph Hellwig wrote:
> This driver never had any open userspace (which for VFIO would include
> VM kernel drivers) that use it, and thus should never have been added
> by our normal userspace ABI rules.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Greg
On Mon, 22 Mar 2021 16:01:54 +0100
Christoph Hellwig wrote:
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 8ce36c1d53ca11..db7e782419d5d9 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -332,19 +332,6 @@ struct vfio_region_info_cap_type
On Mon, 4 Jan 2021 21:13:53 +0100
Christian König wrote:
> Am 04.01.21 um 19:43 schrieb Alex Williamson:
> > On Mon, 4 Jan 2021 18:39:33 +0100
> > Christian König wrote:
> >
> >> Am 04.01.21 um 17:45 schrieb Alex Williamson:
> >>> On Mon, 4 Jan
On Mon, 4 Jan 2021 18:39:33 +0100
Christian König wrote:
> Am 04.01.21 um 17:45 schrieb Alex Williamson:
> > On Mon, 4 Jan 2021 12:34:34 +0100
> > Christian König wrote:
> >
> >> Hi Maxim,
> >>
> >> I can't help with the display related
On Mon, 4 Jan 2021 12:34:34 +0100
Christian König wrote:
> Hi Maxim,
>
> I can't help with the display related stuff. Probably best approach to
> get this fixes would be to open up a bug tracker for this on FDO.
>
> But I'm the one who implemented the resizeable BAR support and your
> analysi
> 1 file changed, 8 insertions(+), 29 deletions(-)
Thanks!
Acked-by: Alex Williamson
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 765e0e5d83ed9..33a88103f857f 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1451,42 +1451,21 @@ static
ged, 27 insertions(+), 30 deletions(-)
Tested with device assignment and Intel mdev vGPU assignment with QEMU
userspace:
Tested-by: Alex Williamson
Acked-by: Alex Williamson
Feel free to include for 19/24 as well. Thanks,
Alex
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio
On Wed, 6 Nov 2019 14:50:30 -0800
Randy Dunlap wrote:
> On 11/5/19 11:05 PM, Jason Wang wrote:
> > diff --git a/samples/Kconfig b/samples/Kconfig
> > index c8dacb4dda80..13a2443e18e0 100644
> > --- a/samples/Kconfig
> > +++ b/samples/Kconfig
> > @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY
>
On Wed, 6 Nov 2019 14:25:23 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson wrote:
> > On Wed, 6 Nov 2019 11:56:46 +0800
> > Jason Wang wrote:
> >
> > > On 2019/11/6 上午1:58, Alex Williamson wrote:
&g
On Wed, 6 Nov 2019 11:56:46 +0800
Jason Wang wrote:
> On 2019/11/6 上午1:58, Alex Williamson wrote:
> > On Tue, 5 Nov 2019 17:32:34 +0800
> > Jason Wang wrote:
> >
> >> Hi all:
> >>
> >> There are hardwares that can do virtio datapath offload
On Tue, 5 Nov 2019 17:32:34 +0800
Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is done
On Tue, 5 Nov 2019 17:32:38 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c| 21 +
> drivers/vfio/mdev/mdev_private.h | 2 +
>
On Tue, 5 Nov 2019 17:50:25 +0100
Cornelia Huck wrote:
> On Tue, 5 Nov 2019 17:32:37 +0800
> Jason Wang wrote:
>
> > Currently, except for the create and remove, the rest of
> > mdev_parent_ops is designed for vfio-mdev driver only and may not help
> > for kernel mdev driver. With the help of
1 - 100 of 185 matches
Mail list logo
