Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu

2020-07-21 Thread Lu Baolu
On 7/22/20 11:03 AM, Jun Miao wrote: On 7/22/20 10:40 AM, Lu Baolu wrote: Hi Jun, On 7/22/20 10:26 AM, Miao, Jun wrote: Kernel panic - not syncing: DMAR hardware is malfunctioning CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124 Hardware name: Intel Corporation Ice Lake

[PATCH 1/1] iommu/vt-d: Rename intel-pasid.h to pasid.h

2020-07-21 Thread Lu Baolu
As Intel VT-d files have been move to its own subdirectory, the prefix makes no sense. Signed-off-by: Lu Baolu --- drivers/iommu/intel/debugfs.c | 2 +- drivers/iommu/intel/iommu.c| 2 +- drivers/iommu/intel/pasid.c| 2 +-

Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu

2020-07-21 Thread Lu Baolu
Hi Jun, On 7/22/20 10:26 AM, Miao, Jun wrote: Kernel panic - not syncing: DMAR hardware is malfunctioning CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS

Re: [PATCH v4 4/7] iommu/vt-d: Handle non-page aligned address

2020-07-21 Thread Lu Baolu
Hi Jacob, On 7/22/20 12:50 AM, Jacob Pan wrote: Hi Baolu, Not sure what state is this patch in, there is a bug in this patch (see below), shall I send out an updated version of this one only? or another incremental patch. Please send an updated version. I hope Joerg could pick these as 5.8

Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init

2020-07-21 Thread Bjorn Andersson
On Tue 21 Jul 09:20 PDT 2020, Konrad Dybcio wrote: > >The current > >focus has been on moving more of the SMMU specific bits into the > >arm-smmu-qcom > >implementation [1] and I think that is the right way to go. > > Pardon if I overlooked something obvious, but I can't seem to find a > clean

RE: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu

2020-07-21 Thread Limonciello, Mario
> -Original Message- > From: Lu Baolu > Sent: Tuesday, July 21, 2020 6:07 PM > To: Limonciello, Mario; Joerg Roedel > Cc: baolu...@linux.intel.com; Ashok Raj; linux-ker...@vger.kernel.org; > sta...@vger.kernel.org; Koba Ko; iommu@lists.linux-foundation.org > Subject: Re: [PATCH 1/1]

Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu

2020-07-21 Thread Lu Baolu
Hi Limonciello, On 7/21/20 10:44 PM, Limonciello, Mario wrote: -Original Message- From: iommu On Behalf Of Lu Baolu Sent: Monday, July 20, 2020 7:17 PM To: Joerg Roedel Cc: Ashok Raj;linux-ker...@vger.kernel.org;sta...@vger.kernel.org; Koba Ko;iommu@lists.linux-foundation.org Subject:

Re: [PATCH v5 4/5] iommu/uapi: Handle data and argsz filled by users

2020-07-21 Thread Jacob Pan
On Fri, 17 Jul 2020 13:59:54 -0600 Alex Williamson wrote: > 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

Re: [PATCH v5 4/5] iommu/uapi: Handle data and argsz filled by users

2020-07-21 Thread Jacob Pan
On Fri, 17 Jul 2020 17:58:04 +0200 Auger Eric wrote: > Hi Jacob, > On 7/16/20 8:45 PM, Jacob Pan wrote: > > Could you share a branch? I was not able to apply this on either > iommu/next or master? > Will push it to github for the next version. This set is based on v5.8-rc1 and my fixes for

Re: [PATCH v2] iommu/mediatek: check 4GB mode by reading infracfg

2020-07-21 Thread Matthias Brugger
On 21/07/2020 13:24, Yong Wu wrote: On Tue, 2020-07-21 at 11:40 +0200, Matthias Brugger wrote: On 21/07/2020 04:16, Miles Chen wrote: In previous discussion [1] and [2], we found that it is risky to use max_pfn or totalram_pages to tell if 4GB mode is enabled. Check 4GB mode by reading

[PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

2020-07-21 Thread Ashok Raj
PASID and PRI capabilities are only enumerated in PF devices. VF devices do not enumerate these capabilites. IOMMU drivers also need to enumerate them before enabling features in the IOMMU. Extending the same support as PASID feature discovery (pci_pasid_features) for PRI. Signed-off-by: Ashok

[PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

2020-07-21 Thread Ashok Raj
PASID and PRI capabilities are only enumerated in PF devices. VF devices do not enumerate these capabilites. IOMMU drivers also need to enumerate them before enabling features in the IOMMU. Extending the same support as PASID feature discovery (pci_pasid_features) for PRI. Signed-off-by: Ashok

Re: [PATCH v4 4/7] iommu/vt-d: Handle non-page aligned address

2020-07-21 Thread Jacob Pan
Hi Baolu, Not sure what state is this patch in, there is a bug in this patch (see below), shall I send out an updated version of this one only? or another incremental patch. Thanks, Jacob On Mon, 6 Jul 2020 17:12:51 -0700 Jacob Pan wrote: > From: Liu Yi L > > Address information for

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Nicolas Saenz Julienne
On Tue, 2020-07-21 at 20:52 +0530, Amit Pundir wrote: [...] > > > > Can you try booting *without* my patch and this in the kernel > > > > command > > > > line: "cma=16M@0x1-0x2". > > > > > > It doesn't boot with this added kernel command line. > > > > For the record, this

Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init

2020-07-21 Thread Konrad Dybcio
>The current >focus has been on moving more of the SMMU specific bits into the arm-smmu-qcom >implementation [1] and I think that is the right way to go. Pardon if I overlooked something obvious, but I can't seem to find a clean way for implementing qcom,skip-init in arm-smmu-qcom, as neither the

Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init

2020-07-21 Thread Jordan Crouse
On Tue, Jul 21, 2020 at 05:04:11PM +0200, Konrad Dybcio wrote: > So.. is this a no-no? > > I of course would like to omit this entirely, but SMMUs on sdm630 and > friends are REALLY picky.. What seems to happen is that when the > driver tries to do things the "standard" way, hypervisor decides to

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Amit Pundir
On Tue, 21 Jul 2020 at 18:15, Nicolas Saenz Julienne wrote: > > On Tue, 2020-07-21 at 17:45 +0530, Amit Pundir wrote: > > On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne > > wrote: > > > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote: > > > > On Tue, 21 Jul 2020 at 14:09, Nicolas

RE: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu

2020-07-21 Thread Limonciello, Mario
> -Original Message- > From: iommu On Behalf Of Lu > Baolu > Sent: Monday, July 20, 2020 7:17 PM > To: Joerg Roedel > Cc: Ashok Raj; linux-ker...@vger.kernel.org; sta...@vger.kernel.org; Koba > Ko; iommu@lists.linux-foundation.org > Subject: [PATCH 1/1] iommu/vt-d: Skip TE disabling on

Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init

2020-07-21 Thread Konrad Dybcio
So.. is this a no-no? I of course would like to omit this entirely, but SMMUs on sdm630 and friends are REALLY picky.. What seems to happen is that when the driver tries to do things the "standard" way, hypervisor decides to hang the platform or force a reboot. Not very usable. This thing is

Re: [PATCH v2 03/12] ACPI/IORT: Make iort_msi_map_rid() PCI agnostic

2020-07-21 Thread Bjorn Helgaas
On Fri, Jun 19, 2020 at 09:20:04AM +0100, Lorenzo Pieralisi wrote: > There is nothing PCI specific in iort_msi_map_rid(). > > Rename the function using a bus protocol agnostic name, > iort_msi_map_id(), and convert current callers to it. > > Signed-off-by: Lorenzo Pieralisi > Cc: Will Deacon >

Re: [PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

2020-07-21 Thread Bjorn Helgaas
On Mon, Jul 20, 2020 at 09:43:00AM -0700, Ashok Raj wrote: > PASID and PRI capabilities are only enumerated in PF devices. VF devices > do not enumerate these capabilites. IOMMU drivers also need to enumerate > them before enabling features in the IOMMU. Extending the same support as > PASID

Re: [PATCH v8 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-21 Thread Christoph Hellwig
On Wed, Jul 15, 2020 at 10:35:11AM -0400, Jim Quinlan wrote: > 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

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Nicolas Saenz Julienne
On Tue, 2020-07-21 at 17:45 +0530, Amit Pundir wrote: > On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne > wrote: > > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote: > > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne > > > wrote: > > > > Hi Amit, > > > > > Hi Nicolas, > > > > >

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Amit Pundir
On Tue, 21 Jul 2020 at 17:07, Nicolas Saenz Julienne wrote: > > On Tue, 2020-07-21 at 13:28 +0200, Christoph Hellwig wrote: > > On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne > > wrote: > > > I'm at loss at what could be failing here. Your device should be > > > able > > > to

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Amit Pundir
On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne wrote: > > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote: > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne > > wrote: > > > Hi Amit, > > > > Hi Nicolas, > > > > > > > > I see a boot regression with this commit d9765e41d8e9

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Nicolas Saenz Julienne
On Tue, 2020-07-21 at 13:28 +0200, Christoph Hellwig wrote: > On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne > wrote: > > I'm at loss at what could be failing here. Your device should be > > able > > to address the whole 8GB memory space, which AFAIK is the max > > available > >

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Christoph Hellwig
On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne wrote: > I'm at loss at what could be failing here. Your device should be able > to address the whole 8GB memory space, which AFAIK is the max available > on that smartphone family. But maybe the device-tree is lying, who > knows...

Re: [PATCH v2] iommu/mediatek: check 4GB mode by reading infracfg

2020-07-21 Thread Yong Wu
On Tue, 2020-07-21 at 11:40 +0200, Matthias Brugger wrote: > > On 21/07/2020 04:16, Miles Chen wrote: > > In previous discussion [1] and [2], we found that it is risky to > > use max_pfn or totalram_pages to tell if 4GB mode is enabled. > > > > Check 4GB mode by reading infracfg register, remove

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Nicolas Saenz Julienne
On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote: > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne > wrote: > > Hi Amit, > > > Hi Nicolas, > > > > > > I see a boot regression with this commit d9765e41d8e9 "dma-pool: > > > Do not allocate pool memory from CMA" on my Xiaomi Poco F1 > > >

Re: [PATCH v2] iommu/mediatek: check 4GB mode by reading infracfg

2020-07-21 Thread Matthias Brugger
On 21/07/2020 04:16, Miles Chen wrote: In previous discussion [1] and [2], we found that it is risky to use max_pfn or totalram_pages to tell if 4GB mode is enabled. Check 4GB mode by reading infracfg register, remove the usage of the un-exported symbol max_pfn. This is a step towards

Re: [PATCH v2] iommu/mediatek: check 4GB mode by reading infracfg

2020-07-21 Thread David Hildenbrand
On 21.07.20 04:16, Miles Chen wrote: > In previous discussion [1] and [2], we found that it is risky to > use max_pfn or totalram_pages to tell if 4GB mode is enabled. > > Check 4GB mode by reading infracfg register, remove the usage > of the un-exported symbol max_pfn. > > This is a step

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Amit Pundir
On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne wrote: > > Hi Amit, > > On Tue, 2020-07-21 at 12:51 +0530, Amit Pundir wrote: > > On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne > > wrote: > > > There is no guarantee to CMA's placement, so allocating a zone > > > specific > > > atomic

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Nicolas Saenz Julienne
Hi Amit, On Tue, 2020-07-21 at 12:51 +0530, Amit Pundir wrote: > On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne > wrote: > > There is no guarantee to CMA's placement, so allocating a zone > > specific > > atomic pool from CMA might return memory from a completely > > different > > memory

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

2020-07-21 Thread Amit Pundir
On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne wrote: > > There is no guarantee to CMA's placement, so allocating a zone specific > atomic pool from CMA might return memory from a completely different > memory zone. So stop using it. > > Fixes: c84dc6e68a1d ("dma-pool: add additional

[GIT PULL] iommu/arm-smmu: Updates for 5.9

2020-07-21 Thread Will Deacon
Hi Joerg, Please pull these Arm SMMU driver updates for 5.9. Summary is in the tag, but the main thing is support for two new SoC integrations, one of which is considerably more brain-dead than the other (determining which one is left as an exercise to the reader although the diffstat is fairly