On Thu, 10 Apr 2025 15:04:35 -0700
Sean Christopherson wrote:
> On Thu, Apr 10, 2025, Alex Williamson wrote:
> > The "token" terminology seems a little out of place after all is said
> > and done in this series.
>
> Ugh, yeah, good point. I don't know why
On Fri, 4 Apr 2025 14:14:45 -0700
Sean Christopherson wrote:
> diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
> index 9bdb2a781841..379725b9a003 100644
> --- a/include/linux/irqbypass.h
> +++ b/include/linux/irqbypass.h
> @@ -10,6 +10,7 @@
>
> #include
>
> +struct eventf
On Tue, 20 Feb 2024 17:20:52 +0530
wrote:
> From: Ankit Agrawal
>
> NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device
> for the on-chip GPU that is the logical OS representation of the
> internal proprietary chip-to-chip cache coherent interconnect.
>
> The device is peculiar
On Fri, 9 Feb 2024 13:19:03 -0400
Jason Gunthorpe wrote:
> On Fri, Feb 09, 2024 at 08:55:31AM -0700, Alex Williamson wrote:
> > I think Kevin's point is also relative to this latter scenario, in the
> > L1 instance of the nvgrace-gpu driver the mmap of the usemem BAR is
>
On Fri, 9 Feb 2024 09:20:22 +
Ankit Agrawal wrote:
> Thanks Kevin for the review. Comments inline.
>
> >>
> >> Note that the usemem memory is added by the VM Nvidia device driver [5]
> >> to the VM kernel as memblocks. Hence make the usable memory size
> >> memblock
> >> aligned.
> >
> > I
On Thu, 8 Feb 2024 07:21:40 +
"Tian, Kevin" wrote:
> > From: Ankit Agrawal
> > Sent: Thursday, February 8, 2024 3:13 PM
> > >> > + * Determine how many bytes to be actually read from the
> > >> > device memory.
> > >> > + * Read request beyond the actual device memory size is
> > >>
On Tue, 6 Feb 2024 04:31:23 +0530
wrote:
> From: Ankit Agrawal
>
> NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device
> for the on-chip GPU that is the logical OS representation of the
> internal proprietary chip-to-chip cache coherent interconnect.
>
> The device is peculiar
On Thu, 8 Feb 2024 00:32:10 +0200
Zhi Wang wrote:
> On Tue, 6 Feb 2024 04:31:23 +0530
> wrote:
>
> > From: Ankit Agrawal
> >
> > NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device
> > for the on-chip GPU that is the logical OS representation of the
> > internal proprietary ch
On Tue, 9 Jan 2024 08:57:19 +0100
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The new vfio-virtio driver already has a dependency on
> VIRTIO_PCI_ADMIN_LEGACY,
> but that is a bool symbol and allows vfio-virtio to be built-in even if
> virtio-pci itself is a loadable module. This leads to
On Tue, 20 Apr 2021 09:59:57 -0300
Jason Gunthorpe wrote:
> On Tue, Apr 20, 2021 at 08:50:12PM +0800, liulongfang wrote:
> > On 2021/4/19 20:33, Jason Gunthorpe wrote:
> > > On Mon, Apr 19, 2021 at 08:24:40PM +0800, liulongfang wrote:
> > >
> > >>> I'm also confused how this works securely a
On Fri, 16 Apr 2021 06:12:58 -0700
Jacob Pan wrote:
> Hi Jason,
>
> On Thu, 15 Apr 2021 20:07:32 -0300, Jason Gunthorpe wrote:
>
> > On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
> > > Hi Jason,
> > >
> > > On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
> > > > On Thu, Apr 01,
[Cc+ NVIDIA folks both from migration and vfio-pci-core discussion]
On Tue, 13 Apr 2021 11:36:20 +0800
Longfang Liu wrote:
> The live migration solution relies on the vfio_device_migration_info protocol.
> The structure vfio_device_migration_info is placed at the 0th offset of
> the VFIO_REGION_
On Tue, 13 Apr 2021 17:14:45 +0800
Keqian Zhu wrote:
> From: Kunkun Jiang
>
> In the past, we clear dirty log immediately after sync dirty
> log to userspace. This may cause redundant dirty handling if
> userspace handles dirty log iteratively:
>
> After vfio clears dirty log, new dirty log st
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
d it to resolve an issue during link retraining to a
higher speed on boot, not during a bus reset. Pali can correct if I'm
wrong. Thanks,
Alex
> Am 15.04.2021 um 04:36 schrieb Alex Williamson:
> > On Wed, 14 Apr 2021 16:03:50 -0500
> > Bjorn Helgaas wrote:
> >
&
On Wed, 14 Apr 2021 16:03:50 -0500
Bjorn Helgaas wrote:
> [+cc Alex]
>
> On Fri, Apr 09, 2021 at 11:26:33AM +0200, Ingmar Klein wrote:
> > Edit: Retry, as I did not consider, that my mail-client would make this
> > party html.
> >
> > Dear maintainers,
> > I recently encountered an issue on my
Hi Linus,
Sorry for the late request.
The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef:
Linux 5.12-rc7 (2021-04-11 15:16:13 -0700)
are available in the Git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v5.12-rc8
for you to fetch changes up to
On Mon, 12 Apr 2021 10:44:15 +0800
Keqian Zhu wrote:
> pinned_page_dirty_scope is optimized out by commit 010321565a7d
> ("vfio/iommu_type1: Mantain a counter for non_pinned_groups"),
> but appears again due to some issues during merging branches.
> We can safely remove it here.
>
> Signed-off-b
On Mon, 12 Apr 2021 10:32:14 -0600
Alex Williamson wrote:
> Running a Windows guest on a i915-GVTg_V4_2 from an HD 5500 IGD on
> v5.12-rc6 results in host logs:
>
> gvt: vgpu 1: lrm access to register (20c0)
> gvt: vgpu 1: MI_LOAD_REGISTER_MEM handler error
> gvt: vgpu 1: cmd
Running a Windows guest on a i915-GVTg_V4_2 from an HD 5500 IGD on
v5.12-rc6 results in host logs:
gvt: vgpu 1: lrm access to register (20c0)
gvt: vgpu 1: MI_LOAD_REGISTER_MEM handler error
gvt: vgpu 1: cmd parser error
0x0
0x29
gvt: vgpu 1: scan wa ctx error
gvt: vgpu 1: failed to submit des
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, 9 Apr 2021 04:54:23 +
"Zengtao (B)" wrote:
> > -邮件原件-----
> > 发件人: Alex Williamson [mailto:alex.william...@redhat.com]
> > 发送时间: 2021年3月9日 5:47
> > 收件人: alex.william...@redhat.com
> > 抄送: coh...@redhat.com; k...@vger.kernel.org;
> >
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 Tue, 6 Apr 2021 21:50:09 +0800
Shenming Lu wrote:
> The check i > npage at the end of vfio_iommu_type1_unpin_pages is unused
> unless npage < 0, but if npage < 0, this function will return npage, which
> should return -EINVAL instead. So let's just check the parameter npage at
> the start of t
On Fri, 26 Mar 2021 16:35:24 +0800
Zhen Lei wrote:
> This detection and correction covers the entire driver/vfio directory.
>
> Zhen Lei (4):
> vfio/type1: fix a couple of spelling mistakes
> vfio/mdev: Fix spelling mistake "interal" -> "internal"
> vfio/pci: fix a couple of spelling mista
On Sun, 14 Mar 2021 10:59:25 +0530
Bhaskar Chowdhury wrote:
> s/permision/permission/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/vfio/pci/vfio_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> i
On Sun, 4 Apr 2021 11:04:32 +0300
Leon Romanovsky wrote:
> On Thu, Apr 01, 2021 at 10:56:16AM -0600, Alex Williamson wrote:
> > On Thu, 1 Apr 2021 15:27:37 +0300
> > Leon Romanovsky wrote:
> >
> > > On Thu, Apr 01, 2021 at 05:37:16AM +, Raphael Norwitz wr
On Thu, 1 Apr 2021 10:12:27 -0300
Jason Gunthorpe wrote:
> On Mon, Mar 29, 2021 at 05:10:53PM -0600, Alex Williamson wrote:
> > On Tue, 23 Mar 2021 16:32:13 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Mar 22, 2021 at 10:40:16AM -0600, Alex Williamson wro
hen
> > attempts a bus reset if -ENOTTY is returned, such that there is now a
> > single device agnostic function to perform an SBR.
> >
> > This new function is also needed to add SBR reset quirks and therefore
> > is exposed in pci.h.
> >
> > Link: https
Hi Linus,
The following changes since commit 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b:
Linux 5.12-rc4 (2021-03-21 14:56:43 -0700)
are available in the Git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v5.12-rc6
for you to fetch changes up to e0146a108ce4d2c22b9510fd1226
On Tue, 23 Mar 2021 16:32:13 -0300
Jason Gunthorpe wrote:
> On Mon, Mar 22, 2021 at 10:40:16AM -0600, Alex Williamson wrote:
>
> > Of course if you start looking at features like migration support,
> > that's more than likely not simply an additional region with optio
On Fri, 26 Mar 2021 09:40:30 +0300
Leon Romanovsky wrote:
> On Thu, Mar 25, 2021 at 11:53:24AM -0600, Alex Williamson wrote:
> > On Thu, 25 Mar 2021 18:09:58 +0200
> > Leon Romanovsky wrote:
> >
> > > On Thu, Mar 25, 2021 at 08:55:04AM -0600, Alex Williamson w
result in occasional false positives but keeps the
> code simpler.
>
> Fixes: 4d83de6da265 ("vfio/type1: Batch page pinning")
> Link: https://lkml.kernel.org/r/20210323133254.33ed9...@omen.home.shazbot.org/
> Reported-by: Alex Williamson
> Suggested-by: Alex Williamson
>
On Thu, 25 Mar 2021 18:09:58 +0200
Leon Romanovsky wrote:
> On Thu, Mar 25, 2021 at 08:55:04AM -0600, Alex Williamson wrote:
> > On Thu, 25 Mar 2021 10:37:54 +0200
> > Leon Romanovsky wrote:
> >
> > > On Wed, Mar 24, 2021 at 11:17:29AM -0600, Alex Williamson w
On Thu, 25 Mar 2021 10:37:54 +0200
Leon Romanovsky wrote:
> On Wed, Mar 24, 2021 at 11:17:29AM -0600, Alex Williamson wrote:
> > On Wed, 24 Mar 2021 17:13:56 +0200
> > Leon Romanovsky wrote:
>
> <...>
>
> > > Yes, and real testing/debuggin
On Wed, 24 Mar 2021 17:13:56 +0200
Leon Romanovsky wrote:
> On Wed, Mar 24, 2021 at 08:37:43AM -0600, Alex Williamson wrote:
> > On Wed, 24 Mar 2021 12:03:00 +0200
> > Leon Romanovsky wrote:
> >
> > > On Mon, Mar 22, 2021 at 11:10:03AM -0600, Alex Williamson w
On Wed, 24 Mar 2021 12:03:00 +0200
Leon Romanovsky wrote:
> On Mon, Mar 22, 2021 at 11:10:03AM -0600, Alex Williamson wrote:
> > On Sun, 21 Mar 2021 10:40:55 +0200
> > Leon Romanovsky wrote:
> >
> > > On Sat, Mar 20, 2021 at 08:59:42AM -0600, Alex Williamson w
On Tue, 23 Mar 2021 18:25:45 -0400
Daniel Jordan wrote:
> Hi Alex,
>
> Alex Williamson writes:
> > I've found a bug in this patch that we need to fix. The diff is a
> > little difficult to follow,
>
> It was an awful diff, I remember...
>
> > so
Hi Daniel,
I've found a bug in this patch that we need to fix. The diff is a
little difficult to follow, so I'll discuss it in the resulting
function below...
(1) Imagine the user has passed a vaddr range that alternates pfnmaps
and pinned memory per page.
static long vfio_pin_pages_remote(str
On Tue, 23 Mar 2021 10:06:25 -0600
Alex Williamson wrote:
> On Tue, 23 Mar 2021 21:02:21 +0530
> Amey Narkhede wrote:
>
> > On 21/03/23 08:44AM, Alex Williamson wrote:
> > > On Tue, 23 Mar 2021 15:34:19 +0100
> > > Pali Rohár wrote:
> > >
>
On Tue, 23 Mar 2021 21:02:21 +0530
Amey Narkhede wrote:
> On 21/03/23 08:44AM, Alex Williamson wrote:
> > On Tue, 23 Mar 2021 15:34:19 +0100
> > Pali Rohár wrote:
> >
> > > On Thursday 18 March 2021 20:01:55 Amey Narkhede wrote:
> > > > On 21/03/17
On Tue, 23 Mar 2021 15:34:19 +0100
Pali Rohár wrote:
> On Thursday 18 March 2021 20:01:55 Amey Narkhede wrote:
> > On 21/03/17 09:13PM, Pali Rohár wrote:
> > > On Wednesday 17 March 2021 14:00:20 Alex Williamson wrote:
> > > > On Wed, 17 Mar 2021 20:40:24 +
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 Sun, 21 Mar 2021 10:40:55 +0200
Leon Romanovsky wrote:
> On Sat, Mar 20, 2021 at 08:59:42AM -0600, Alex Williamson wrote:
> > On Sat, 20 Mar 2021 11:10:08 +0200
> > Leon Romanovsky wrote:
> > > On Fri, Mar 19, 2021 at 10:23:13AM -0600, Alex Williamson wrote:
>
On Sun, 21 Mar 2021 09:58:18 -0300
Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 10:40:28PM -0600, Alex Williamson wrote:
>
> > > Well, today we don't, but Max here adds id_table's to the special
> > > devices and a MODULE_DEVICE_TABLE would come too if we
On Sat, 20 Mar 2021 11:10:08 +0200
Leon Romanovsky wrote:
> On Fri, Mar 19, 2021 at 10:23:13AM -0600, Alex Williamson wrote:
> >
> > What if we taint the kernel or pci_warn() for cases where either all
> > the reset methods are disabled, ie. 'echo none > reset_meth
On Fri, 19 Mar 2021 19:59:43 -0300
Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 03:08:09PM -0600, Alex Williamson wrote:
> > On Fri, 19 Mar 2021 17:07:49 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Fri, Mar 19, 2021 at 11:36:42AM -0600, Alex Williamson w
On Wed, 10 Mar 2021 07:56:39 +
Christoph Hellwig wrote:
> On Mon, Mar 08, 2021 at 02:48:30PM -0700, Alex Williamson wrote:
> > Using a vfio device, a notifier block can be registered to receive
> > select device events. Notifiers can only be registered for contained
> &
On Fri, 19 Mar 2021 17:07:49 -0300
Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 11:36:42AM -0600, Alex Williamson wrote:
> > On Fri, 19 Mar 2021 17:34:49 +0100
> > Christoph Hellwig wrote:
> >
> > > On Fri, Mar 19, 2021 at 01:28:48PM -0300, Jason Gunthorpe
On Fri, 19 Mar 2021 17:34:49 +0100
Christoph Hellwig wrote:
> On Fri, Mar 19, 2021 at 01:28:48PM -0300, Jason Gunthorpe wrote:
> > The wrinkle I don't yet have an easy answer to is how to load vfio_pci
> > as a universal "default" within the driver core lazy bind scheme and
> > still have working
On Fri, 19 Mar 2021 14:59:47 +0200
Leon Romanovsky wrote:
> On Thu, Mar 18, 2021 at 07:34:56PM +0100, Enrico Weigelt, metux IT consult
> wrote:
> > On 18.03.21 18:22, Leon Romanovsky wrote:
> >
> > > Which email client do you use?
> > > Your responses are grouped as one huge block without any
On Wed, 10 Mar 2021 14:57:57 +0200
Max Gurtovoy wrote:
> On 3/10/2021 8:39 AM, Alexey Kardashevskiy wrote:
> > On 09/03/2021 19:33, Max Gurtovoy wrote:
> >> +static const struct pci_device_id nvlink2gpu_vfio_pci_table[] = {
> >> + { PCI_VDEVICE(NVIDIA, 0x1DB1) }, /* GV100GL-A NVIDIA Tesla
>
Hi Linus,
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v5.12-rc4
for you to fetch changes up to 4ab4fcfce5b540227d80eb32f1db
On Thu, 18 Mar 2021 11:09:34 +0200
Leon Romanovsky wrote:
> On Wed, Mar 17, 2021 at 11:31:40AM -0600, Alex Williamson wrote:
> > On Wed, 17 Mar 2021 15:58:40 +0200
> > Leon Romanovsky wrote:
> >
> > > On Wed, Mar 17, 2021 at 06:47:18PM +0530, Amey Narkhede wrote:
On Wed, 17 Mar 2021 20:40:24 +0100
Pali Rohár wrote:
> On Wednesday 17 March 2021 13:32:45 Alex Williamson wrote:
> > On Wed, 17 Mar 2021 20:24:24 +0100
> > Pali Rohár wrote:
> >
> > > On Wednesday 17 March 2021 13:15:36 Alex Williamson wrote:
> > &g
On Wed, 17 Mar 2021 20:24:24 +0100
Pali Rohár wrote:
> On Wednesday 17 March 2021 13:15:36 Alex Williamson wrote:
> > On Wed, 17 Mar 2021 20:02:06 +0100
> > Pali Rohár wrote:
> >
> > > On Monday 15 March 2021 09:03:39 Alex Williamson wrote:
> > &g
On Wed, 17 Mar 2021 20:02:06 +0100
Pali Rohár wrote:
> On Monday 15 March 2021 09:03:39 Alex Williamson wrote:
> > On Mon, 15 Mar 2021 15:52:38 +0100
> > Pali Rohár wrote:
> >
> > > On Monday 15 March 2021 08:34:09 Alex Williamson wrote:
> > &g
01:02PM, Leon Romanovsky wrote:
> > > > > On Wed, Mar 17, 2021 at 03:54:47PM +0530, Amey Narkhede wrote:
> > > > > > On 21/03/17 06:20AM, Leon Romanovsky wrote:
> > > > > > > On Mon, Mar 15, 2021 at 06:32:32PM +, Raphael Norwit
On Wed, 17 Mar 2021 13:16:58 +0800
Lu Baolu wrote:
> Hi Longpeng,
>
> On 3/17/21 11:16 AM, Longpeng (Mike, Cloud Infrastructure Service
> Product Dept.) wrote:
> > Hi guys,
> >
> > We find the Intel iommu cache (i.e. iotlb) maybe works wrong in a special
> > situation, it would cause DMA fails
On Mon, 15 Mar 2021 21:03:41 +0530
Amey Narkhede wrote:
> On 21/03/15 05:07PM, Leon Romanovsky wrote:
> > On Mon, Mar 15, 2021 at 08:34:09AM -0600, Alex Williamson wrote:
> > > On Mon, 15 Mar 2021 14:52:26 +0100
> > > Pali Rohár wrote:
> > >
> >
On Mon, 15 Mar 2021 15:52:38 +0100
Pali Rohár wrote:
> On Monday 15 March 2021 08:34:09 Alex Williamson wrote:
> > On Mon, 15 Mar 2021 14:52:26 +0100
> > Pali Rohár wrote:
> >
> > > On Monday 15 March 2021 19:13:23 Amey Narkhede wrote:
> > > > sl
On Mon, 15 Mar 2021 14:52:26 +0100
Pali Rohár wrote:
> On Monday 15 March 2021 19:13:23 Amey Narkhede wrote:
> > slot reset (pci_dev_reset_slot_function) and secondary bus
> > reset(pci_parent_bus_reset) which I think are hot reset and
> > warm reset respectively.
>
> No. PCI secondary bus res
On Fri, 12 Mar 2021 13:09:38 -0700
Alex Williamson wrote:
> On Fri, 12 Mar 2021 15:41:47 -0400
> Jason Gunthorpe wrote:
>
>
> ==
> WARNING: possible circular locking dependency detected
> 5.12.0
On Fri, 12 Mar 2021 15:41:47 -0400
Jason Gunthorpe wrote:
> On Fri, Mar 12, 2021 at 12:16:11PM -0700, Alex Williamson wrote:
> > On Wed, 10 Mar 2021 14:40:11 -0400
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Mar 10, 2021 at 11:34:06AM -0700, Alex Williamson wro
On Wed, 10 Mar 2021 14:40:11 -0400
Jason Gunthorpe wrote:
> On Wed, Mar 10, 2021 at 11:34:06AM -0700, Alex Williamson wrote:
>
> > > I think after the address_space changes this should try to stick with
> > > a normal io_rmap_pfn_range() done outside the fault hand
memory protection as formerly provided by
io_remap_pfn_range(). Tracking of vmas is also updated to
prevent duplicate entries.
Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking")
Reported-by: Zeng Tao
Suggested-by: Zeng Tao
Signed-off-by: Alex Williamson
---
v2: Set
On Wed, 10 Mar 2021 14:14:46 -0400
Jason Gunthorpe wrote:
> On Wed, Mar 10, 2021 at 10:53:29AM -0700, Alex Williamson wrote:
>
> > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > index 65e7e6b44578..ae723808e08b 100644
> > +++ b/dri
protection from io_remap_pfn_range(), but allow
concurrent page table updates. Tracking of vmas is also updated to
prevent duplicate entries.
Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking")
Reported-by: Zeng Tao
Suggested-by: Zeng Tao
Signed-off-by: Alex Williamson
---
On Wed, 10 Mar 2021 08:19:13 -0400
Jason Gunthorpe wrote:
> On Wed, Mar 10, 2021 at 07:48:38AM +, Christoph Hellwig wrote:
> > On Mon, Mar 08, 2021 at 02:47:40PM -0700, Alex Williamson wrote:
> > > Rather than an errno, return a pointer to the opaque vfio_device
>
On Tue, 9 Mar 2021 19:45:03 -0400
Jason Gunthorpe wrote:
> On Tue, Mar 09, 2021 at 12:56:39PM -0700, Alex Williamson wrote:
>
> > And I think this is what we end up with for the current code base:
>
> Yeah, that looks Ok
>
> > diff --git a/drivers/vfio/pci/vf
On Tue, 9 Mar 2021 19:41:27 -0400
Jason Gunthorpe wrote:
> On Tue, Mar 09, 2021 at 12:26:07PM -0700, Alex Williamson wrote:
>
> > In the new series, I think the fault handler becomes (untested):
> >
> > static vm_fault_t vfio_pci_mmap_fault(struct vm_fault *vmf)
On Tue, 9 Mar 2021 16:00:36 -0500
Peter Xu wrote:
> On Tue, Mar 09, 2021 at 01:11:04PM -0700, Alex Williamson wrote:
> > > It's just that the initial MMIO access delay would be spread to the 1st
> > > access
> > > of each mmio page access rather than
On Tue, 9 Mar 2021 14:48:24 -0500
Peter Xu wrote:
> On Tue, Mar 09, 2021 at 12:26:07PM -0700, Alex Williamson wrote:
> > On Tue, 9 Mar 2021 13:47:39 -0500
> > Peter Xu wrote:
> >
> > > On Tue, Mar 09, 2021 at 12:40:04PM -0400, Jason Gunthorpe wrote:
> &g
On Tue, 9 Mar 2021 12:26:07 -0700
Alex Williamson wrote:
> On Tue, 9 Mar 2021 13:47:39 -0500
> Peter Xu wrote:
>
> > On Tue, Mar 09, 2021 at 12:40:04PM -0400, Jason Gunthorpe wrote:
> > > On Tue, Mar 09, 2021 at 08:29:51AM -0700, Alex Williamson wrote:
> > &
On Tue, 9 Mar 2021 13:47:39 -0500
Peter Xu wrote:
> On Tue, Mar 09, 2021 at 12:40:04PM -0400, Jason Gunthorpe wrote:
> > On Tue, Mar 09, 2021 at 08:29:51AM -0700, Alex Williamson wrote:
> > > On Tue, 9 Mar 2021 08:46:09 -0400
> > > Jason Gunthorpe wrote:
> >
On Mon, 8 Mar 2021 20:46:27 -0400
Jason Gunthorpe wrote:
> On Mon, Mar 08, 2021 at 02:48:30PM -0700, Alex Williamson wrote:
> > Using a vfio device, a notifier block can be registered to receive
> > select device events. Notifiers can only be registered for contained
> >
On Tue, 9 Mar 2021 08:46:09 -0400
Jason Gunthorpe wrote:
> On Tue, Mar 09, 2021 at 03:49:09AM +, Zengtao (B) wrote:
> > Hi guys:
> >
> > Thanks for the helpful comments, after rethinking the issue, I have proposed
> > the following change:
> > 1. follow_pte instead of follow_pfn.
>
> St
Replace with 'unsigned int'.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_intrs.c | 42 ++---
drivers/vfio/pci/vfio_pci_private.h |4 +-
drivers/vfio/platform/vfio_platform_irq.c | 21 +++--
drivers/vfi
Cleanup disrecommended usage and docs.
Signed-off-by: Alex Williamson
---
Documentation/driver-api/vfio-mediated-device.rst | 19 ++-
Documentation/driver-api/vfio.rst |4 -
drivers/s390/cio/vfio_ccw_cp.h| 13 +-
drivers/s390/cio/vfio_ccw_private.h
. On notification of device release,
automatically drop the DMA mappings for it.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1.c | 163 ---
1 file changed, 116 insertions(+), 47 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b
Populate the page array to the extent available to enable batching.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index
Pull code out to a function for re-use.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1.c | 57 +++
1 file changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index
We'll need these to track vfio device mappings.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
Trigger a release notifier call when open reference count is zero.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 585895970e9c..bee9318b46ed 100644
--- a
Add a new vfio_device_ops callback to allow the bus driver to
translate a vma mapping of a vfio device fd to a pfn. Plumb through
vfio-core. Implemented for vfio-pci.
Suggested-by: Jason Gunthorpe
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c |1 +
drivers/vfio/vfio.c
minimally respond to the release event by
asynchronously removing notifiers.
Signed-off-by: Alex Williamson
---
drivers/vfio/Kconfig |1 +
drivers/vfio/vfio.c | 35 +++
include/linux/vfio.h |9 +
3 files changed, 45 insertions(+)
diff --git a
Creating an address space mapping onto our vfio pseudo fs for each
device file descriptor means that we can universally retrieve a
vfio_device from a vma mapping this file.
Suggested-by: Jason Gunthorpe
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio.c | 19 +--
include
e pfn in vm_pgoff if we want to
use unmap_mapping_range() to zap a selective portion of the device
fd corresponding to BAR mappings.
Suggested-by: Jason Gunthorpe
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 228 +++
drivers/vfi
ernel.org/kvm/161401167013.16443.8389863523766611711.st...@gimli.home/
---
Alex Williamson (14):
vfio: Create vfio_fs_type with inode per device
vfio: Update vfio_add_group_dev() API
vfio: Export unmap_mapping_range() wrapper
vfio/pci: Use vfio_device_unmap_mapping_range()
v
Allow bus drivers to use vfio pseudo fs mapping to zap all mmaps
across a range of their device files.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio.c |7 +++
include/linux/vfio.h |2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
Rather than an errno, return a pointer to the opaque vfio_device
to allow the bus driver to call into vfio-core without additional
lookups and references. Note that bus drivers are still required
to use vfio_del_group_dev() to teardown the vfio_device.
Signed-off-by: Alex Williamson
By linking all the device fds we provide to userspace to an
address space through a new pseudo fs, we can use tools like
unmap_mapping_range() to zap all vmas associated with a device.
Suggested-by: Jason Gunthorpe
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio.c | 54
On Mon, 8 Mar 2021 19:11:26 +0800
Zeng Tao wrote:
> We have met the following error when test with DPDK testpmd:
> [ 1591.733256] kernel BUG at mm/memory.c:2177!
> [ 1591.739515] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [ 1591.747381] Modules linked in: vfio_iommu_type1 vfio_pci vfio_virq
On Thu, 4 Mar 2021 19:16:33 -0400
Jason Gunthorpe wrote:
> On Thu, Mar 04, 2021 at 02:37:57PM -0700, Alex Williamson wrote:
>
> > Therefore unless a bus driver opts-out by replacing vm_private_data, we
> > can identify participating vmas by the vm_ops and have flags indicat
On Thu, 25 Feb 2021 19:49:49 -0400
Jason Gunthorpe wrote:
> On Thu, Feb 25, 2021 at 03:21:13PM -0700, Alex Williamson wrote:
>
> > This is where it gets tricky. The vm_pgoff we get from
> > file_operations.mmap is already essentially describing an offset from
> >
On Mon, 1 Mar 2021 14:28:17 -0600
Bjorn Helgaas wrote:
> [+cc Alex, reset expert]
>
> On Mon, Mar 01, 2021 at 06:12:21PM +0100, Pali Rohár wrote:
> > Hello!
> >
> > PCIe card can be reset via in-band Hot Reset signal which can be
> > triggered by PCIe bridge via Secondary Bus Reset bit in PCI c
On Wed, 24 Feb 2021 20:06:10 -0400
Jason Gunthorpe wrote:
> On Wed, Feb 24, 2021 at 02:55:06PM -0700, Alex Williamson wrote:
>
> > > The only use of the special ops would be if there are multiple types
> > > of mmap's going on, but for this narrow u
On Mon, 22 Feb 2021 13:29:13 -0400
Jason Gunthorpe wrote:
> On Mon, Feb 22, 2021 at 09:51:25AM -0700, Alex Williamson wrote:
>
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index da212425ab30..399c42b77fbb 100644
> > +++ b/drivers/vfio/vfio.c
>
On Mon, 22 Feb 2021 13:22:30 -0400
Jason Gunthorpe wrote:
> On Mon, Feb 22, 2021 at 09:51:13AM -0700, Alex Williamson wrote:
>
> > + vfio_device_unmap_mapping_range(vdev->device,
> > + VFIO_PCI_INDEX_TO_OFFSET(VFIO_
On Mon, 22 Feb 2021 13:55:23 -0400
Jason Gunthorpe wrote:
> On Mon, Feb 22, 2021 at 09:52:32AM -0700, Alex Williamson wrote:
> > Introduce a new default strict MMIO mapping mode where the vma for
> > a VM_PFNMAP mapping must be backed by a vfio device. This allows
> > holdi
1 - 100 of 1581 matches
Mail list logo
