> > > > > From: Tian, Kevin
> > > > > Sent: Thursday, July 9, 2020 9:57 AM
> > > > >
> > > > > > From: Liu, Yi L
> > > > > > Sent: Thursday, July 9, 2020 8:32 AM
> > > > > >
> > > > > > Hi Alex,
> >
On Wed, 8 Jul 2020 08:16:16 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> > From: Liu, Yi L < yi.l@intel.com>
> > Sent: Friday, July 3, 2020 2:28 PM
> >
> > Hi Alex,
> >
> > > From: Alex Williamson
> > > Sent: Frida
On Wed, 8 Jul 2020 08:08:40 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> Eric asked if we will to have data strcut other than struct iommu_nesting_info
> type in the struct vfio_iommu_type1_info_cap_nesting @info[] field. I'm not
> quit sure on it. I guess the answer may be not as VFIO's nesting
On Wed, 8 Jul 2020 10:53:12 +0800
Lu Baolu wrote:
> Hi Alex,
>
> Thanks a lot for your comments. Please check my reply inline.
>
> On 7/8/20 5:04 AM, Alex Williamson wrote:
> > On Tue, 7 Jul 2020 09:39:56 +0800
> > Lu Baolu wrote:
> >
> >> T
On Mon, 29 Jun 2020 16:05:18 -0700
Jacob Pan wrote:
> On Fri, 26 Jun 2020 16:19:23 -0600
> Alex Williamson wrote:
>
> > On Tue, 23 Jun 2020 10:03:53 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI is newly introduced to support communications betwee
) so that the users could pass
> in an optional device pointer (struct device for vfio/mdev for example),
> and the necessary check and data link could be done.
>
> Fixes: a3a195929d40b ("iommu: Add APIs for multiple domains per device")
> Cc: Robin Murphy
> Cc: Alex
On Wed, 24 Jun 2020 01:55:14 -0700
Liu Yi L wrote:
> This patch refactors the vfio_iommu_type1_ioctl() to use switch instead of
> if-else, and each cmd got a helper function.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Phili
tup.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Liu Yi L
> Signed-off-by: Eric Auger
> Signed-off-by: Jacob Pan
> ---
> v1 -> v2:
&
es
> to a PASID. This PASID must have been allocated to user space before the
> binding request.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Jean-Philippe
exits.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Liu Yi L
> Signed-off-by: Yi Sun
> Signed-off-by: Jacob Pan
> ---
> v1 -> v2:
> *) m
o.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Suggested-by: Alex Williamson
> Signed-off-by: Liu Yi L
> ---
> v1 -> v2:
> *) added in v2, split from the pasid alloc/free su
context. But for now let's go with this restriction
> by requiring singleton container for using nesting iommu features. Below
> link has the related discussion about this decision.
>
> https://lkml.org/lkml/2020/5/15/1028
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
ting info after setting DOMAIN_ATTR_NESTING.
>
> v2 -> v3:
> *) remvoe cap/ecap_mask in iommu_nesting_info.
> *) reuse DOMAIN_ATTR_NESTING to get nesting info.
> *) return an empty iommu_nesting_info for SMMU drivers per Jean'
>suggestion.
>
> Cc: Kevin Tian
> CC:
andeburg
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index f634c81998bb..9968dc0f87a3 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -20
On Sun, 28 Jun 2020 03:12:12 +
"Wang, Haiyue" wrote:
> > -Original Message-
> > From: kvm-ow...@vger.kernel.org On Behalf Of
> > Alex Williamson
> > Sent: Friday, June 26, 2020 00:57
> > To: alex.william...@redhat.com
> > Cc: k...
to ebfa440ce38b7e2e04c3124aa89c8a9f4094cf21:
vfio/pci: Fix SR-IOV VF handling with MMIO blocking (2020-06-25 11:04:23
-0600)
VFIO fixes for v5.8-rc3
- Fix double free of eventfd ctx (Alex Williamson)
- Fix duplicate use of capability ID (Alex Williamson
On Tue, 23 Jun 2020 10:03:53 -0700
Jacob Pan wrote:
> IOMMU UAPI is newly introduced to support communications between guest
> virtual IOMMU and host IOMMU. There has been lots of discussions on how
> it should work with VFIO UAPI and userspace in general.
>
> This document is indended to
o-pci: Invalidate mmaps and block MMIO access on
disabled memory")
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_config.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_conf
On Wed, 10 Jun 2020 01:23:14 -0400
Yan Zhao wrote:
> On Fri, Jun 05, 2020 at 10:13:01AM -0600, Alex Williamson wrote:
> > On Thu, 4 Jun 2020 22:02:31 -0400
> > Yan Zhao wrote:
> >
> > > On Wed, Jun 03, 2020 at 10:10:58PM -0600, Alex Williamson wrote:
>
On Tue, 9 Jun 2020 20:37:31 -0400
Yan Zhao wrote:
> On Fri, Jun 05, 2020 at 03:39:50PM +0100, Dr. David Alan Gilbert wrote:
> > > > > I tried to simplify the problem a bit, but we keep going backwards.
> > > > > If
> > > > > the requirement is that potentially any source device can migrate to
On Fri, 19 Jun 2020 03:30:24 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> > From: Alex Williamson
> > Sent: Friday, June 19, 2020 10:55 AM
> >
> > On Fri, 19 Jun 2020 02:15:36 +
> > "Liu, Yi L" wrote:
> >
> > > Hi Ale
No functional change, avoid non-inclusive naming schemes.
Signed-off-by: Alex Williamson
---
v2: Wrap vfio_dev_driver_allowed to 80 column for consistency,
checkpatch no longer warns about this.
drivers/vfio/vfio.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions
On Fri, 19 Jun 2020 00:18:02 -0700
Christoph Hellwig wrote:
> On Thu, Jun 18, 2020 at 01:57:18PM -0600, Alex Williamson wrote:
> > No functional change, avoid non-inclusive naming schemes.
>
> Adding a bunch of overly long lines that don't change anything are
> everything
On Fri, 19 Jun 2020 02:15:36 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> > From: Alex Williamson
> > Sent: Friday, June 19, 2020 5:48 AM
> >
> > On Wed, 17 Jun 2020 08:28:24 +
> > "Tian, Kevin" wrote:
> >
> >
On Wed, 17 Jun 2020 08:28:24 +
"Tian, Kevin" wrote:
> > From: Liu, Yi L
> > Sent: Wednesday, June 17, 2020 2:20 PM
> >
> > > From: Jacob Pan
> > > Sent: Tuesday, June 16, 2020 11:22 PM
> > >
> > > On Thu, 11 Jun 2020 17:27:27 -0700
> > > Jacob Pan wrote:
> > >
> > > > >
> > > > > But
No functional change, avoid non-inclusive naming schemes.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 580099afeaff..833da937b7fc 100644
--- a/drivers
ID 1 is already used by the IOVA range capability, use ID 2.
Reported-by: Liu Yi L
Cc: Kirti Wankhede
Fixes: ad721705d09c ("vfio iommu: Add migration capability to report supported
features")
Signed-off-by: Alex Williamson
---
include/uapi/linux/vfio.h |2 +-
1 file changed, 1
_eventfd+0x54/0x1ac
> [<82791a69>] __arm64_sys_eventfd2+0x34/0x44
> [<0000b819758c>] do_el0_svc+0x128/0x1dc
> [<b244e810>] el0_sync_handler+0xd0/0x268
> [<d495ef94>] el0_sync+0x164/0x180
>
> Signed-off-by: Q
_eventfd+0x54/0x1ac
> [<82791a69>] __arm64_sys_eventfd2+0x34/0x44
> [<0000b819758c>] do_el0_svc+0x128/0x1dc
> [<b244e810>] el0_sync_handler+0xd0/0x268
> [<d495ef94>] el0_sync+0x164/0x180
>
> Signed-off-by: Q
_eventfd+0x54/0x1ac
> [<82791a69>] __arm64_sys_eventfd2+0x34/0x44
> [<0000b819758c>] do_el0_svc+0x128/0x1dc
> [<b244e810>] el0_sync_handler+0xd0/0x268
> [<d495ef94>] el0_sync+0x164/0x180
>
> Signed-off-by: Q
_eventfd+0x54/0x1ac
> [<82791a69>] __arm64_sys_eventfd2+0x34/0x44
> [<0000b819758c>] do_el0_svc+0x128/0x1dc
> [<b244e810>] el0_sync_handler+0xd0/0x268
> [<d495ef94>] el0_sync+0x164/0x180
>
> Signed-off-by: Q
_eventfd+0x54/0x1ac
> [<82791a69>] __arm64_sys_eventfd2+0x34/0x44
> [<0000b819758c>] do_el0_svc+0x128/0x1dc
> [<b244e810>] el0_sync_handler+0xd0/0x268
> [<d495ef94>] el0_sync+0x164/0x180
>
> Signed-off-by: Q
_eventfd+0x54/0x1ac
> [<82791a69>] __arm64_sys_eventfd2+0x34/0x44
> [<0000b819758c>] do_el0_svc+0x128/0x1dc
> [<b244e810>] el0_sync_handler+0xd0/0x268
> [<d495ef94>] el0_sync+0x164/0x180
>
> Signed-off-by: Q
On Tue, 16 Jun 2020 10:50:52 +0200
Daniel Wagner wrote:
> Hi,
>
> I'm getting the warning below when starting a KVM the second time with an
> Emulex PCI card 'passthroughed' into a KVM. I'm terminating the session
> via 'ctrl-a x', not sure if this is relevant.
>
> This is with 5.8-rc1. IIRC,
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c |8 ++--
1 file
On Thu, 11 Jun 2020 13:02:24 -0700
Jacob Pan wrote:
> On Thu, 11 Jun 2020 11:08:16 -0600
> Alex Williamson wrote:
>
> > On Wed, 10 Jun 2020 21:12:15 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI data has an argsz field which is filled by user. As the
On Thu, 11 Jun 2020 12:52:05 -0700
Jacob Pan wrote:
> Hi Alex,
>
> On Thu, 11 Jun 2020 09:47:41 -0600
> Alex Williamson wrote:
>
> > On Wed, 10 Jun 2020 21:12:13 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI is newly introduced to support commun
On Thu, 11 Jun 2020 05:15:21 -0700
Liu Yi L wrote:
> IOMMUs that support nesting translation needs report the capability info
> to userspace, e.g. the format of first level/stage paging structures.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
On Wed, 10 Jun 2020 21:12:15 -0700
Jacob Pan wrote:
> IOMMU UAPI data has an argsz field which is filled by user. As the data
> structures expands, argsz may change. As the UAPI data are shared among
> different architectures, extensions of UAPI data could be a result of
> one architecture which
On Wed, 10 Jun 2020 21:12:14 -0700
Jacob Pan wrote:
> As IOMMU UAPI gets extended, user data size may increase. To support
> backward compatibiliy, this patch introduces a size field to each UAPI
> data structures. It is *always* the responsibility for the user to fill in
> the correct size.
On Wed, 10 Jun 2020 21:12:13 -0700
Jacob Pan wrote:
> IOMMU UAPI is newly introduced to support communications between guest
> virtual IOMMU and host IOMMU. There has been lots of discussions on how
> it should work with VFIO UAPI and userspace in general.
>
> This document is indended to
On Fri, 5 Jun 2020 00:26:10 +
"He, Shaopeng" wrote:
> > From: Alex Williamson
> > Sent: Thursday, June 4, 2020 12:11 PM
> >
> > On Wed, 3 Jun 2020 22:42:28 -0400
> > Yan Zhao wrote:
> >
> > > On Wed, Jun 03, 2020 at 05:04:52PM -06
On Thu, 4 Jun 2020 22:02:31 -0400
Yan Zhao wrote:
> On Wed, Jun 03, 2020 at 10:10:58PM -0600, Alex Williamson wrote:
> > On Wed, 3 Jun 2020 22:42:28 -0400
> > Yan Zhao wrote:
> >
> > > On Wed, Jun 03, 2020 at 05:04:52PM -0600, Alex Williamson wrote:
>
On Fri, 5 Jun 2020 11:22:24 +0100
"Dr. David Alan Gilbert" wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > On Wed, 3 Jun 2020 01:24:43 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrot
On Wed, 3 Jun 2020 22:42:28 -0400
Yan Zhao wrote:
> On Wed, Jun 03, 2020 at 05:04:52PM -0600, Alex Williamson wrote:
> > On Tue, 2 Jun 2020 21:40:58 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 01:34:35PM -0600, Alex Williamson wrote:
On Tue, 2 Jun 2020 21:40:58 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 01:34:35PM -0600, Alex Williamson wrote:
> > I'm not at all happy with this. Why do we need to hide the migration
> > sparse mmap from the user until migration time? What if instead we
>
to 4f085ca2f5a8047845ab2d6bbe97089daed28655:
Merge branch 'v5.8/vfio/kirti-migration-fixes' into v5.8/vfio/next
(2020-06-02 13:53:00 -0600)
VFIO updates for v5.8-rc1
- Block accesses to disabled MMIO space (Alex Williamson)
- VFIO device migration API (Kirti
On Wed, 3 Jun 2020 01:24:43 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote:
> > On Tue, 2 Jun 2020 23:19:48 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> &
On Tue, 2 Jun 2020 23:19:48 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > On Wed, 29 Apr 2020 20:39:50 -0400
> > Yan Zhao wrote:
> >
> > > On Wed, Apr 29, 2020 at 05:48:44PM +0800
On Wed, 29 Apr 2020 20:39:50 -0400
Yan Zhao wrote:
> On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote:
>
> > > > > > > > > > > > > > An mdev type is meant to define a software
> > > > > > > > > > > > > > compatible interface, so in
> > > > > > > > > > > > > > the case of
On Tue, 2 Jun 2020 09:16:15 -0600
Alex Williamson wrote:
> On Tue, 2 Jun 2020 07:36:45 -0700
> Randy Dunlap wrote:
>
> > On 6/2/20 3:37 AM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > News: The merge window has opened, so please do *not*
On Tue, 2 Jun 2020 04:28:58 -0400
Yan Zhao wrote:
> On Mon, Jun 01, 2020 at 10:43:07AM -0600, Alex Williamson wrote:
> > On Mon, 1 Jun 2020 02:57:26 -0400
> > Yan Zhao wrote:
> >
> > > On Fri, May 29, 2020 at 03:45:47PM -0600, Alex Williamson wrote:
> &
On Tue, 2 Jun 2020 07:36:45 -0700
Randy Dunlap wrote:
> On 6/2/20 3:37 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > News: The merge window has opened, so please do *not* add v5.9 material
> > to your linux-next included branches until after v5.8-rc1 has been
> > released.
> >
> > Changes
On Fri, 8 May 2020 10:20:32 +0300
Diana Craciun wrote:
> The DPRC (Data Path Resource Container) device is a bus device and has
> child devices attached to it. When the vfio-fsl-mc driver is probed
> the DPRC is scanned and the child devices discovered and initialized.
>
> Signed-off-by:
On Fri, 8 May 2020 10:20:34 +0300
Diana Craciun wrote:
> Expose to userspace information about the memory regions.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Diana Craciun
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 77 ++-
>
On Fri, 8 May 2020 10:20:35 +0300
Diana Craciun wrote:
> Allow userspace to mmap device regions for direct access of
> fsl-mc devices.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Diana Craciun
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 60 ++-
>
twork controller: Intel Corporation Device 9df0 (rev 30)
> > > Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
> > >
> > > This permits assigning this device to a guest VM.
> > >
> > > Fixes: f096c061f552 ("iommu: Rewo
On Mon, 1 Jun 2020 02:57:26 -0400
Yan Zhao wrote:
> On Fri, May 29, 2020 at 03:45:47PM -0600, Alex Williamson wrote:
> > On Sun, 17 May 2020 22:52:45 -0400
> > Yan Zhao wrote:
> >
> > > This is a virtual irq type.
> > > vendor driver triggers thi
On Wed, 27 May 2020 21:01:09 -0500
wu000...@umn.edu wrote:
> From: Qiushi Wu
>
> kobject_init_and_add() takes reference even when it fails.
> If this function returns an error, kobject_put() must be called to
> properly clean up the memory associated with the object. Thus,
> replace kfree() by
On Sun, 17 May 2020 22:52:45 -0400
Yan Zhao wrote:
> This is a virtual irq type.
> vendor driver triggers this irq when it wants to notify userspace to
> remap PCI BARs.
>
> 1. vendor driver triggers this irq and packs the target bar number in
>the ctx count. i.e. "1 << bar_number".
>if
Fixes tag. This seems like a feature,
not a fix. If you want it in stable releases as a feature, request it
via Cc: sta...@vger.kernel.org. I'd drop that tag, that's my nit.
Otherwise:
Reviewed-by: Alex Williamson
> Signed-off-by: Ashok Raj
> To: Joerg Roedel
> To: Bjorn Helgaas
r: Intel Corporation Device 9df0 (rev 30)
> Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
>
> This permits assigning this device to a guest VM.
>
> Fixes: f096c061f552 ("iommu: Rework iommu_group_get_for_pci_dev()")
> Signed-off-by: Ashok Raj
&g
On Tue, 26 May 2020 11:06:48 -0700
"Raj, Ashok" wrote:
> Hi Alex,
>
> I was able to find better language in the IOMMU spec that gaurantees
> the behavior we need. See below.
>
>
> On Tue, May 05, 2020 at 09:34:14AM -0600, Alex Williamson wrote:
> > On Tu
On Thu, 21 May 2020 21:18:29 -0400
Qian Cai wrote:
> It is possible vfio_config_init() does not call vfio_cap_len(), and then
> vdev->msi_perm == NULL. Later, in vfio_config_free(), it could trigger a
> null-ptr-deref.
>
> BUG: kernel NULL pointer dereference, address:
> RIP:
On Tue, 26 May 2020 12:53:31 -0300
Jason Gunthorpe wrote:
> On Tue, May 26, 2020 at 08:32:18AM -0600, Alex Williamson wrote:
> > > > Certainly there is no reason to optimize the fringe case of vfio
> > > > sleeping if there is and incorrect concurrnent attempt t
On Tue, 26 May 2020 09:49:54 -0400
Peter Xu wrote:
> On Mon, May 25, 2020 at 09:37:05PM -0300, Jason Gunthorpe wrote:
> > On Mon, May 25, 2020 at 01:56:28PM -0700, John Hubbard wrote:
> > > On 2020-05-25 09:56, Jason Gunthorpe wrote:
> > > > On Mon, May 25, 2020 at 11:11:42AM -0400, Peter Xu
On Sat, 23 May 2020 15:34:17 -0400
Peter Xu wrote:
> Hi, Alex,
>
> On Fri, May 22, 2020 at 01:17:43PM -0600, Alex Williamson wrote:
> > @@ -1346,15 +1526,32 @@ static vm_fault_t vfio_pci_mmap_fault(struct
> > vm_fault *vmf)
> > {
> > struct vm_area_struc
On Fri, 22 May 2020 18:08:58 -0400
Qian Cai wrote:
> On Fri, May 22, 2020 at 01:17:09PM -0600, Alex Williamson wrote:
> > v3:
> >
> > The memory_lock semaphore is only held in the MSI-X path for callouts
> > to functions that may access MSI-X MMIO space of the devi
to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Fixes: CVE-2020-12888
Signed-off-by: Alex Williamson
---
drivers/vfio/pci
range so that all tracking is inserted in the
fault handler and removed in the close handler.
Reviewed-by: Peter Xu
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 76 ++-
drivers/vfio/pci/vfio_pci_private.h |7 +++
2 files changed, 81
ather than SIGBUS if we experience regressions, but
without known code requiring that, SIGBUS seems the appropriate
response to this condition. Thanks,
Alex
---
Alex Williamson (3):
vfio/type1: Support faulting PFNMAP vmas
vfio-pci: Fault mmaps to enable vma tracking
vfio-pci: Invali
With conversion to follow_pfn(), DMA mapping a PFNMAP range depends on
the range being faulted into the vma. Add support to manually provide
that, in the same way as done on KVM with hva_to_pfn_remapped().
Reviewed-by: Peter Xu
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1
On Thu, 21 May 2020 22:39:06 -0400
Qian Cai wrote:
> On Tue, May 05, 2020 at 03:55:02PM -0600, Alex Williamson wrote:
> []
> vfio_pci_mmap_fault(struct vm_fault *vmf)
> > {
> > struct vm_area_struct *vma = vmf->vma;
> > struct vfio_pci_devic
in next patch.
> >
> > In this patch, guest page table bind and unbind are done by using flags
> > VFIO_IOMMU_BIND_GUEST_PGTBL and
> > VFIO_IOMMU_UNBIND_GUEST_PGTBL under IOCTL
> > VFIO_IOMMU_BIND, the bind/unbind data are conveyed by
> > struct iommu_gpasid_b
On Fri, 15 May 2020 11:22:51 -0400
Peter Xu wrote:
> On Thu, May 14, 2020 at 04:55:17PM -0600, Alex Williamson wrote:
> > > I'm not if this makes sense, can't we arrange to directly trap the
> > > IOMMU failure and route it into qemu if that is what is desired?
>
On Thu, 14 May 2020 19:24:15 -0300
Jason Gunthorpe wrote:
> On Thu, May 14, 2020 at 04:17:12PM -0600, Alex Williamson wrote:
>
> > that much. I think this would also address Jason's primary concern.
> > It's better to get an IOMMU fault from the user trying to access those
On Thu, 14 May 2020 17:25:38 -0400
Peter Xu wrote:
> On Thu, May 14, 2020 at 10:51:46AM -0600, Alex Williamson wrote:
> > This is a follow-on series to "vfio-pci: Block user access to disabled
> > device MMIO"[1], which extends user access blocking of disabled M
, enabled
by default, restricting IOMMU mapping of PFNMAP vmas to only those
supporting invalidation callbacks. vfio-pci is updated to register
vfio_pci_mmap_ops as supporting this feature.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c |7
drivers/vfio/vfio.c
recommended as this
support only provides invalidation, dropping unmapped vmas. Those
vmas are not automatically re-installed when re-mapped.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 34 +-
drivers/vfio/pci/vfio_pci_private.h |1
drivers/vfio/vfio.c
you'd like Suggested-by credit for the ideas here I'd be
glad to add it. Thanks,
Alex
[1]https://lore.kernel.org/kvm/158871401328.15589.17598154478222071285.st...@gimli.home/
---
Alex Williamson (2):
vfio: Introduce bus driver to IOMMU invalidation interface
vfio: Introduce str
> 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
hu, May 07, 2020 at 08:54:21PM -0300, Jason Gunthorpe wrote:
> > > > > On Thu, May 07, 2020 at 05:24:43PM -0400, Peter Xu wrote:
> > > > > > On Tue, May 05, 2020 at 03:54:44PM -0600, Alex Williamson wrote:
> > > > > > >
On Thu, 7 May 2020 17:59:08 -0400
Peter Xu wrote:
> On Tue, May 05, 2020 at 03:54:36PM -0600, Alex Williamson wrote:
> > v2:
> >
> > Locking in 3/ is substantially changed to avoid the retry scenario
> > within the fault handler, therefore a caller who does not all
On Thu, 7 May 2020 17:47:44 -0400
Peter Xu wrote:
> Hi, Alex,
>
> On Tue, May 05, 2020 at 03:54:53PM -0600, Alex Williamson wrote:
> > +/*
> > + * Zap mmaps on open so that we can fault them in on access and therefore
> > + * our vma_list only tracks mappi
On Thu, 7 May 2020 17:24:43 -0400
Peter Xu wrote:
> On Tue, May 05, 2020 at 03:54:44PM -0600, Alex Williamson wrote:
> > With conversion to follow_pfn(), DMA mapping a PFNMAP range depends on
> > the range being faulted into the vma. Add support to manually provide
> >
this one rather than
delving into the potentially subtle dependencies within our map.
Seen on an NVIDIA Tesla T4.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_config.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b
range so that all tracking is inserted in the
fault handler and removed in the close handler.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 76 ++-
drivers/vfio/pci/vfio_pci_private.h |7 +++
2 files changed, 81 insertions(+), 2
to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c
response to this condition. Thanks,
Alex
---
Alex Williamson (3):
vfio/type1: Support faulting PFNMAP vmas
vfio-pci: Fault mmaps to enable vma tracking
vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
drivers/vfio/pci/vfio_pci.c | 321
With conversion to follow_pfn(), DMA mapping a PFNMAP range depends on
the range being faulted into the vma. Add support to manually provide
that, in the same way as done on KVM with hva_to_pfn_remapped().
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1.c | 36
On Mon, 4 May 2020 17:01:23 -0300
Jason Gunthorpe wrote:
> On Mon, May 04, 2020 at 01:35:52PM -0600, Alex Williamson wrote:
>
> > Ok, this all makes a lot more sense with memory_lock still in the
> > picture. And it looks like you're not insisting on the wait_event
On Tue, 5 May 2020 07:56:06 -0700
"Raj, Ashok" wrote:
> On Tue, May 05, 2020 at 08:05:14AM -0600, Alex Williamson wrote:
> > On Mon, 4 May 2020 23:11:07 -0700
> > "Raj, Ashok" wrote:
> >
> > > Hi Alex
> > >
> > > + Joerg,
On Mon, 4 May 2020 23:11:07 -0700
"Raj, Ashok" wrote:
> Hi Alex
>
> + Joerg, accidently missed in the Cc.
>
> On Mon, May 04, 2020 at 11:19:36PM -0600, Alex Williamson wrote:
> > On Mon, 4 May 2020 21:42:16 -0700
> > Ashok Raj wrote:
> >
.
>
> Fixes: f096c061f552 ("iommu: Rework iommu_group_get_for_pci_dev()")
> Signed-off-by: Ashok Raj
> To: Joerg Roedel
> To: Bjorn Helgaas
> Cc: linux-kernel@vger.kernel.org
> Cc: io...@lists.linux-foundation.org
> Cc: Lu Baolu
> Cc: Alex Williamson
On Mon, 4 May 2020 15:08:08 -0700
Neo Jia wrote:
> On Mon, May 04, 2020 at 12:52:53PM -0600, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, 4 May 2020 18:09:16 +0200
> > Cornelia Huck wrote:
> >
On Mon, 4 May 2020 15:44:36 -0300
Jason Gunthorpe wrote:
> On Mon, May 04, 2020 at 12:26:43PM -0600, Alex Williamson wrote:
> > On Fri, 1 May 2020 20:48:49 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Fri, May 01, 2020 at 03:39:30PM -0600, Alex Williamson wrote
On Mon, 4 May 2020 18:09:16 +0200
Cornelia Huck wrote:
> On Fri, 01 May 2020 15:41:24 -0600
> Alex Williamson wrote:
>
> > There is no PCI spec defined capability with ID 0, therefore we don't
> > expect to find it in a capability chain and we use this index in
On Fri, 1 May 2020 20:48:49 -0300
Jason Gunthorpe wrote:
> On Fri, May 01, 2020 at 03:39:30PM -0600, Alex Williamson wrote:
>
> > static int vfio_pci_add_vma(struct vfio_pci_device *vdev,
> > struct vm_area_struct *vma)
> > {
> >
On Mon, 4 May 2020 12:05:56 -0300
Jason Gunthorpe wrote:
> On Mon, May 04, 2020 at 08:20:55AM -0600, Alex Williamson wrote:
> > On Fri, 1 May 2020 20:25:50 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Fri, May 01, 2020 at 03:39:19PM -0600, Alex Williamso
On Fri, 1 May 2020 20:25:50 -0300
Jason Gunthorpe wrote:
> On Fri, May 01, 2020 at 03:39:19PM -0600, Alex Williamson wrote:
> > Rather than calling remap_pfn_range() when a region is mmap'd, setup
> > a vm_ops handler to support dynamic faulting of the range on access.
>
301 - 400 of 5215 matches
Mail list logo
