Hi Jean,
Have a question for you on whether we can have a fixed token type for
ioasid_set.
Currently, ioasid_set has an arbitrary token. For VT-d vSVA usage, we
choose mm as ioasid_set token to identify PASIDs within a guest. We have
multiple in-kernel users of PASIDs such as VFIO, KVM, and VDCM.
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
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 med
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 mediat
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 devic
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 devic
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 patch
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
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 implement
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":
-- of_dma_get
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 saying
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 pro
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
>> 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 whole
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 SMMU
>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 in
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 no
+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: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 the
>>> +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 we
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 MMU-
>> + - 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 So
>> + * 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 h
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 Tue
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 s
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 drivers/irqchip/irq-gic-v3-its-fsl-
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 iss
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
invalidation
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 to
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 b
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
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 b/include
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 equiva
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
---
drivers/iommu/int
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 we
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 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 F_MMU_S
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 check
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 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 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. The
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 prete
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,
https://github.com/cailca/linux-m
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 w
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
sup
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 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 a/
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 be
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 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. The interactions between vfio/mdev and io
51 matches
Mail list logo
