On Fri, 30 Oct 2020 06:16:28 +
"Tian, Kevin" wrote:
> > From: Lu Baolu
> > Sent: Friday, October 30, 2020 12:58 PM
> >
> > With the IOMMU driver registering iommu_ops for the mdev_bus, the
> > IOMMU
> > operations on an mdev could be done in the same way as any normal device
> > (for
On Fri, 30 Oct 2020 12:58:08 +0800
Lu Baolu wrote:
> +static const struct iommu_ops siov_iommu_ops = {
> + .capable= intel_iommu_capable,
> + .domain_alloc = siov_iommu_domain_alloc,
> + .domain_free= intel_iommu_domain_free,
> + .attach_dev
t; + /*
> + * Attempt to enable ACS regardless of capability because some rootports
> + * (e.g. the ones quirked with *_intel_pch_acs_*) may not expose
> + * standard rootport capability structure, but still may support ACS via
> + * those quirks.
> + */
> + pci_enable_acs(dev);
> }
>
> /**
Much needed regression fix for v5.9:
Reviewed-by: Alex Williamson
On Fri, 30 Oct 2020 12:58:05 +0800
Lu Baolu wrote:
> Move mdev bus registration earlier than IOMMU probe processing so that
> the IOMMU drivers could be able to set iommu_ops for the mdev bus. This
> only applies when vfio-mdev module is setected to be built-in.
>
> Signed-off-by: Lu Baolu
>
1
Reported-by: Ian Pilcher
Tested-by: Ian Pilcher
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_rdwr.c | 43 +++---
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rd
ages and dma-rw accesses (Yan Zhao)
- Cleanups and optimize vconfig regen (Zenghui Yu)
- Fix duplicate irq-bypass token registration (Alex Williamson)
--------
Alex Williamson (3):
Merge branches 'v5.10/vfio/bardirty', 'v5.10/vfio/dma_avail
On Fri, 16 Oct 2020 17:35:58 +0800
"xuxiaoyang (C)" wrote:
> From 099744c26513e386e707faecb3f17726e236d9bc Mon Sep 17 00:00:00 2001
> From: Xiaoyang Xu
> Date: Fri, 16 Oct 2020 15:32:02 +0800
> Subject: [PATCH] vfio iommu type1: Fix memory leak in
> vfio_iommu_type1_pin_pages
>
> pfn is not
object. Clear the token of failed producers so
that they harmlessly fall out when unregistered.
Fixes: 6d7425f109d2 ("vfio: Register/unregister irq_bypass_producer")
Reported-by: guomin chen
Tested-by: guomin chen
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_intrs.c |
On Thu, 15 Oct 2020 13:22:26 +0100
Colin King wrote:
> From: Colin Ian King
>
> Currently the success path in function vfio_fsl_mc_reflck_attach is
> returning an uninitialized value in variable ret. Fix this by setting
> this to zero to indicate success.
>
> Addresses-Coverity:
On Fri, 2 Oct 2020 16:05:49 +0200
Greg KH wrote:
> On Fri, Oct 02, 2020 at 04:56:52PM +0300, Laurentiu Tudor wrote:
> > Hi Greg,
> >
> > On 10/2/2020 4:55 PM, Greg KH wrote:
> > > On Tue, Sep 29, 2020 at 02:06:41PM +0300, Laurentiu Tudor wrote:
> > >>
> > >>
> > >> On 9/29/2020 11:54 AM,
On Thu, 15 Oct 2020 11:59:03 +1100
Stephen Rothwell wrote:
> Hi Alex,
>
> On Tue, 13 Oct 2020 13:20:16 -0600 Alex Williamson
> wrote:
> >
> > Thanks, Stephen. Diana has posted a 32bit build fix which I've merged,
> > maybe that was the error. Also Diana's se
On Wed, 14 Oct 2020 00:15:13 +
"Song Bao Hua (Barry Song)" wrote:
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, October 14, 2020 10:32 AM
> > To: tiantao (H)
> > Cc: eri
On Tue, 13 Oct 2020 10:00:58 +0800
Tian Tao wrote:
> It is redundant to do irqsave and irqrestore in hardIRQ context.
But this function is also called from non-IRQ context. Thanks,
Alex
> Signed-off-by: Tian Tao
> ---
> drivers/vfio/platform/vfio_platform_irq.c | 5 ++---
> 1 file
On Tue, 13 Oct 2020 18:06:51 +0300
Diana Craciun wrote:
> The FSL_MC_BUS on which the VFIO-FSL-MC driver is dependent on
> can be compiled on other architectures as well (not only ARM64)
> including 32 bit architectures.
> Include linux/io-64-nonatomic-hi-lo.h to make writeq/readq used
> in the
On Tue, 13 Oct 2020 18:56:07 +0300
Diana Craciun OSS wrote:
> Hi,
>
> How does it fail? What's the error?
>
> Thanks,
> Diana
>
>
> On 10/13/2020 6:07 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the vfio tree, today's linux-next build (x86_64
> > allmodconfig) failed like
On Mon, 5 Oct 2020 20:36:44 +0300
Diana Craciun wrote:
> DPAA2 (Data Path Acceleration Architecture) consists in
> mechanisms for processing Ethernet packets, queue management,
> accelerators, etc.
>
> The Management Complex (mc) is a hardware entity that manages the DPAA2
> hardware
On Sat, 10 Oct 2020 19:01:30 +0800
gchen chen wrote:
> Alex Williamson 于2020年10月10日周六 上午2:44写道：
> >
> > On Fri, 9 Oct 2020 12:30:04 +0800
> > gchen chen wrote:
> >
> > > Alex Williamson 于2020年9月30日周三 下午10:09写道：
> > > >
> > > &g
On Fri, 9 Oct 2020 12:30:04 +0800
gchen chen wrote:
> Alex Williamson 于2020年9月30日周三 下午10:09写道：
> >
> >
> > Please version your postings so we know which one to consider as the
> > current proposal.
> >
> > On Wed, 30 Sep 2020 20:54:39 +0800
> >
On Wed, 7 Oct 2020 14:56:23 -0400
Matthew Rosato wrote:
> diff --git a/drivers/vfio/pci/vfio_pci_private.h
> b/drivers/vfio/pci/vfio_pci_private.h
> index 61ca8ab..9d28484 100644
> --- a/drivers/vfio/pci/vfio_pci_private.h
> +++ b/drivers/vfio/pci/vfio_pci_private.h
> @@ -213,4 +213,16 @@
On Wed, 7 Oct 2020 14:56:22 -0400
Matthew Rosato wrote:
> Allow the VFIO_DEVICE_GET_INFO ioctl to include a capability chain.
> Add a flag indicating capability chain support, and introduce the
> definitions for the first set of capabilities which are specified to
> s390 zPCI devices.
>
>
On Wed, 7 Oct 2020 14:56:19 -0400
Matthew Rosato wrote:
> This patchset provides a means by which hardware information about the
> underlying PCI device can be passed up to userspace (ie, QEMU) so that
> this hardware information can be used rather than previously hard-coded
> assumptions. The
On Fri, 2 Oct 2020 16:00:42 -0400
Matthew Rosato wrote:
> We define a new device region in vfio.h to be able to get the ZPCI CLP
> information by reading this region from userspace.
>
> We create a new file, vfio_zdev.h to define the structure of the new
> region defined in vfio.h
>
>
On Tue, 29 Sep 2020 12:03:38 +0300
Diana Craciun wrote:
> The software uses a memory-mapped I/O command interface (MC portals) to
> communicate with the MC hardware. This command interface is used to
> discover, enumerate, configure and remove DPAA2 objects. The DPAA2
> objects use MSIs, so the
On Tue, 29 Sep 2020 12:03:39 +0300
Diana Craciun wrote:
> Currently only resetting the DPRC container is supported which
> will reset all the objects inside it. Resetting individual
> objects is possible from the userspace by issueing commands
> towards MC firmware.
>
> Signed-off-by: Diana
On Tue, 29 Sep 2020 12:03:37 +0300
Diana Craciun wrote:
> This patch allows to set an eventfd for fsl-mc device interrupts
> and also to trigger the interrupt eventfd from userspace for testing.
>
> All fsl-mc device interrupts are MSIs. The MSIs are allocated from
> the MSI domain only once
On Tue, 29 Sep 2020 12:03:31 +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:
ioctl+0xa4/0x630
> ? syscall_trace_enter+0x1d3/0x2c0
> ksys_ioctl+0x60/0x90
> __x64_sys_ioctl+0x16/0x20
> do_syscall_64+0x5b/0x1a0
> entry_SYSCALL_64_after_hwframe+0x65/0xca
>
> Cc: Alex Williamson
> Cc: Cornelia Huck
> Cc: J
On Tue, 29 Sep 2020 14:54:35 -0600
Alex Williamson wrote:
> On Sun, 27 Sep 2020 20:11:08 +0800
> guomin_c...@sina.com wrote:
>
> > From: guomin chen
> >
> > Since eventfd "fds" is passed as a parameter by the upper-level
> > application,when &
oad_fixmap_gdt+0x22/0x30
> vfio_msi_set_block+0x6e/0xd0 [vfio_pci]
> vfio_pci_ioctl+0x218/0xbe0 [vfio_pci]
> ? kvm_vcpu_ioctl+0xf2/0x5f0 [kvm]
> do_vfs_ioctl+0xa4/0x630
> ? syscall_trace_enter+0x1d3/0x2c0
> ksys_ioctl+0x60/0x90
>
On Tue, 29 Sep 2020 09:18:22 +0200
Auger Eric wrote:
> Hi all,
>
> [also correcting some outdated email addresses + adding Lorenzo in cc]
>
> On 9/29/20 12:42 AM, Alex Williamson wrote:
> > On Mon, 28 Sep 2020 21:50:34 +0200
> > Eric Auger wrote:
> >
>
On Mon, 28 Sep 2020 21:50:34 +0200
Eric Auger wrote:
> VFIO currently exposes the usable IOVA regions through the
> VFIO_IOMMU_GET_INFO ioctl / VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE
> capability. However it fails to take into account the dma_mask
> of the devices within the container. The top
On Mon, 21 Sep 2020 08:43:29 -0400
Matthew Rosato wrote:
> On 9/10/20 10:59 AM, Matthew Rosato wrote:
> > While it is true that devices with is_virtfn=1 will have a Memory Space
> > Enable bit that is hard-wired to 0, this is not the only case where we
> > see this behavior -- For example some
On Sat, 19 Sep 2020 09:54:00 +0800
Zenghui Yu wrote:
> Hi Alex,
>
> On 2020/9/18 6:07, Alex Williamson wrote:
> > On Thu, 17 Sep 2020 13:35:37 +0200
> > Cornelia Huck wrote:
> >
> >> On Thu, 17 Sep 2020 11:31:28 +0800
> >> Zenghui Yu wr
On Thu, 17 Sep 2020 11:31:27 +0800
Zenghui Yu wrote:
> It was added by commit 137e5531351d ("vfio/pci: Add sriov_configure
> support") and actually unnecessary. Remove it.
Looks correct, but I might clarify as:
s/unnecessary/duplicates a forward declaration earlier in the file/
I can change
On Thu, 17 Sep 2020 13:35:37 +0200
Cornelia Huck wrote:
> On Thu, 17 Sep 2020 11:31:28 +0800
> Zenghui Yu wrote:
>
> > It isn't clear what purpose the @bardirty serves. It might be used to avoid
> > the unnecessary vfio_bar_fixup() invoking on a user-space BAR read, which
> > is not required
On Thu, 17 Sep 2020 10:15:24 -0700
Dave Jiang wrote:
> On 9/17/2020 8:06 AM, Jason Gunthorpe wrote:
> > On Tue, Sep 15, 2020 at 04:27:35PM -0700, Dave Jiang wrote:
> >> drivers/dma/idxd/idxd.h| 65 +
> >> drivers/dma/idxd/init.c|
On Tue, 15 Sep 2020 13:03:01 -0600
Alex Williamson wrote:
> On Tue, 15 Sep 2020 08:30:42 +0800
> Yan Zhao wrote:
>
> > vfio_pin_pages() and vfio_group_pin_pages() are used purely to mark dirty
> > pages to devices with IOMMU backend as they already have all VM pages
>
On Tue, 15 Sep 2020 08:30:42 +0800
Yan Zhao wrote:
> vfio_pin_pages() and vfio_group_pin_pages() are used purely to mark dirty
> pages to devices with IOMMU backend as they already have all VM pages
> pinned at VM startup.
This is wrong. The entire initial basis of mdev devices is for
On Fri, 11 Sep 2020 12:44:03 -0400
Matthew Rosato wrote:
> Commit 492855939bdb ("vfio/type1: Limit DMA mappings per container")
> added the ability to limit the number of memory backed DMA mappings.
> However on s390x, when lazy mapping is in use, we use a very large
> number of concurrent
On Tue, 1 Sep 2020 11:34:22 +0800
Lu Baolu wrote:
> With subdevice information opt-in through iommu_ops.aux_at(de)tach_dev()
> interfaces, the vendor iommu driver is able to learn the knowledge about
> the relationships between the subdevices and the aux-domains. Implement
> is_aux_domain()
On Tue, 1 Sep 2020 11:34:18 +0800
Lu Baolu wrote:
> In the vfio/mdev use case of aux-domain, the subdevices are created from
> the physical devices with IOMMU_DEV_FEAT_AUX enabled and the aux-domains
> are attached to the subdevices through the iommu_ops.aux_attach_dev()
> interface.
>
>
On Tue, 1 Sep 2020 11:34:19 +0800
Lu Baolu wrote:
> This adds two new APIs for the use cases like vfio/mdev where subdevices
> derived from physical devices are created and put in an iommu_group. The
> new IOMMU API interfaces mimic the vfio_mdev_at(de)tach_domain() directly,
> testing whether
On Thu, 10 Sep 2020 16:32:30 +0800
Xu Yilun wrote:
> Hi Alex:
>
> Thanks for your quick response and is helpful to me. I did some more
> investigation and some comments inline.
>
> On Tue, Sep 08, 2020 at 03:10:02PM -0600, Alex Williamson wrote:
> > On Tue, 8 Sep 20
On Thu, 10 Sep 2020 16:15:27 +0530
Vikas Gupta wrote:
> Hi Alex/Cornelia,
>
> We are looking for MSI interrupts for platform devices in user-space
> applications via event/poll mechanism using VFIO.
>
> Since there is no support for MSI/MSIX handling in VFIO-platform in kernel,
> it may not
On Thu, 3 Sep 2020 13:10:02 -0400
Matthew Rosato wrote:
> On 9/3/20 12:41 PM, Bjorn Helgaas wrote:
> > On Wed, Sep 02, 2020 at 03:46:34PM -0400, Matthew Rosato wrote:
> >> Per the PCIe spec, VFs cannot implement the MSE bit
> >> AKA PCI_COMMAND_MEMORY, and it must be hard-wired to 0.
> >> Use
On Mon, 31 Aug 2020 11:24:59 -0700
Jacob Pan wrote:
> IOMMU user APIs are responsible for processing user data. This patch
> changes the interface such that user pointers can be passed into IOMMU
> code directly. Separate kernel APIs without user pointers are introduced
> for in-kernel users of
On Tue, 8 Sep 2020 15:13:32 +0800
Xu Yilun wrote:
> This patch adds description for VFIO Mdev support for dfl devices on
> dfl bus.
>
> Signed-off-by: Xu Yilun
> Signed-off-by: Matthew Gerlach
> ---
> Documentation/fpga/dfl.rst | 20
> 1 file changed, 20 insertions(+)
>
. There's really no need however to
ever fault a user on a VF though as this would only indicate an
error in the user's management of the enable bit, versus a PF
where the same access could trigger hardware faults.
Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on
disabled memory")
Signed-off-by: Alex Williamson
the following or else SR-IOV VFs will be
broken for DPDK:
commit ebfa440ce38b7e2e04c3124aa89c8a9f4094cf21
Author: Alex Williamson
Date: Thu Jun 25 11:04:23 2020 -0600
vfio/pci: Fix SR-IOV VF handling with MMIO blocking
SR-IOV VFs do not implement the memory enable bit of
On Thu, 27 Aug 2020 13:31:38 -0500
Bjorn Helgaas wrote:
> Re the subject line, this patch does a lot more than just "introduce a
> flag"; AFAICT it actually enables important VFIO functionality, e.g.,
> something like:
>
> vfio/pci: Enable MMIO access for s390 detached VFs
>
> On Thu, Aug
On Mon, 24 Aug 2020 10:21:24 -0400
Matthew Rosato wrote:
> On 8/13/20 11:40 AM, Matthew Rosato wrote:
> > s390x has the notion of providing VFs to the kernel in a manner
> > where the associated PF is inaccessible other than via firmware.
> > These are not treated as typical VFs and access to
On Fri, 21 Aug 2020 00:37:19 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> > From: Alex Williamson
> > Sent: Friday, August 21, 2020 4:51 AM
> >
> > On Mon, 27 Jul 2020 23:27:36 -0700
> > Liu Yi L wrote:
> >
> > > This patch allow
uxiliary domain associated with mdev.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> CC: Jun Tian
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Reviewed-by: Eric Auger
> Signed-off-by: Liu Yi L
> ---
> v5 -
ge, which it isn't. It just notes that it
happened, not why it happened, with a mostly irrelevant link.
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Reviewed-by: Eric Auger
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
> ---
> v5 -> v6:
> *)
s. Detail can be found in below link as well.
>
> https://lore.kernel.org/kvm/20200717090900.GC4850@myrica/
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-of
On Fri, 14 Aug 2020 10:37:29 +0800
Ming Mao wrote:
> In the original process of pinning/unpinning pages for VFIO-devices,
> to make sure the pages are contiguous, we have to check them one by one.
> As a result, dma_map/unmap could spend a long time.
> Using the hugetlb pages, we can avoid this
to aae7a75a821a793ed6b8ad502a5890fb8e8f172d:
vfio/type1: Add proper error unwind for vfio_iommu_replay() (2020-08-17
11:09:13 -0600)
VFIO fixes for v5.9-rc2
- Fix lockdep issue reported for recursive read-lock (Alex Williamson)
- Fix missing unwind in type1
On Wed, 12 Aug 2020 15:21:11 -0400
Matthew Rosato wrote:
> s390x has the notion of providing VFs to the kernel in a manner
> where the associated PF is inaccessible other than via firmware.
> These are not treated as typical VFs and access to them is emulated
> by underlying firmware which can
On Wed, 12 Aug 2020 10:50:17 -0400
Matthew Rosato wrote:
> s390x has the notion of providing VFs to the kernel in a manner
> where the associated PF is inaccessible other than via firmware.
> These are not treated as typical VFs and access to them is emulated
> by underlying firmware which can
On Wed, 12 Aug 2020 01:58:00 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, August 12, 2020 1:01 AM
> >
> > On Mon, 10 Aug 2020 07:32:24 +
> > "Tian, Kevin" wrote:
> >
> > > >
to ccd59dce1a21f473518bf273bdf5b182bab955b3:
vfio/type1: Refactor vfio_iommu_type1_ioctl() (2020-07-27 13:46:13 -0600)
VFIO updates for v5.9-rc1
- Inclusive naming updates (Alex Williamson)
- Intel X550 INTx quirk (Alex Williamson)
- Error path resched
On Mon, 10 Aug 2020 07:32:24 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, August 7, 2020 8:20 PM
> >
> > On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
> >
> > > If you see this as an
ing the DMA entry as IOMMU mapped until all
entries are processed, in order to allow the unwind to know the
disposition of each entry.
Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices")
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_t
On Thu, 23 Jul 2020 21:19:30 -0300
Jason Gunthorpe wrote:
> On Tue, Jul 21, 2020 at 11:54:49PM +, Tian, Kevin wrote:
> > In a nutshell, applications don't require raw WQ controllability as guest
> > kernel drivers may expect. Extending DSA user space interface to be another
> > passthrough
to allow legacy probing, this behavior remains with
a comment added. ioeventfds are now included in memory access testing,
with writes dropped while memory space is disabled.
Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on
disabled memory")
Signed-off-by: Alex
On Fri, 31 Jul 2020 14:30:03 +0800
Lu Baolu wrote:
> Hi Alex,
>
> On 2020/7/30 4:25, Alex Williamson wrote:
> > On Tue, 14 Jul 2020 13:57:02 +0800
> > Lu Baolu wrote:
> >
> >> The device driver needs an API to get its aux-domain. A typical usage
> >
On Fri, 31 Jul 2020 13:47:57 +0800
Lu Baolu wrote:
> Hi Alex,
>
> On 2020/7/31 3:46, Alex Williamson wrote:
> > On Wed, 29 Jul 2020 23:34:40 +
> > "Tian, Kevin" wrote:
> >
> >>> From: Alex Williamson
> >>> Sent: Thursday, J
On Thu, 30 Jul 2020 10:41:32 +0800
Lu Baolu wrote:
> Hi Alex,
>
> On 7/30/20 4:32 AM, Alex Williamson wrote:
> > On Tue, 14 Jul 2020 13:57:03 +0800
> > Lu Baolu wrote:
> >
> >> Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
>
On Wed, 29 Jul 2020 23:49:20 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, July 30, 2020 4:25 AM
> >
> > On Tue, 14 Jul 2020 13:57:02 +0800
> > Lu Baolu wrote:
> >
> > > The device driver needs an AP
On Wed, 29 Jul 2020 23:34:40 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, July 30, 2020 4:04 AM
> >
> > On Thu, 16 Jul 2020 09:07:46 +0800
> > Lu Baolu wrote:
> >
> > > Hi Jacob,
> > >
> > &g
On Tue, 14 Jul 2020 13:57:03 +0800
Lu Baolu wrote:
> Replace iommu_aux_at(de)tach_device() with iommu_aux_at(de)tach_group().
> It also saves the IOMMU_DEV_FEAT_AUX-capable physcail device in the
> vfio_group data structure so that it could be reused in other places.
>
> Signed-off-by: Lu Baolu
return -EINVAL;
>
> /* Program the device context */
>
>
> This adds an API for such use case.
>
> Suggested-by: Alex Williamson
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommu.c | 18 ++
> include/linux/io
On Thu, 16 Jul 2020 09:07:46 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 7/16/20 12:01 AM, Jacob Pan wrote:
> > On Wed, 15 Jul 2020 08:47:36 +0800
> > Lu Baolu wrote:
> >
> >> Hi Jacob,
> >>
> >> On 7/15/20 12:39 AM, Jacob Pan wrote:
> >>> On Tue, 14 Jul 2020 13:57:01 +0800
> >>> Lu Baolu
On Tue, 14 Jul 2020 13:57:00 +0800
Lu Baolu wrote:
> The iommu aux-domain api's work only when IOMMU_DEV_FEAT_AUX is enabled
> for the device. Add this check to avoid misuse.
Shouldn't this really be the IOMMU driver's responsibility to test? If
nothing else, iommu_dev_feature_enabled() needs
On Thu, 23 Jul 2020 10:25:39 -0700
Jacob Pan wrote:
> IOMMU user APIs are responsible for processing user data. This patch
> changes the interface such that user pointers can be passed into IOMMU
> code directly. Separate kernel APIs without user pointers are introduced
> for in-kernel users of
On Thu, 23 Jul 2020 10:25:35 -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 intended to
On Mon, 27 Jul 2020 23:27:30 -0700
Liu Yi L wrote:
> This patch refactors the vfio_iommu_type1_ioctl() to use switch instead of
> if-else, and each command got a helper function.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jea
On Sun, 26 Jul 2020 17:49:07 +1000
Geoffrey McRae wrote:
> Hi All,
>
> The commit 22540ca3d00d2990a4148a13b92209c3dc5422db causes a Windows KVM
> guest running under QEMU with a VFIO passthrough GPU to randomly stall
> when using the GPU leading to the guest assuming that the driver has
>
On Fri, 24 Jul 2020 12:57:49 +
WeitaoWang-oc wrote:
> On Thu, 23 Jul 2020 12:38:21 -0400, Alan wrote:
> > On Thu, Jul 23, 2020 at 10:17:35AM -0600, Alex Williamson wrote:
> > > The IOMMU grouping restriction does solve the hardware issue, so long
> > > as one dr
On Thu, 23 Jul 2020 22:47:02 +0100
Giovanni Cabiddu wrote:
> Add denylist of devices that by default are not probed by vfio-pci.
> Devices in this list may be susceptible to untrusted application, even
> if the IOMMU is enabled. To be accessed via vfio-pci, the user has to
> explicitly disable
On Thu, 23 Jul 2020 08:57:11 -0700
Sean Christopherson wrote:
> On Tue, Jul 21, 2020 at 10:00:36AM -0600, Alex Williamson wrote:
> > On Mon, 20 Jul 2020 20:03:19 -0700
> > Sean Christopherson wrote:
> >
> > > +Weijiang
> > >
> > >
On Thu, 23 Jul 2020 11:38:21 -0400
Alan Stern wrote:
> On Wed, Jul 22, 2020 at 10:18:17PM -0600, Alex Williamson wrote:
> > On Thu, 23 Jul 2020 02:59:55 +
> > "Weitao Wang(BJ-RD)" wrote:
> >
> > > On , Jul 22, 2020 at 02:44:14PM +0200, Alan wrote:
On Tue, 14 Jul 2020 07:36:07 +0100
Giovanni Cabiddu wrote:
> Add blocklist of devices that by default are not probed by vfio-pci.
> Devices in this list may be susceptible to untrusted application, even
> if the IOMMU is enabled. To be accessed via vfio-pci, the user has to
> explicitly disable
On Thu, 23 Jul 2020 02:59:55 +
"Weitao Wang(BJ-RD)" wrote:
> On , Jul 22, 2020 at 02:44:14PM +0200, Alan wrote:
> > On Wed, Jul 22, 2020 at 02:44:14PM +0200, Greg KH wrote:
> > > On Wed, Jul 22, 2020 at 07:57:48PM +0800, WeitaoWangoc wrote:
> > > > This bug is found in Zhaoxin platform,
On Wed, 22 Jul 2020 19:57:48 +0800
WeitaoWangoc wrote:
> This bug is found in Zhaoxin platform, but it's a commom code bug.
> Fail sequence:
> step1: Unbind UHCI controller from native driver;
> step2: Bind UHCI controller to vfio-pci, which will put UHCI controller in
> one vfio
>
On Mon, 20 Jul 2020 20:03:19 -0700
Sean Christopherson wrote:
> +Weijiang
>
> On Mon, Jul 13, 2020 at 12:06:50PM -0700, Sean Christopherson wrote:
> > The only ideas I have going forward are to:
> >
> > a) Reproduce the bug outside of your environment and find a resource that
> > can go
On Mon, 20 Jul 2020 16:29:47 +0800
Jay Zhou wrote:
> From: Ming Mao
>
> Hi all,
> I'm working on starting lots of big size
> Virtual Machines(memory: >128GB) with VFIO-devices. And I
> encounter a problem that is the waiting time of starting
> all Virtual Machines is too long. I analyze the
No need to release and immediately re-acquire igate while clearing
out the eventfd ctxs.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index
On Mon, 20 Jul 2020 13:33:29 -0700
Linus Torvalds wrote:
> On Mon, Jul 20, 2020 at 7:34 AM Alex Williamson
> wrote:
> >
> > VFIO fixes for v5.8-rc7
> >
> > - Fix race with eventfd ctx cleared outside of mutex (Zeng Tao)
>
> Why does this take and then re-
Hi Linus,
The following changes since commit 11ba468877bb23f28956a35e896356252d63c983:
Linux 5.8-rc5 (2020-07-12 16:34:50 -0700)
are available in the Git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v5.8-rc7
for you to fetch changes up to
On Thu, 16 Jul 2020 11:45:16 -0700
Jacob Pan wrote:
> IOMMU UAPI data has a user filled argsz field which indicates the data
> length comes with the API call. User data is not trusted, argsz must be
> validated based on the current kernel data size, mandatory data size,
> and feature flags.
>
>
On Thu, 16 Jul 2020 11:45: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 Mon, 13 Jul 2020 22:00:23 -0700
Jacob Pan wrote:
> Hi Alex,
>
> On Mon, 13 Jul 2020 16:48:42 -0600
> Alex Williamson wrote:
>
> > On Tue, 7 Jul 2020 16:43:45 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI is newly introduced to support commun
On Tue, 7 Jul 2020 16:43:45 -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 Thu, 9 Jul 2020 21:29:22 -0700
Sean Christopherson wrote:
> +Alex, whom I completely spaced on Cc'ing.
>
> Alex, this is related to the dreaded VFIO memslot zapping issue from last
> year. Start of thread: https://patchwork.kernel.org/patch/11640719/.
>
> The TL;DR of below: can you try
On Fri, 10 Jul 2020 10:44:33 -0500
Bjorn Helgaas wrote:
> On Fri, Jul 10, 2020 at 10:37:45AM -0500, Bjorn Helgaas wrote:
> > On Fri, Jul 10, 2020 at 04:08:19PM +0100, Giovanni Cabiddu wrote:
> > > On Wed, Jul 01, 2020 at 04:28:12PM -0500, Bjorn Helgaas wrote:
> > > > On Wed, Jul 01, 2020 at
On Fri, 10 Jul 2020 05:39:57 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> > From: Alex Williamson
> > Sent: Thursday, July 9, 2020 10:28 PM
> >
> > On Thu, 9 Jul 2020 07:16:31 +
> > "Liu, Yi L" wrote:
> >
> > >
On Mon, 6 Jul 2020 18:41:48 +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 Mon, 6 Jul 2020 18:41:46 +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:
201 - 300 of 5215 matches
Mail list logo
