linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	iommu@lists.linux-foundation.org
Cc: linuxarm@huawei.com, lorenzo.pieralisi@arm.com, joro@8bytes.org,
	robin.murphy@arm.com, wanghuiqiang@huawei.com,
	guohanjun@huawei.com, Sami.Mujawar@arm.com, jon@solid-run.com,
	eric.auger@redhat.com, yangyicong@huawei.com
Subject: Re: [PATCH v5 0/8] ACPI/IORT: Support for IORT RMR node
Date: Mon, 24 May 2021 16:18:51 +0100	[thread overview]
Message-ID: <2372ccf7-0a13-304c-be24-6429d0981b3d@arm.com> (raw)
In-Reply-To: <20210524110222.2212-1-shameerali.kolothum.thodi@huawei.com>

On 24/05/2021 12:02, Shameer Kolothum wrote:
> Hi,
> 
> v4 --> v5
>  -Added a fw_data union to struct iommu_resv_region and removed
>   struct iommu_rmr (Based on comments from Joerg/Robin).
>  -Added iommu_put_rmrs() to release mem.
>  -Thanks to Steve for verifying v4 on SMMUv2, but not added the
>   Tested-by yet because of the above changes.

I've retested with this series (Juno with SMMU in front of display
controller and EFI framebuffer), and it still works, so:

Tested-by: Steven Price <steven.price@arm.com>

Thanks,

Steve

