Re: [PATCH] Revert "firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module"

2020-11-19 Thread Bjorn Andersson
On Thu, Nov 19, 2020 at 11:42 AM Thierry Reding wrote: > > From: Thierry Reding > > Commit d0511b5496c0 ("firmware: QCOM_SCM: Allow qcom_scm driver to be > loadable as a permenent module") causes the ARM SMMU driver to be built > as a loadable module when using the Aarch64 default configuration.

Re: [PATCH v2] iommu/amd: Enforce 4k mapping for certain IOMMU data structures

2020-11-19 Thread Brijesh Singh
On 11/19/20 8:30 PM, Suravee Suthikulpanit wrote: > Will, > > To answer your questions from v1 thread. > > On 11/18/20 5:57 AM, Will Deacon wrote: > > On 11/5/20 9:58 PM, Suravee Suthikulpanit wrote: > >> AMD IOMMU requires 4k-aligned pages for the event log, the PPR log, > >> and the completion

Re: [PATCH v2] iommu/amd: Enforce 4k mapping for certain IOMMU data structures

2020-11-19 Thread Suravee Suthikulpanit
Will, To answer your questions from v1 thread. On 11/18/20 5:57 AM, Will Deacon wrote: > On 11/5/20 9:58 PM, Suravee Suthikulpanit wrote: >> AMD IOMMU requires 4k-aligned pages for the event log, the PPR log, >> and the completion wait write-back regions. However, when allocating >> the pages,

Re: [Patch V8 3/3] iommu: Document usage of "/sys/kernel/iommu_groups//type" file

2020-11-19 Thread Lu Baolu
Hi Will On 11/19/20 4:55 PM, Will Deacon wrote: Hi Lu, On Thu, Nov 19, 2020 at 10:32:43AM +0800, Lu Baolu wrote: On 11/18/20 9:51 PM, Will Deacon wrote: On Fri, Sep 25, 2020 at 12:06:20PM -0700, Ashok Raj wrote: I can't figure out from this description what string is returned to userspace in

Re: [Patch V8 1/3] iommu: Add support to change default domain of an iommu group

2020-11-19 Thread Lu Baolu
Hi Will, On 11/19/20 4:53 PM, Will Deacon wrote: On Thu, Nov 19, 2020 at 10:18:05AM +0800, Lu Baolu wrote: The original author of this patch series has left Intel. I am now the backup. Ok, thanks for letting me know. On 11/18/20 9:51 PM, Will Deacon wrote: On Fri, Sep 25, 2020 at

[PATCH v6] swiotlb: Adjust SWIOTBL bounce buffer size for SEV guests.

2020-11-19 Thread Ashish Kalra
From: Ashish Kalra For SEV, all DMA to and from guest has to use shared (un-encrypted) pages. SEV uses SWIOTLB to make this happen without requiring changes to device drivers. However, depending on workload being run, the default 64MB of SWIOTLB might not be enough and SWIOTLB may run out of

Re: [PATCH] Revert "firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module"

2020-11-19 Thread John Stultz
On Thu, Nov 19, 2020 at 9:41 AM Thierry Reding wrote: > > From: Thierry Reding > > Commit d0511b5496c0 ("firmware: QCOM_SCM: Allow qcom_scm driver to be > loadable as a permenent module") causes the ARM SMMU driver to be built > as a loadable module when using the Aarch64 default configuration.

Re: [PATCH] Revert "firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module"

2020-11-19 Thread Will Deacon
On Thu, Nov 19, 2020 at 06:41:49PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Commit d0511b5496c0 ("firmware: QCOM_SCM: Allow qcom_scm driver to be > loadable as a permenent module") causes the ARM SMMU driver to be built > as a loadable module when using the Aarch64 default

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-19 Thread James Morse
Hi, (sorry for the late response) On 06/11/2020 18:46, Nicolas Saenz Julienne wrote: > On Thu, 2020-11-05 at 16:11 +, James Morse wrote:>> We also depend on > this when skipping the checksum code in purgatory, which can be >> exceedingly slow. > > This one I don't fully understand, so I'll

