On 04/06/21 19:22, Jason Gunthorpe wrote:
4) The KVM interface is the very simple enable/disable WBINVD.
Possessing a FD that can do IOMMU_EXECUTE_WBINVD is required
to enable WBINVD at KVM.
The KVM interface is the same kvm-vfio device that exists already. The
userspace API does
> From: Jason Gunthorpe
> Sent: Friday, June 4, 2021 8:34 PM
>
> On Fri, Jun 04, 2021 at 06:08:28AM +, Tian, Kevin wrote:
>
> > In Qemu case the problem is that it doesn't know the list of devices
> > that will be attached to an IOASID when it's created. This is a guest-
> > side knowledge w
> From: Jason Gunthorpe
> Sent: Friday, June 4, 2021 8:09 PM
>
> On Fri, Jun 04, 2021 at 06:37:26AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 3, 2021 9:05 PM
> > >
> > > > >
> > > > > 3) Device accepts any PASIDs from the guest. No
> > > > >vPASID/pPASID
On Fri, Jun 04, 2021 at 03:29:18PM -0600, Alex Williamson wrote:
> On Fri, 4 Jun 2021 14:22:07 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, Jun 04, 2021 at 06:10:51PM +0200, Paolo Bonzini wrote:
> > > On 04/06/21 18:03, Jason Gunthorpe wrote:
> > > > On Fri, Jun 04, 2021 at 05:57:19PM +0200, Pa
On Fri, 4 Jun 2021 09:13:37 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 03, 2021 at 02:41:36PM -0600, Alex Williamson wrote:
>
> > Could you clarify "vfio_driver"?
>
> This is the thing providing the vfio_device_ops function pointers.
>
> So vfio-pci can't know anything about this (although
On Fri, 4 Jun 2021 14:22:07 -0300
Jason Gunthorpe wrote:
> On Fri, Jun 04, 2021 at 06:10:51PM +0200, Paolo Bonzini wrote:
> > On 04/06/21 18:03, Jason Gunthorpe wrote:
> > > On Fri, Jun 04, 2021 at 05:57:19PM +0200, Paolo Bonzini wrote:
> > > > I don't want a security proof myself; I want to
> On Jun 4, 2021, at 11:53 AM, Robin Murphy wrote:
>
> On 2021-06-04 18:10, Nadav Amit wrote:
>>> On Jun 4, 2021, at 8:38 AM, Joerg Roedel wrote:
>>>
>>> Hi Nadav,
>>>
>>> [Adding Robin]
>>>
>>> On Mon, May 24, 2021 at 03:41:55PM -0700, Nadav Amit wrote:
Nadav Amit (4):
iommu/amd
[+cc John, who tested 6bf6c24720d3]
On Fri, May 21, 2021 at 03:03:24AM +, Wang Xingang wrote:
> From: Xingang Wang
>
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. And ACS should be ena
On 2021-06-04 18:10, Nadav Amit wrote:
On Jun 4, 2021, at 8:38 AM, Joerg Roedel wrote:
Hi Nadav,
[Adding Robin]
On Mon, May 24, 2021 at 03:41:55PM -0700, Nadav Amit wrote:
Nadav Amit (4):
iommu/amd: Fix wrong parentheses on page-specific invalidations
This patch is already upstream in
Hi Jason,
On Fri, 4 Jun 2021 13:22:00 -0300, Jason Gunthorpe wrote:
> >
> > Yes, in that case we should support both. Give the device driver a
> > chance to handle the IOPF if it can.
>
> Huh?
>
> The device driver does not "handle the IOPF" the device driver might
> inject the IOPF.
You ar
Hi Claire,
On Thu, May 27, 2021 at 08:58:30PM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leadin
On Fri, Jun 04, 2021 at 10:27:43AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Fri, 4 Jun 2021 09:05:55 -0300, Jason Gunthorpe wrote:
>
> > On Fri, Jun 04, 2021 at 12:24:08PM +0200, Jean-Philippe Brucker wrote:
> >
> > > I think once it binds a device to an IOASID fd, QEMU will want to probe
> >
On 2021-06-04 16:26, Joerg Roedel wrote:
On Thu, Jun 03, 2021 at 02:48:21PM +0100, Robin Murphy wrote:
As discussed on the report thread, I think it makes most sense to merge
this as a fix for 5.13 and not worry about any backporting.
drivers/iommu/amd/amd_iommu.h | 2 --
drivers/iommu/amd/
Hi Jason,
On Fri, 4 Jun 2021 09:05:55 -0300, Jason Gunthorpe wrote:
> On Fri, Jun 04, 2021 at 12:24:08PM +0200, Jean-Philippe Brucker wrote:
>
> > I think once it binds a device to an IOASID fd, QEMU will want to probe
> > what hardware features are available before going further with the
> > v
On Fri, Jun 04, 2021 at 06:10:51PM +0200, Paolo Bonzini wrote:
> On 04/06/21 18:03, Jason Gunthorpe wrote:
> > On Fri, Jun 04, 2021 at 05:57:19PM +0200, Paolo Bonzini wrote:
> > > I don't want a security proof myself; I want to trust VFIO to make the
> > > right
> > > judgment and I'm happy to def
> On Jun 4, 2021, at 8:38 AM, Joerg Roedel wrote:
>
> Hi Nadav,
>
> [Adding Robin]
>
> On Mon, May 24, 2021 at 03:41:55PM -0700, Nadav Amit wrote:
>> Nadav Amit (4):
>> iommu/amd: Fix wrong parentheses on page-specific invalidations
>
> This patch is already upstream in v5.13-rc4. Please re
Add internal ops to be able to handle incoming variant v2.
The goal is to keep the overall structure of the framework but
to allow to add the evolution of this hardware block.
The ops are global for a SoC because iommu domains are not
attached to a specific devices if they are for a virtuel device
Convert Rockchip IOMMU to DT schema
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
.../bindings/iommu/rockchip,iommu.txt | 38 -
.../bindings/iommu/rockchip,iommu.yaml| 80 +++
2 files changed, 80 insertions(+),
This second version of the hardware block has a different bits
mapping for page table entries.
Add the ops matching to this new mapping.
Define a new compatible to distinguish it from the first version.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Heiko Stuebner
---
version 8:
- Fix compilatio
Add compatible for the second version of IOMMU hardware block.
RK356x IOMMU can also be link to a power domain.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
.../devicetree/bindings/iommu/rockchip,iommu.yaml | 7 ++-
1 file changed, 6 in
This series adds the IOMMU driver for rk356x SoC.
Since a new compatible is needed to distinguish this second version of
IOMMU hardware block from the first one, it is an opportunity to convert
the binding to DT schema.
version 8:
- Fix compilation issue.
version 7:
- Set DMA mask
- Fix rk_io
On Fri, Jun 04, 2021 at 09:22:43AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Fri, 4 Jun 2021 09:30:37 +0800, Jason Wang wrote:
>
> > 在 2021/6/4 上午2:19, Jacob Pan 写道:
> > > Hi Shenming,
> > >
> > > On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
> > > wrote:
> > >
> > >> On 2021/6/2 1:33, Jaso
Hi Jason,
On Fri, 4 Jun 2021 09:30:37 +0800, Jason Wang wrote:
> 在 2021/6/4 上午2:19, Jacob Pan 写道:
> > Hi Shenming,
> >
> > On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
> > wrote:
> >
> >> On 2021/6/2 1:33, Jason Gunthorpe wrote:
> >>> On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wro
On 04/06/21 18:03, Jason Gunthorpe wrote:
On Fri, Jun 04, 2021 at 05:57:19PM +0200, Paolo Bonzini wrote:
I don't want a security proof myself; I want to trust VFIO to make the right
judgment and I'm happy to defer to it (via the KVM-VFIO device).
Given how KVM is just a device driver inside Lin
On Fri, Jun 04, 2021 at 05:57:19PM +0200, Paolo Bonzini wrote:
> On 04/06/21 17:50, Jason Gunthorpe wrote:
> > > Extending the scenarios where WBINVD is not a nop is not a problem for me.
> > > If possible I wouldn't mind keeping the existing kvm-vfio connection via
> > > the
> > > device, if only
On 04/06/21 17:50, Jason Gunthorpe wrote:
Extending the scenarios where WBINVD is not a nop is not a problem for me.
If possible I wouldn't mind keeping the existing kvm-vfio connection via the
device, if only because then the decision remains in the VFIO camp (whose
judgment I trust more than mi
On Fri, Jun 04, 2021 at 05:40:34PM +0200, Paolo Bonzini wrote:
> On 04/06/21 17:26, Alex Williamson wrote:
> > Let's make sure the KVM folks are part of this decision; a re-cap for
> > them, KVM currently automatically enables wbinvd emulation when
> > potentially non-coherent devices are present w
On Thu, May 27, 2021 at 02:37:09PM -0500, Rob Herring wrote:
> drivers/iommu/of_iommu.c | 68
> include/linux/of_iommu.h | 17 ++
> 2 files changed, 3 insertions(+), 82 deletions(-)
Applied both, thanks.
On Thu, Jun 03, 2021 at 01:05:43PM +0100, Robin Murphy wrote:
> Hooray! I've been forecasting this for years, but the cases we regularly hit
> with internal FPGA prototyping (nor the secret unused MMU-400 I found on
> RK3288) have never really been a strong enough argument to stand behind.
>
> Bas
On 04/06/21 17:26, Alex Williamson wrote:
Let's make sure the KVM folks are part of this decision; a re-cap for
them, KVM currently automatically enables wbinvd emulation when
potentially non-coherent devices are present which is determined solely
based on the IOMMU's (or platform's, as exposed v
Hi Nadav,
[Adding Robin]
On Mon, May 24, 2021 at 03:41:55PM -0700, Nadav Amit wrote:
> Nadav Amit (4):
> iommu/amd: Fix wrong parentheses on page-specific invalidations
This patch is already upstream in v5.13-rc4. Please rebase to that
version.
> iommu/amd: Selective flush on unmap
> iomm
On Fri, 4 Jun 2021 09:19:50 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Friday, June 4, 2021 4:42 AM
> >
> > > 'qemu --allow-no-snoop' makes more sense to me
> >
> > I'd be tempted to attach it to the -device vfio-pci option, it's
> > specific drivers for specific device
On Fri, May 21, 2021 at 03:03:24AM +, Wang Xingang wrote:
> From: Xingang Wang
>
> When booting with devicetree, the pci_request_acs() is called after the
> enumeration and initialization of PCI devices, thus the ACS is not
> enabled. And ACS should be enabled when IOMMU is detected for the
>
On Mon, May 10, 2021 at 07:53:02PM +0800, chenxiang wrote:
> From: Xiang Chen
>
> It is not necessary to put free_iova_mem() inside of spinlock/unlock
> iova_rbtree_lock which only leads to more completion for the spinlock.
> It has a small promote on the performance after the change. And also
>
On Mon, Sep 14, 2020 at 12:53:19PM +0530, Srinath Mannam wrote:
> Fix IOVA reserve failure in the case when address of first memory region
> listed in dma-ranges is equal to 0x0.
>
> Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
> address")
> Signed-off-by: Srinath Mann
[Cc +Paolo]
On Fri, 4 Jun 2021 09:28:30 -0300
Jason Gunthorpe wrote:
> On Fri, Jun 04, 2021 at 08:38:26AM +, Tian, Kevin wrote:
> > > I think more to drive the replacement design; if we can't figure out
> > > how to do something other than backwards compatibility trickery in the
> > > kernel
On Thu, Jun 03, 2021 at 02:48:21PM +0100, Robin Murphy wrote:
> As discussed on the report thread, I think it makes most sense to merge
> this as a fix for 5.13 and not worry about any backporting.
>
> drivers/iommu/amd/amd_iommu.h | 2 --
> drivers/iommu/amd/init.c | 5 -
> drivers/io
On Thu, Jun 03, 2021 at 09:26:39AM +0200, Jean-Philippe Brucker wrote:
> These are only defined when CONFIG_IOMMU_API is set. IORT uses them inside
> an #ifdef, I can do the same. Maybe moving these two functions to a new
> drivers/acpi/iommu.c would be nicer, though.
Not sure what the ACPI mainta
On Fri, May 21, 2021 at 02:49:39PM +0100, Robin Murphy wrote:
> When we allocate new pagetable pages, we don't modify them between the
> initial dma_map_single() call and the dma_sync_single_for_device() call
> via rk_iommu_flush(), so the latter is entirely pointless.
>
> Signed-off-by: Robin Mur
On Fri, Jun 04, 2021 at 04:54:58PM +0200, Joerg Roedel wrote:
> On Tue, May 25, 2021 at 02:15:47PM +0200, Benjamin Gaignard wrote:
> > Benjamin Gaignard (4):
> > dt-bindings: iommu: rockchip: Convert IOMMU to DT schema
> > dt-bindings: iommu: rockchip: Add compatible for v2
> > iommu: rockchi
On Tue, May 25, 2021 at 02:15:47PM +0200, Benjamin Gaignard wrote:
> Benjamin Gaignard (4):
> dt-bindings: iommu: rockchip: Convert IOMMU to DT schema
> dt-bindings: iommu: rockchip: Add compatible for v2
> iommu: rockchip: Add internal ops to handle variants
Applied patches 1-3, thanks.
___
On Wed, May 19, 2021 at 11:37:27AM +0800, Shaokun Zhang wrote:
> 'err' will be initialized and cleanup the redundant initialization.
>
> Cc: Joerg Roedel
> Signed-off-by: Shaokun Zhang
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundat
On Tue, May 04, 2021 at 01:22:20PM +0300, Alexander Monakov wrote:
> Fixes: 9a295ff0ffc9 ("iommu/amd: Print extended features in one line to fix
> divergent log levels")
> Link:
> https://lore.kernel.org/lkml/alpine.lnx.2.20.13.2104112326460.11...@monopod.intra.ispras.ru
> Signed-off-by: Alexande
On Fri, Jun 04, 2021 at 06:08:28AM +, Tian, Kevin wrote:
> In Qemu case the problem is that it doesn't know the list of devices
> that will be attached to an IOASID when it's created. This is a guest-
> side knowledge which is conveyed one device at a time to Qemu
> though vIOMMU.
At least f
On Fri, Jun 04, 2021 at 12:44:28PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 02.06.21 19:24, Jason Gunthorpe wrote:
>
> Hi,
>
> >> If I understand this correctly, /dev/ioasid is a kind of "common
> supplier"
> >> to other APIs / devices. Why can't the fd be acquired by the
> >> consume
On Fri, Jun 04, 2021 at 08:38:26AM +, Tian, Kevin wrote:
> > I think more to drive the replacement design; if we can't figure out
> > how to do something other than backwards compatibility trickery in the
> > kernel, it's probably going to bite us. Thanks,
>
> I'm a bit lost on the desired fl
On Thu, Jun 03, 2021 at 02:41:36PM -0600, Alex Williamson wrote:
> Could you clarify "vfio_driver"?
This is the thing providing the vfio_device_ops function pointers.
So vfio-pci can't know anything about this (although your no-snoop
control probing idea makes sense to me)
But vfio_mlx5_pci c
On Fri, Jun 04, 2021 at 06:37:26AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, June 3, 2021 9:05 PM
> >
> > > >
> > > > 3) Device accepts any PASIDs from the guest. No
> > > >vPASID/pPASID translation is possible. (classic vfio_pci)
> > > > 4) Device accepts any PAS
On Fri, Jun 04, 2021 at 12:24:08PM +0200, Jean-Philippe Brucker wrote:
> I think once it binds a device to an IOASID fd, QEMU will want to probe
> what hardware features are available before going further with the vIOMMU
> setup (is there PASID, PRI, which page table formats are supported,
I thin
On Fri, Jun 04, 2021 at 09:11:03AM +0800, Jason Wang wrote:
> > nor do any virtio drivers implement the required platform specific
> > cache flushing to make no-snoop TLPs work.
>
> I don't get why virtio drivers needs to do that. I think DMA API should hide
> those arch/platform specific stuffs f
On 02.06.21 19:24, Jason Gunthorpe wrote:
Hi,
>> If I understand this correctly, /dev/ioasid is a kind of "common
supplier"
>> to other APIs / devices. Why can't the fd be acquired by the
>> consumer APIs (eg. kvm, vfio, etc) ?
>
> /dev/ioasid would be similar to /dev/vfio, and everything alre
On Thu, Jun 03, 2021 at 03:45:09PM +1000, David Gibson wrote:
> > > But it would certainly be possible for a system to have two
> > > different host bridges with two different IOMMUs with different
> > > pagetable formats. Until you know which devices (and therefore
> > > which host bridge) you're
> From: Alex Williamson
> Sent: Friday, June 4, 2021 4:42 AM
>
> > 'qemu --allow-no-snoop' makes more sense to me
>
> I'd be tempted to attach it to the -device vfio-pci option, it's
> specific drivers for specific devices that are going to want this and
> those devices may not be permanently at
> From: Jean-Philippe Brucker
> Sent: Friday, June 4, 2021 4:18 PM
>
> On Wed, Jun 02, 2021 at 01:25:00AM +, Tian, Kevin wrote:
> > > > This implies that VFIO_BOUND_IOASID will be extended to allow user
> > > > specify a device label. This label will be recorded in /dev/iommu to
> > > > serve
> From: Alex Williamson
> Sent: Friday, June 4, 2021 5:44 AM
>
> > Based on that observation we can say as soon as the user wants to use
> > an IOMMU that does not support DMA_PTE_SNP in the guest we can still
> > share the IO page table with IOMMUs that do support DMA_PTE_SNP.
page table sharin
If unsure, say N here.
+choice
+ prompt "IOMMU default DMA mode"
+ depends on IOMMU_API
config INTEL_IOMMU
depends on PCI_MSI && ACPI && (X86 || IA64)
config AMD_IOMMU
depends on X86_64 && PCI && ACPI && HAVE_CMPXCHG_DOUBLE
config ARM_SMMU_V3
On Wed, Jun 02, 2021 at 01:25:00AM +, Tian, Kevin wrote:
> > > This implies that VFIO_BOUND_IOASID will be extended to allow user
> > > specify a device label. This label will be recorded in /dev/iommu to
> > > serve per-device invalidation request from and report per-device
> > > fault data to
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 8:41 PM
>
> > When discussing I/O page fault support in another thread, the consensus
> > is that an device handle will be registered (by user) or allocated (return
> > to user) in /dev/ioasid when binding the device to ioasid fd. From this
>
58 matches
Mail list logo