> 
> v3 -->v4
> -Included the SMMUv2 SMR bypass install changes suggested by
>  Steve(patch #7)
> -As per Robin's comments, RMR reserve implementation is now
>  more generic  (patch #8) and dropped v3 patches 8 and 10.
> -Rebase to 5.13-rc1 
> 
> RFC v2 --> v3
>  -Dropped RFC tag as the ACPICA header changes are now ready to be
>   part of 5.13[0]. But this series still has a dependency on that patch.
>  -Added IORT E.b related changes(node flags, _DSM function 5 checks for
>   PCIe).
>  -Changed RMR to stream id mapping from M:N to M:1 as per the spec and
>   discussion here[1].
>  -Last two patches add support for SMMUv2(Thanks to Jon Nettleton!) 
> 
> Sanity tested on a HiSilicon D06. Further testing and feedback is greatly
> appreciated.
> 
> The whole series can be found here,
> https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc8-rmr-v3
> 
> Thanks,
> Shameer
> 
> [0] https://lore.kernel.org/linux-acpi/20210406213028.718796-22-erik.kaneda@intel.com/
> [1] https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html
> 
> 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 SMMUv3 reset. This is
>    based on the suggestions received for v1 to take care of the
>    EFI framebuffer use case. Only sanity tested for now.
>  - During the probe/attach device, SMMUv3 driver reserves any
>    RMR region associated with the device such that there is a unity
>    mapping for them in SMMU.
> ---    
> 
> From RFC v1:
> -------------
> The series adds support to IORT RMR nodes specified in IORT
> Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
> ranges that are used by endpoints and require a unity mapping
> in SMMU.
> 
> We have faced issues with 3408iMR RAID controller cards which
> fail to boot when SMMU is enabled. This is because these controllers
> make use of host memory for various caching related purposes and when
> SMMU is enabled the iMR firmware fails to access these memory regions
> as there is no mapping for them. IORT RMR provides a way for UEFI to
> describe and report these memory regions so that the kernel can make
> a unity mapping for these in SMMU.
> 
> Tests:
> 
> With a UEFI, that reports the RMR for the dev,
> ....
> [16F0h 5872   1]                         Type : 06
> [16F1h 5873   2]                       Length : 007C
> [16F3h 5875   1]                     Revision : 00
> [1038h 0056   2]                     Reserved : 00000000
> [1038h 0056   2]                   Identifier : 00000000
> [16F8h 5880   4]                Mapping Count : 00000001
> [16FCh 5884   4]               Mapping Offset : 00000040
> 
> [1700h 5888   4]    Number of RMR Descriptors : 00000002
> [1704h 5892   4]        RMR Descriptor Offset : 00000018
> 
> [1708h 5896   8]          Base Address of RMR : 0000E6400000
> [1710h 5904   8]                Length of RMR : 000000100000
> [1718h 5912   4]                     Reserved : 00000000
> 
> [171Ch 5916   8]          Base Address of RMR : 0000000027B00000
> [1724h 5924   8]                Length of RMR : 0000000000C00000
> [172Ch 5932   4]                     Reserved : 00000000
> 
> [1730h 5936   4]                   Input base : 00000000
> [1734h 5940   4]                     ID Count : 00000001
> [1738h 5944   4]                  Output Base : 00000003
> [173Ch 5948   4]             Output Reference : 00000064
> [1740h 5952   4]        Flags (decoded below) : 00000001
>                                Single Mapping : 1
> ...
> 
> Without the series the RAID controller initialization fails as
> below,
> 
> ...
> [   12.631117] megaraid_sas 0000:03:00.0: FW supports sync cache        : Yes   
> [   12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
> [   18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED for SCSI host 0                                                                         
> [   23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state 
> [  106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault code:0x10000 subcode:0x0 func:megasas_transition_to_ready                                    
> [  106.695186] megaraid_sas 0000:03:00.0: System Register set:                  
> [  106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to ready for scsi0.                                                                   
> [  106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw 6407      
> estuary:/$
> 
> With the series, now the kernel has direct mapping for the dev as
> below,
> 
> estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions                      
> 0x0000000008000000 0x00000000080fffff msi                                       
> 0x0000000027b00000 0x00000000286fffff direct                                    
> 0x00000000e6400000 0x00000000e64fffff direct                                    
> estuary:/$
> 
> ....
> [   12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
> [   12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs: 0      max_lds: 32                                                                      
> [   12.746628] megaraid_sas 0000:03:00.0: controller type       : iMR(0MB)      
> [   12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR)  : Enabled                                                                               
> [   12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support   : Yes           
> [   12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes           
> [   12.771931] megaraid_sas 0000:03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs                                                                 
> [   12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map support     : Yes   
> [   12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining support    : No    
> [   12.819179] megaraid_sas 0000:03:00.0: NVME page size        : (4096)        
> [   12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000                                                    
> [   12.835199] megaraid_sas 0000:03:00.0: INIT adapter done                     
> [   12.873932] megaraid_sas 0000:03:00.0: pci id                : (0x1000)/(0x0017)/(0x19e5)/(0xd213)                                                           
> [   12.881644] megaraid_sas 0000:03:00.0: unevenspan support    : no            
> [   12.887451] megaraid_sas 0000:03:00.0: firmware crash dump   : no            
> [   12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map     : enabled       
> 
> RAID controller init is now success and can detect the drives
> attached as well.
> 
> Jon Nettleton (1):
>   iommu/arm-smmu: Get associated RMR info and install bypass SMR
> 
> Shameer Kolothum (7):
>   ACPI/IORT: Add support for RMR node parsing
>   iommu/dma: Introduce generic helper to retrieve RMR info
>   ACPI/IORT: Add a helper to retrieve RMR memory regions
>   iommu/arm-smmu-v3: Introduce strtab init helper
>   iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent()
>   iommu/arm-smmu-v3: Get associated RMR info and install
>   iommu/dma: Reserve any RMR regions associated with a dev
> 
>  drivers/acpi/arm64/iort.c                   | 154 +++++++++++++++++++-
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  72 ++++++---
>  drivers/iommu/arm/arm-smmu/arm-smmu.c       |  65 +++++++++
>  drivers/iommu/dma-iommu.c                   |  89 ++++++++++-
>  include/linux/acpi_iort.h                   |   7 +
>  include/linux/dma-iommu.h                   |  13 ++
>  include/linux/iommu.h                       |  10 ++
>  7 files changed, 387 insertions(+), 23 deletions(-)
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      parent reply	other threads:[~2021-05-24 19:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 11:02 [PATCH v5 0/8] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2021-05-24 11:02 ` [PATCH v5 1/8] ACPI/IORT: Add support for RMR node parsing Shameer Kolothum
2021-06-14 11:14   ` Robin Murphy
2021-06-14 12:37     ` Shameerali Kolothum Thodi
2021-05-24 11:02 ` [PATCH v5 2/8] iommu/dma: Introduce generic helper to retrieve RMR info Shameer Kolothum
2021-05-24 15:35   ` kernel test robot
2021-05-24 11:02 ` [PATCH v5 3/8] ACPI/IORT: Add a helper to retrieve RMR memory regions Shameer Kolothum
2021-05-26  7:53   ` Laurentiu Tudor
2021-05-26 16:36     ` Shameerali Kolothum Thodi
2021-05-26 17:11       ` Laurentiu Tudor
2021-06-03 12:27         ` Jon Nettleton
2021-06-03 12:32           ` Laurentiu Tudor
2021-05-27  4:25       ` Jon Nettleton
2021-06-14 10:35       ` Robin Murphy
2021-06-14 11:23   ` Robin Murphy
2021-06-14 12:49     ` Shameerali Kolothum Thodi
2021-06-29 17:34       ` Jon Nettleton
2021-07-04  7:38         ` Jon Nettleton
2021-07-05  9:10           ` Shameerali Kolothum Thodi
2021-05-24 11:02 ` [PATCH v5 4/8] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2021-05-24 11:02 ` [PATCH v5 5/8] iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent() Shameer Kolothum
2021-06-14 10:23   ` Robin Murphy
2021-06-14 12:51     ` Shameerali Kolothum Thodi
2021-05-24 11:02 ` [PATCH v5 6/8] iommu/arm-smmu-v3: Get associated RMR info and install Shameer Kolothum
2021-06-14 10:15   ` Robin Murphy
2021-05-24 11:02 ` [PATCH v5 7/8] iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum
2021-06-03  8:52   ` Jon Nettleton
2021-06-03 11:27     ` Steven Price
2021-06-03 11:51       ` Jon Nettleton
2021-06-13  7:40         ` Jon Nettleton
2021-06-14  9:23           ` Robin Murphy
2021-06-14 10:06   ` Robin Murphy
2021-06-14 16:51     ` Shameerali Kolothum Thodi
2021-06-15  8:02       ` Jon Nettleton
2021-06-29  7:03     ` Jon Nettleton
2021-06-29 13:22       ` Robin Murphy
2021-06-29 16:25         ` Jon Nettleton
2021-06-30  8:50           ` Shameerali Kolothum Thodi
2021-05-24 11:02 ` [PATCH v5 8/8] iommu/dma: Reserve any RMR regions associated with a dev Shameer Kolothum
2021-05-24 15:18 ` Steven Price [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2372ccf7-0a13-304c-be24-6429d0981b3d@arm.com \
    --to=steven.price@arm.com \
    --cc=Sami.Mujawar@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jon@solid-run.com \
    --cc=joro@8bytes.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=yangyicong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).