[PATCH v7 3/7] of/address: Introduce of_dma_get_max_cpu_address()

2020-11-19 Thread Nicolas Saenz Julienne
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU physical address addressable by all DMA masters in the system. It's specially useful for setting memory zones sizes at early boot time. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Rob Herring --- Changes since v4:

[PATCH v7 7/7] mm: Remove examples from enum zone_type comment

2020-11-19 Thread Nicolas Saenz Julienne
We can't really list every setup in common code. On top of that they are unlikely to stay true for long as things change in the arch trees independently of this comment. Suggested-by: Christoph Hellwig Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Christoph Hellwig ---

[PATCH v7 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

2020-11-19 Thread Nicolas Saenz Julienne
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that can only address up to 1 GB (and its PCIe host bridge can only access the

[PATCH v7 4/7] of: unittest: Add test for of_dma_get_max_cpu_address()

2020-11-19 Thread Nicolas Saenz Julienne
Introduce a test for of_dma_get_max_cup_address(), it uses the same DT data as the rest of dma-ranges unit tests. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Rob Herring --- Changes since v5: - Update address expected by test Changes since v3: - Remove HAS_DMA guards

[PATCH v7 6/7] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-11-19 Thread Nicolas Saenz Julienne
From: Ard Biesheuvel We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that can only address up to 1 GB (and its PCIe host bridge

[PATCH v7 0/7] arm64: Default to 32-bit wide ZONE_DMA

2020-11-19 Thread Nicolas Saenz Julienne
Using two distinct DMA zones turned out to be problematic. Here's an attempt go back to a saner default. I tested this on both a RPi4 and QEMU. --- Changes since v6: - Update patch #1 so we reserve crashkernel before request_standard_resources() - Tested on top of Catalin's mem_init()

[PATCH v7 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-19 Thread Nicolas Saenz Julienne
crashkernel might reserve memory located in ZONE_DMA. We plan to delay ZONE_DMA's initialization after unflattening the devicetree and ACPI's boot table initialization, so move it later in the boot process. Specifically into bootmem_init() since request_standard_resources() depends on it.

[PATCH v7 2/7] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()

2020-11-19 Thread Nicolas Saenz Julienne
zone_dma_bits's initialization happens earlier that it's actually needed, in arm64_memblock_init(). So move it into the more suitable zone_sizes_init(). Signed-off-by: Nicolas Saenz Julienne Tested-by: Jeremy Linton --- arch/arm64/mm/init.c | 7 ++- 1 file changed, 2 insertions(+), 5

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-19 Thread Catalin Marinas
On Thu, Nov 19, 2020 at 06:25:29PM +0100, Nicolas Saenz Julienne wrote: > On Thu, 2020-11-19 at 17:10 +, Catalin Marinas wrote: > > On Thu, Nov 19, 2020 at 03:09:58PM +0100, Nicolas Saenz Julienne wrote: > > > On Fri, 2020-11-13 at 11:29 +, Catalin Marinas wrote: > > > [...] > > > > > > >

[PATCH] Revert "firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module"

2020-11-19 Thread Thierry Reding
From: Thierry Reding Commit d0511b5496c0 ("firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module") causes the ARM SMMU driver to be built as a loadable module when using the Aarch64 default configuration. This in turn causes problems because if the loadable module is not

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-19 Thread Nicolas Saenz Julienne
On Thu, 2020-11-19 at 17:10 +, Catalin Marinas wrote: > On Thu, Nov 19, 2020 at 03:09:58PM +0100, Nicolas Saenz Julienne wrote: > > On Fri, 2020-11-13 at 11:29 +, Catalin Marinas wrote: > > [...] > > > > > > Let me stress that knowing the DMA constraints in the system before > > > > > >

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-19 Thread Catalin Marinas
On Thu, Nov 19, 2020 at 05:10:49PM +, Catalin Marinas wrote: > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index ed71b1c305d7..acdec0c67d3b 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -469,6 +469,21 @@ void __init mark_linear_text_alias_ro(void) >

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-19 Thread Catalin Marinas
On Thu, Nov 19, 2020 at 03:09:58PM +0100, Nicolas Saenz Julienne wrote: > On Fri, 2020-11-13 at 11:29 +, Catalin Marinas wrote: > [...] > > > > > Let me stress that knowing the DMA constraints in the system before > > > > > reserving > > > > > crashkernel's regions is necessary if we ever

Re: [PATCH v13 01/15] iommu: Introduce attach/detach_pasid_table API

2020-11-19 Thread Auger Eric
Hi Jacob, On 11/18/20 5:19 PM, Jacob Pan wrote: > Hi Eric, > > On Wed, 18 Nov 2020 12:21:37 +0100, Eric Auger > wrote: > >> In virtualization use case, when a guest is assigned >> a PCI host device, protected by a virtual IOMMU on the guest, >> the physical IOMMU must be programmed to be

[PATCH] iommu: Check return of __iommu_attach_device()

2020-11-19 Thread Shameer Kolothum
Currently iommu_create_device_direct_mappings() is called without checking the return of __iommu_attach_device(). This may result in failures in iommu driver if dev attach returns error. Fixes: ce574c27ae27("iommu: Move iommu_group_create_direct_mappings() out of iommu_group_add_device()")

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-11-19 Thread Nicolas Saenz Julienne
Hi Catalin, James, sorry for the late reply but I got sidetracked. On Fri, 2020-11-13 at 11:29 +, Catalin Marinas wrote: [...] > > > > Let me stress that knowing the DMA constraints in the system before > > > > reserving > > > > crashkernel's regions is necessary if we ever want it to work

[RFC PATCH v2 8/8] iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev

2020-11-19 Thread Shameer Kolothum
Get RMR regions associated with a dev reserved so that there is a unity mapping for them in SMMU. Signed-off-by: Shameer Kolothum --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 38 + 1 file changed, 38 insertions(+) diff --git

[RFC PATCH v2 6/8] iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent()

2020-11-19 Thread Shameer Kolothum
By default, disable_bypass is set and any dev without an iommu domain installs STE with CFG_ABORT during arm_smmu_init_bypass_stes(). Introduce a "bypass" flag to arm_smmu_write_strtab_ent() so that we can force it to install CFG_BYPASS STE for specific SIDs. This will be useful for RMR related

[RFC PATCH v2 7/8] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE

2020-11-19 Thread Shameer Kolothum
Check if there is any RMR info associated with the devices behind the SMMUv3 and if any, install bypass STEs for them. This is to keep any ongoing traffic associated with these devices alive when we enable/reset SMMUv3 during probe(). Signed-off-by: Shameer Kolothum ---

[RFC PATCH v2 5/8] iommu/arm-smmu-v3: Introduce strtab init helper

2020-11-19 Thread Shameer Kolothum
Introduce a helper to check the sid range and to init the l2 strtab entries(bypass). This will be useful when we have to initialize the l2 strtab for RMR SIDs. Signed-off-by: Shameer Kolothum --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 26 - 1 file changed, 15

[RFC PATCH v2 3/8] iommu/dma: Introduce generic helper to retrieve RMR info

2020-11-19 Thread Shameer Kolothum
Reserved Memory Regions(RMR) associated with an IOMMU may be described either through ACPI tables or DT in systems with devices that require a unity mapping or bypass for those regions in IOMMU drivers. Introduce a generic interface so that IOMMU drivers can retrieve and set up necessary

[RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing

2020-11-19 Thread Shameer Kolothum
Add support for parsing RMR node information from ACPI. Find associated stream ids and smmu node info from the RMR node and populate a linked list with RMR memory descriptors. Signed-off-by: Shameer Kolothum --- drivers/acpi/arm64/iort.c | 122 +- 1 file

[RFC PATCH v2 4/8] ACPI/IORT: Add RMR memory regions reservation helper

2020-11-19 Thread Shameer Kolothum
Add a helper function that retrieves RMR memory descriptors associated with a given IOMMU. This will be used by IOMMU drivers to setup necessary mappings. Now that we have this, invoke this from the generic helper interface. Signed-off-by: Shameer Kolothum --- drivers/acpi/arm64/iort.c | 60

[RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node

2020-11-19 Thread Shameer Kolothum
RFC v1 --> v2:  - Added a generic interface for IOMMU drivers to retrieve all the    RMR info associated with a given IOMMU.  - SMMUv3 driver gets the RMR list during probe() and installs    bypass STEs for all the SIDs in the RMR list. This is to keep   the ongoing traffic alive(if any) during

[RFC PATCH v2 1/8] ACPICA: IORT: Update for revision E

2020-11-19 Thread Shameer Kolothum
IORT revision E contains a few additions like,     -Added an identifier field in the node descriptors to aid table      cross-referencing.     -Introduced the Reserved Memory Range(RMR) node. This is used     to describe memory ranges that are used by endpoints and requires     a unity mapping

RE: [Devel] Re: [RFC PATCH 2/4] ACPI/IORT: Add support for RMR node parsing

2020-11-19 Thread Shameerali Kolothum Thodi
> -Original Message- > From: Sami Mujawar [mailto:sami.muja...@arm.com] > Sent: 09 November 2020 12:30 > To: david.e@linux.intel.com; Shameerali Kolothum Thodi > ; > linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; > iommu@lists.linux-foundation.org;

Re: [PATCH] iommu/amd: Enforce 4k mapping for certain IOMMU data structures

2020-11-19 Thread Suravee Suthikulpanit
Will, I have already submitted v2 of this patch. Let me move the discussion there instead ... (https://lore.kernel.org/linux-iommu/20201105145832.3065-1-suravee.suthikulpa...@amd.com/) Suravee On 11/18/20 5:57 AM, Will Deacon wrote: On Wed, Oct 28, 2020 at 11:18:24PM +, Suravee

Re: [PATCH 1/1] iommu/vt-d: Fix compile error with CONFIG_PCI_ATS not set

2020-11-19 Thread Will Deacon
On Thu, 19 Nov 2020 13:51:19 +0800, Lu Baolu wrote: > Fix the compile error below (CONFIG_PCI_ATS not set): > > drivers/iommu/intel/dmar.c: In function ‘vf_inherit_msi_domain’: > drivers/iommu/intel/dmar.c:338:59: error: ‘struct pci_dev’ has no member > named ‘physfn’; did you mean ‘is_physfn’?

Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-11-19 Thread Will Deacon
On Tue, Nov 17, 2020 at 02:47:54PM +0100, Thierry Reding wrote: > On Mon, Nov 16, 2020 at 11:48:39AM -0800, John Stultz wrote: > > On Mon, Nov 16, 2020 at 8:36 AM Will Deacon wrote: > > > On Mon, Nov 16, 2020 at 04:59:36PM +0100, Thierry Reding wrote: > > > > On Fri, Nov 06, 2020 at 04:27:10AM

Re: [Patch V8 3/3] iommu: Document usage of "/sys/kernel/iommu_groups//type" file

2020-11-19 Thread Will Deacon
Hi Lu, On Thu, Nov 19, 2020 at 10:32:43AM +0800, Lu Baolu wrote: > On 11/18/20 9:51 PM, Will Deacon wrote: > > On Fri, Sep 25, 2020 at 12:06:20PM -0700, Ashok Raj wrote: > > I can't figure out from this description what string is returned to > > userspace in the case that the group is configured

Re: [Patch V8 1/3] iommu: Add support to change default domain of an iommu group

2020-11-19 Thread Will Deacon
On Thu, Nov 19, 2020 at 10:18:05AM +0800, Lu Baolu wrote: > The original author of this patch series has left Intel. I am now the > backup. Ok, thanks for letting me know. > On 11/18/20 9:51 PM, Will Deacon wrote: > > On Fri, Sep 25, 2020 at 12:06:18PM -0700, Ashok Raj wrote: > > > From: Sai