Re: [PATCH 1/1] Revert "iommu/vt-d: Clean up pasid quirk for pre-production devices"
Hi Joerg,
The graphic guys are looking forward to having this in 4.18.
Is it possible to take it in the following rcs?
Best regards,
Lu Baolu
On 07/08/2018 02:23 PM, Lu Baolu wrote:
> This reverts commit ab96746aaa344fb720a198245a837e266fad3b62.
>
> The commit ab96746aaa34 ("iommu/vt-d: Clean up pasid quirk for
> pre-production devices") triggers ECS mode on some platforms
> which have broken ECS support. As the result, graphic device
> will be inoperable on boot.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107017
>
> Cc: Ashok Raj
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-iommu.c | 32 ++--
> include/linux/intel-iommu.h | 1 +
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index b344a88..115ff26 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -484,14 +484,37 @@ static int dmar_forcedac;
> static int intel_iommu_strict;
> static int intel_iommu_superpage = 1;
> static int intel_iommu_ecs = 1;
> +static int intel_iommu_pasid28;
> static int iommu_identity_mapping;
>
> #define IDENTMAP_ALL 1
> #define IDENTMAP_GFX 2
> #define IDENTMAP_AZALIA 4
>
> -#define ecs_enabled(iommu) (intel_iommu_ecs && ecap_ecs(iommu->ecap))
> -#define pasid_enabled(iommu) (ecs_enabled(iommu) && ecap_pasid(iommu->ecap))
> +/* Broadwell and Skylake have broken ECS support — normal so-called "second
> + * level" translation of DMA requests-without-PASID doesn't actually happen
> + * unless you also set the NESTE bit in an extended context-entry. Which of
> + * course means that SVM doesn't work because it's trying to do nested
> + * translation of the physical addresses it finds in the process page tables,
> + * through the IOVA->phys mapping found in the "second level" page tables.
> + *
> + * The VT-d specification was retroactively changed to change the definition
> + * of the capability bits and pretend that Broadwell/Skylake never
> happened...
> + * but unfortunately the wrong bit was changed. It's ECS which is broken, but
> + * for some reason it was the PASID capability bit which was redefined (from
> + * bit 28 on BDW/SKL to bit 40 in future).
> + *
> + * So our test for ECS needs to eschew those implementations which set the
> old
> + * PASID capabiity bit 28, since those are the ones on which ECS is broken.
> + * Unless we are working around the 'pasid28' limitations, that is, by
> putting
> + * the device into passthrough mode for normal DMA and thus masking the bug.
> + */
> +#define ecs_enabled(iommu) (intel_iommu_ecs && ecap_ecs(iommu->ecap) && \
> + (intel_iommu_pasid28 ||
> !ecap_broken_pasid(iommu->ecap)))
> +/* PASID support is thus enabled if ECS is enabled and *either* of the old
> + * or new capability bits are set. */
> +#define pasid_enabled(iommu) (ecs_enabled(iommu) && \
> + (ecap_pasid(iommu->ecap) ||
> ecap_broken_pasid(iommu->ecap)))
>
> int intel_iommu_gfx_mapped;
> EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
> @@ -554,6 +577,11 @@ static int __init intel_iommu_setup(char *str)
> printk(KERN_INFO
> "Intel-IOMMU: disable extended context table
> support\n");
> intel_iommu_ecs = 0;
> + } else if (!strncmp(str, "pasid28", 7)) {
> + printk(KERN_INFO
> + "Intel-IOMMU: enable pre-production PASID
> support\n");
> + intel_iommu_pasid28 = 1;
> + iommu_identity_mapping |= IDENTMAP_GFX;
> } else if (!strncmp(str, "tboot_noforce", 13)) {
> printk(KERN_INFO
> "Intel-IOMMU: not forcing on after tboot. This
> could expose security risk for tboot\n");
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 1df9401..ef169d6 100644
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ -121,6 +121,7 @@
> #define ecap_srs(e) ((e >> 31) & 0x1)
> #define ecap_ers(e) ((e >> 30) & 0x1)
> #define ecap_prs(e) ((e >> 29) & 0x1)
> +#define ecap_broken_pasid(e) ((e >> 28) & 0x1)
> #define ecap_dis(e) ((e >> 27) & 0x1)
> #define ecap_nest(e) ((e >> 26) & 0x1)
> #define ecap_mts(e) ((e >> 25) & 0x1)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 3/9] iommu/vt-d: Apply global PASID in SVA
On Sat, Jul 14, 2018 at 03:46:56PM +0800, Lu Baolu wrote: > This patch applies the global pasid name space in the shared > virtual address (SVA) implementation. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc: Liu Yi L > Signed-off-by: Lu Baolu > Reviewed-by: Kevin Tian > Reviewed-by: Liu Yi L Reviewed-by: Peter Xu -- Peter Xu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 2/9] iommu/vt-d: Avoid using idr_for_each_entry()
On Sat, Jul 14, 2018 at 03:46:55PM +0800, Lu Baolu wrote: > idr_for_each_entry() is used to iteratte over idr elements > of a given type. It isn't suitable for the globle pasid idr > since the pasid idr consumer could specify different types > of pointers to bind with a pasid. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc: Liu Yi L > Signed-off-by: Lu Baolu > Reviewed-by: Kevin Tian > Reviewed-by: Liu Yi L Reviewed-by: Peter Xu -- Peter Xu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 1/9] iommu/vt-d: Global PASID name space
On Sat, Jul 14, 2018 at 03:46:54PM +0800, Lu Baolu wrote: > This adds the system wide PASID name space for the PASID > allocation. Currently we are using per IOMMU PASID name > spaces which are not suitable for some use cases. For an > example, one application (associated with a PASID) might > talk to two physical devices simultaneously while the two > devices could reside behind two different IOMMU units. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc: Liu Yi L > Suggested-by: Ashok Raj > Signed-off-by: Lu Baolu > Reviewed-by: Kevin Tian > Reviewed-by: Liu Yi L Reviewed-by: Peter Xu -- Peter Xu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Borken IOMMU+i915
Hi Peter, There is already a patch to revert that broken patch. https://patchwork.kernel.org/patch/10513017/ Best regards, Lu Baolu On 07/15/2018 04:29 PM, peter.ch...@data61.csiro.au wrote: > Hi Lu, > In recent kernels, i915 graphics with intel_iommu=on has been > giving me a blank screen. > > git bisect points at your patch ab96746aaa34 > "iommu/vt-d: Clean up pasid quirk for pre-production devices" > > Either one of the pre-production devices made it into my Dell > laptop, or there's something else wrong with the patch. > > Reverting that patch gives me text console and X11 graphics; > keeping it in yields a blank screen on boot. > > My laptop is a Dell Inc. Precision 7710/0PMJX2, BIOS 1.15.4 12/08/2017 > CPU is Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz > (family: 0x6, model: 0x5e, stepping: 0x3) > > Peter C ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Borken IOMMU+i915
Hi Lu, In recent kernels, i915 graphics with intel_iommu=on has been giving me a blank screen. git bisect points at your patch ab96746aaa34 "iommu/vt-d: Clean up pasid quirk for pre-production devices" Either one of the pre-production devices made it into my Dell laptop, or there's something else wrong with the patch. Reverting that patch gives me text console and X11 graphics; keeping it in yields a blank screen on boot. My laptop is a Dell Inc. Precision 7710/0PMJX2, BIOS 1.15.4 12/08/2017 CPU is Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz (family: 0x6, model: 0x5e, stepping: 0x3) Peter C -- Dr Peter Chubb Tel: +61 2 9490 5852 http://ts.data61.csiro.au/ Trustworthy Systems Group Data61, CSIRO (formerly NICTA) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: convert parisc to the generic dma-noncoherent code
On 2018-07-13 4:14 AM, Helge Deller wrote: On 11.07.2018 17:34, Christoph Hellwig wrote: ping? Any comments? I applied those 3 patches on top of git head, and booted the 32-bit kernel on a HP 715/64 (PCX-L) and a HP B160L (PCX-L2). On both machines I had problems with those drivers which use DMA (I checked specifically the lasi NIC card, which is the main onboard NIC card in both machines). Getting IP via DHCP was unreliable, pings on the same network to both machines gave lost packets, login via ssh sometimes failed and so on. So, there is definitively some cache-flush missing in this patchset. Possibly, the code should use flush_kernel_vmap_range() as it purges the TLB entries used for the cache flush. Some of the routines in pci-dma.c currently use it. Dave -- John David Anglin dave.ang...@bell.net ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dma-mapping: Relax warnings for per-device areas
Hi Christoph, Robin, On Thu, Jul 05, 2018 at 09:36:13PM +0200, Christoph Hellwig wrote: > > - BUG_ON(!ops); > > - WARN_ON_ONCE(dev && !dev->coherent_dma_mask); > > - > > if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr)) > > return cpu_addr; > > > > + BUG_ON(!ops); > > + WARN_ON_ONCE(dev && !dev->coherent_dma_mask); > > I think doing dma on a device without ops is completely broken no matter > what you think of it, so I very much disagree with that part of the change. > > Also while I don't think not having a dma mask is a good idea even for > a driver purely using dma coherent pools. If the pools really are on > the device itself I can see why it might not matter, but for the case > commonly used on some ARM SOCs where we just reserve memory for certain > devices from a system pool it very much does matter. > > There really is no good excuse to not set a coherent mask in the drivers. Here are three other regressions related to the coherent mask WARN_ON_ONCE: WARNING: CPU: 0 PID: 382 at ./include/linux/dma-mapping.h:516 .dma_pool_alloc+0xb8/0x238 Modules linked in: ehci_hcd(+) usbcore usb_common CPU: 0 PID: 382 Comm: modprobe Not tainted 4.18.0-rc3-00022-g06ddb9e4cfce #52 NIP: c018f540 LR: c018f4f4 CTR: c018f488 REGS: cd536f20 TRAP: 0700 Not tainted (4.18.0-rc3-00022-g06ddb9e4cfce) MSR: 80028032 CR: 24024242 XER: 2000 IRQMASK: 0 GPR00: c018f4f4 cd5371a0 c0a81e00 cd52a858 GPR04: 1000 cd34c318 0001 ce517290 GPR08: 0dbbb000 c04d5b00 d027f6f0 GPR12: c018f488 c0b0b000 c0636bd0 GPR16: c0680ab0 0100 c0a11848 GPR20: 006000c0 c04d8210 cd572400 d0281850 GPR24: cd5372c0 cd39a610 006000c0 GPR28: cd39a600 006000c0006000c0 cd39a600 cd34c300 NIP [c018f540] .dma_pool_alloc+0xb8/0x238 LR [c018f4f4] .dma_pool_alloc+0x6c/0x238 Call Trace: [cd5371a0] [c018f4f4] .dma_pool_alloc+0x6c/0x238 (unreliable) [cd537250] [d02765ec] .ehci_qh_alloc+0x4c/0xd4 [ehci_hcd] [cd5372f0] [d027b7f0] .ehci_setup+0x1f4/0x554 [ehci_hcd] [cd537380] [d027bb7c] .ps3_ehci_hc_reset+0x2c/0x6c [ehci_hcd] [cd537400] [d0216740] .usb_add_hcd+0x31c/0x82c [usbcore] [cd5374d0] [d027b1dc] .ps3_ehci_probe+0x124/0x1d8 [ehci_hcd] [cd537570] [c005b350] .ps3_system_bus_probe+0x64/0x80 [cd5375e0] [c033fa7c] .driver_probe_device+0x298/0x384 [cd537680] [c033fc14] .__driver_attach+0xac/0xf4 [cd537710] [c033d7c8] .bus_for_each_dev+0x84/0xb0 [cd5377b0] [c033f394] .driver_attach+0x24/0x38 [cd537820] [c033edb4] .bus_add_driver+0x1e4/0x224 [cd5378c0] [c0340580] .driver_register+0xe0/0x124 [cd537940] [c005ba48] .ps3_system_bus_driver_register+0x20/0x34 [cd5379b0] [d027ecb4] .ehci_hcd_init+0x8c/0xbc [ehci_hcd] [cd537a30] [c000beb0] .do_one_initcall+0xac/0x1c0 [cd537b00] [c00e06ec] .do_init_module+0x6c/0x1fc [cd537ba0] [c00dfd18] .load_module+0x1fbc/0x2164 [cd537d20] [c00e0048] .__se_sys_finit_module+0x94/0xa4 [cd537e30] [c000a2a4] system_call+0x5c/0x70 Instruction dump: e89e0038 3920 2fa3 419e0008 e92301f8 7d2a0074 794ad182 0b0a 419e0014 e9430208 2faa 409e0008 <0fe0> e929 57a6045e 2fa9 ---[ end trace 9066c3fd23e9bf8f ]--- WARNING: CPU: 0 PID: 382 at ./include/linux/dma-mapping.h:516 .ehci_setup+0x294/0x554 [ehci_hcd] Modules linked in: ehci_hcd(+) usbcore usb_common CPU: 0 PID: 382 Comm: modprobe Tainted: GW 4.18.0-rc3-00022-g06ddb9e4cfce #52 NIP: d027b890 LR: d027b844 CTR: c018f058 REGS: cd537070 TRAP: 0700 Tainted: GW (4.18.0-rc3-00022-g06ddb9e4cfce) MSR: 80028032 CR: 28024242 XER: IRQMASK: 0 GPR00: d027b844 cd5372f0 d0288a00 cd52a858 GPR04: 0800 cd3b8bc0 cd32e480 GPR08: c04d5b00 d027f000 GPR12: c018f058 c0b0b000 c0636bd0 GPR16: c0680ab0 0100 c0a11848 GPR20: 006000c0 c04d8210 cd572400 d0281850 GPR24: d02379b0 0031 d0237b00 d0237b30 GPR28: d0281b80 cd3b8a70 0016 cd3b8800 NIP [d027b890] .ehci_setup+0x294/0x554 [ehci_hcd] LR [d027b844] .ehci_setup+0x248/0x554 [ehci_hcd] Call Trace: [cd5
