On 2020-06-30 20:08, Jonathan Lemon wrote:
On Mon, Jun 29, 2020 at 02:15:16PM +0100, Robin Murphy wrote:
On 2020-06-27 08:02, Christoph Hellwig wrote:
On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote:
On Fri, Jun 26, 2020 at 09:47:25AM +0200, Christoph Hellwig wrote:
Note that
On Wed, Jul 01, 2020 at 12:40:50AM -0700, Bjorn Andersson wrote:
> On Wed 03 Jun 04:00 PDT 2020, Robin Murphy wrote:
> > at that point I'm inclined to suggest we give up and stop trying to
> > drive these things with arm-smmu. The XZR thing was bad enough, but if
> > they're not even going to
On 2020-06-29 17:41, Robin Murphy wrote:
On 2020-06-28 18:16, Björn Töpel wrote:
[...]>
Somewhat related to the DMA API; It would have performance benefits for
AF_XDP if the DMA range of the mapped memory was linear, i.e. by IOMMU
utilization. I've started hacking a thing a little bit, but it
Hi Will, Robin,
On 2020-06-27 01:30, Jordan Crouse wrote:
Another iteration of the split-pagetable support for arm-smmu and the
Adreno GPU
SMMU. After email discussions [1] we opted to make a arm-smmu
implementation for
specifically for the Adreno GPU and use that to enable split pagetable
On 2020-07-01 01:40, Qian Cai wrote:
Looks like this patchset introduced an use-after-free on arm-smmu-v3.
Reproduced using mlx5,
# echo 1 > /sys/class/net/enp11s0f1np1/device/sriov_numvfs
# echo 0 > /sys/class/net/enp11s0f1np1/device/sriov_numvfs
The .config,
On 2020-07-01 08:32, Lu Baolu wrote:
Hi Robin,
On 2020/7/1 0:51, Robin Murphy wrote:
On 2020-06-30 02:03, Lu Baolu wrote:
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio mediated device is a use case of iommu
aux-domain.
On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote:
> > I could imagine some future Xen hosts setting a flag somewhere in the
> > platform capability saying "no xen specific flag, rely on
> > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU.
> > How about that?
>
On Wed, 1 Jul 2020 09:45:40 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 7/1/20 1:34 AM, Jacob Pan wrote:
> > On Thu, 25 Jun 2020 18:10:43 +0800
> > Lu Baolu wrote:
> >
> >> Hi,
> >>
> >> On 2020/6/23 23:43, Jacob Pan wrote:
> >>> For guest requested IOTLB invalidation, address and mask are
>
On Wed, 1 Jul 2020 08:49:54 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 7/1/20 5:07 AM, Jacob Pan wrote:
> > DevTLB flush can be used for both DMA request with and without
> > PASIDs. The former uses PASID#0 (RID2PASID), latter uses non-zero
> > PASID for SVA usage.
> >
> > This patch adds a
On 30/06/2020 12:59, chao hao wrote:
> On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Some platforms(ex: mt6779) need to improve performance by setting
>>> REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
>>> whether
On 6/19/2020 11:20 AM, Lorenzo Pieralisi wrote:
> From: Makarand Pawagi
>
> Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
> extract memory and other resources.
>
> Interrupt (GIC ITS) information is extracted from the MADT table
> by
On 30/06/2020 12:53, chao hao wrote:
> On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>>
>> On 29/06/2020 09:13, Chao Hao wrote:
>>> Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
>>> in MISC_CTRL register.
>>> F_MMU_STANDARD_AXI_MODE_BIT:
>>> If we set
For guest requested IOTLB invalidation, address and mask are provided as
part of the invalidation data. VT-d HW silently ignores any address bits
below the mask. SW shall also allow such case but give warning if
address does not align with the mask. This patch relax the fault
handling from error
From: Liu Yi L
Address information for device TLB invalidation comes from userspace
when device is directly assigned to a guest with vIOMMU support.
VT-d requires page aligned address. This patch checks and enforce
address to be page aligned, otherwise reserved bits can be set in the
From: Liu Yi L
For guest SVA usage, in order to optimize for less VMEXIT, guest request
of IOTLB flush also includes device TLB.
On the host side, IOMMU driver performs IOTLB and implicit devTLB
invalidation. When PASID-selective granularity is requested by the guest
we need to derive the
Global pages support is removed from VT-d spec 3.0 for dev TLB
invalidation. This patch is to remove the bits for vSVA. Similar change
already made for the native SVA. See the link below.
Link: https://lkml.org/lkml/2019/8/26/651
Acked-by: Lu Baolu
Signed-off-by: Jacob Pan
---
For the unlikely use case where multiple aux domains from the same pdev
are attached to a single guest and then bound to a single process
(thus same PASID) within that guest, we cannot easily support this case
by refcounting the number of users. As there is only one SL page table
per PASID while
From: Liu Yi L
Set proper masks to avoid invalid input spillover to reserved bits.
Acked-by: Lu Baolu
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
include/linux/intel-iommu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/intel-iommu.h
Hi Baolu and all,
This is a series to address some of the issues we found in vSVA support.
Most of the patches deal with exception handling, we also removed some bits
that are not currently supported.
Many thanks to Kevin Tian's review.
Jacob & Yi
Changelog:
v3
- Use pr_err instead of
DevTLB flush can be used for both DMA request with and without PASIDs.
The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
usage.
This patch adds a check for PASID value such that devTLB flush with
PASID is used for SVA case. This is more efficient in that multiple
PASIDs can
On 2020-06-30 14:04, Hanjun Guo wrote:
On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
For devices that aren't described in the DSDT - IORT translations
are determined by their ACPI parent device. Do you see/Have you
found any
On Wed, 1 Jul 2020, Christoph Hellwig wrote:
> On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote:
> > > I could imagine some future Xen hosts setting a flag somewhere in the
> > > platform capability saying "no xen specific flag, rely on
> > > "VIRTIO_F_ACCESS_PLATFORM". Then you
>> + * When Linux kernel supports multiple SMMU devices, the SMMU device
>> +used for
>> + * isochornous HW devices should be added as a separate ARM MMU-500
>> +device
>> + * in DT and be programmed independently for efficient TLB invalidates.
>I don't understand the "When" there - the driver
>> With shared irq line, the context fault identification is not optimal
>> already. Reading all the context banks all the time can be additional mmio
>> read overhead. But, it may not hurt the real use cases as these happen only
>> when there are bugs.
>Right, I did ponder the idea of a
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v6:
Commit "device core: Introduce DMA range map":
--
On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> Would you be in favor of a more flexible check along the lines of the
> one proposed in the patch that started this thread:
>
> if (xen_vring_use_dma())
> return true;
>
>
> xen_vring_use_dma would be
Hello,
On Tue, Jun 30, 2020 at 10:00 AM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 30, 2020 at 06:08:31PM +0200, Rafael J. Wysocki wrote:
> > On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> > > > On
+items:
+ - enum:
+ - nvdia,tegra194-smmu
+ - const: arm,mmu-500
> >
>>> Is the fallback compatible appropriate here? If software treats this as a
>>> standard MMU-500 it will only program the first instance (because the
>>> second isn't
On 2020-07-01 19:48, Krishna Reddy wrote:
+for (inst = 0; inst < nvidia_smmu->num_inst; inst++) {
+irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst);
+if (irq_ret == IRQ_HANDLED)
+return irq_ret;
Any chance there could be more than one
>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500"
> Hmm, there must be a better way to word that to express that it only applies
> to the sets of SMMUs that must be programmed identically, and not any other
> independent MMU-500s that might also happen to be in the same
On 2020-07-01 19:18, Krishna Reddy wrote:
+ * When Linux kernel supports multiple SMMU devices, the SMMU
device +used for + * isochornous HW devices should be added as a
separate ARM MMU-500 +device + * in DT and be programmed
independently for efficient TLB invalidates.
I don't understand
On 01/07/2020 19:28, Krishna Reddy wrote:
>>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500"
>> Hmm, there must be a better way to word that to express that it only applies
>> to the sets of SMMUs that must be programmed identically, and not any other
>> independent
>>> +for (inst = 0; inst < nvidia_smmu->num_inst; inst++) {
>>> +irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst);
>>> +if (irq_ret == IRQ_HANDLED)
>>> +return irq_ret;
>>
>> Any chance there could be more than one SMMU faulting by the time
On 2020-07-01 19:47, Jon Hunter wrote:
On 01/07/2020 19:28, Krishna Reddy wrote:
+ - description: NVIDIA SoCs that use more than one "arm,mmu-500"
Hmm, there must be a better way to word that to express that it only applies to
the sets of SMMUs that must be programmed identically, and
On 01/07/2020 20:00, Krishna Reddy wrote:
>> +items:
>> + - enum:
>> + - nvdia,tegra194-smmu
>> + - const: arm,mmu-500
> Is the fallback compatible appropriate here? If software treats this as a
> standard MMU-500 it will only
Hi Robin,
On 7/1/20 8:18 PM, Robin Murphy wrote:
On 2020-07-01 08:32, Lu Baolu wrote:
Hi Robin,
On 2020/7/1 0:51, Robin Murphy wrote:
On 2020-06-30 02:03, Lu Baolu wrote:
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio
From: Rajat Jain
[ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ]
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the
On 7/1/20 11:33 PM, Jacob Pan wrote:
For guest requested IOTLB invalidation, address and mask are provided as
part of the invalidation data. VT-d HW silently ignores any address bits
below the mask. SW shall also allow such case but give warning if
address does not align with the mask. This
From: Rajat Jain
[ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ]
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the
On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote:
>
> *snip*
>
> > > I guess it would make sense to have an attribute for user space to
> > > write to in order to make the kernel reject device plug-in events
> > > coming from a given port or connector, but the kernel has no reliable
> > > means to
On 7/1/20 11:33 PM, Jacob Pan wrote:
DevTLB flush can be used for both DMA request with and without PASIDs.
The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
usage.
This patch adds a check for PASID value such that devTLB flush with
PASID is used for SVA case. This is more
Hello,
On 7/1/20 8:18 PM, Robin Murphy wrote:
On 2020-07-01 08:32, Lu Baolu wrote:
Hi Robin,
On 2020/7/1 0:51, Robin Murphy wrote:
On 2020-06-30 02:03, Lu Baolu wrote:
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio
>Yeah, I realised later last night that this probably originated from forking
>the whole driver downstream. But even then you could have treated the other
>one as a separate nsmmu with a single instance ;)
True, But the initial nvidia implementation had limitation that it can only
handle one
On 01/07/2020 20:00, Krishna Reddy wrote:
> +items:
> + - enum:
> + - nvdia,tegra194-smmu
> + - const: arm,mmu-500
>>>
Is the fallback compatible appropriate here? If software treats this as a
standard MMU-500 it will only program
On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> On Wed, 1 Jul 2020, Christoph Hellwig wrote:
> > On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote:
> > > > I could imagine some future Xen hosts setting a flag somewhere in the
> > > > platform capability
On Wed 03 Jun 04:00 PDT 2020, Robin Murphy wrote:
> On 2020-06-02 07:32, Bjorn Andersson wrote:
> > On Wed 27 May 04:03 PDT 2020, Will Deacon wrote:
> >
> > > Hi John, Bjorn,
> > >
> > > On Tue, May 26, 2020 at 01:34:45PM -0700, John Stultz wrote:
> > > > On Thu, May 14, 2020 at 12:34 PM
On 01/07/2020 00:57, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC has three ARM MMU-500 instances.
> It uses two of ARM MMU-500s together to interleave IOVA accesses
> across them and must be programmed identically.
> The third SMMU instance is used as a regular ARM MMU-500 and it
> can either
Hi Robin,
On 2020/7/1 0:51, Robin Murphy wrote:
On 2020-06-30 02:03, Lu Baolu wrote:
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and
On 01/07/2020 00:57, Krishna Reddy wrote:
> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
> on ARM MMU-500.
>
> Signed-off-by: Krishna Reddy
> ---
> .../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git
50 matches
Mail list logo
