[PATCH v8 0/5] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
by Shameer Kolothum
On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.
The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.
This patch implements an ACPI and DT based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.
To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve the
associated ITS base address from a device IORT node.
2. Added a generic helper function to of iommu code to retrieve the
associated msi controller base address from for a PCI RC
msi-mapping and also platform device msi-parent.
3. Added quirk to SMMUv3 to retrieve the HW ITS address and replace
the default SW MSI reserve address based on the IORT SMMU model
or DT bindings.
Changelog:
v7 --> v8
Addressed comments from Rob and Lorenzo:
-Modified to use DT compatible string for errata.
-Changed logic to retrieve the msi-parent for DT case.
v6 --> v7
Addressed request from Will to add DT support for the erratum:
- added bt binding
- add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions
v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
is not applicable. Provided a generic function in iommu code and added
back the quirk implementation in SMMU v3 driver(patch#3)
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward
HW topologies are handled while reserving ITS regions(patch #1).
v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into
iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).
v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
iort helper function.
v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.
RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead of vendor specific CSRT table.
John Garry (2):
Doc: iommu/arm-smmu-v3: Add workaround for HiSilicon erratum 161010801
iommu/of: Add msi address regions reservation helper
Shameer Kolothum (3):
ACPI/IORT: Add msi address regions reservation helper
iommu/dma: Add a helper function to reserve HW MSI address regions for
IOMMU drivers
iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
Documentation/arm64/silicon-errata.txt | 1 +
.../devicetree/bindings/iommu/arm,smmu-v3.txt | 9 +-
drivers/acpi/arm64/iort.c | 96 +++++++++++++++++++++-
drivers/iommu/arm-smmu-v3.c | 41 +++++++--
drivers/iommu/dma-iommu.c | 19 +++++
drivers/iommu/of_iommu.c | 95 +++++++++++++++++++++
drivers/irqchip/irq-gic-v3-its.c | 3 +-
include/linux/acpi_iort.h | 7 +-
include/linux/dma-iommu.h | 7 ++
include/linux/of_iommu.h | 10 +++
10 files changed, 276 insertions(+), 12 deletions(-)
--
1.9.1
4 years, 9 months
ACPICA version 20170929 released
by Moore, Robert
29 September 2017. Summary of changes for version 20170929:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Redesigned and implemented an improved ASL While() loop timeout mechanism. This mechanism is used to prevent infinite loops in the kernel AML interpreter caused by either non-responsive hardware or incorrect AML code. The new implementation uses AcpiOsGetTimer instead of a simple maximum loop count, and is thus more accurate and constant across different machines. The default timeout is currently 30 seconds, but this may be adjusted later.
Renamed the ACPI_AML_INFINITE_LOOP exception to AE_AML_LOOP_TIMEOUT to better reflect the new implementation of the loop timeout mechanism.
Updated the AcpiGetTimerDuration interface to cleanup the 64-bit support and to fix an off-by-one error. Jung-uk Kim.
Fixed an EFI build problem by updating the makefiles to for a new file that was added, utstrsuppt.c
2) iASL Compiler/Disassembler and Tools:
Implemented full support for the PDTT, SDEV, and TPM2 ACPI tables. This includes support in the table disassembler, compiler, and template generator.
iASL: Added an exception for an illegal type of recursive method invocation. If a method creates named objects, the first recursive call will fail at runtime. This change adds an error detection at compile time to catch the problem up front. Note: Marking such a method as "serialized" will not help with this problem, because the same thread can acquire the method mutex more than once. Example compiler and runtime output:
Method (MTH1)
{
Name (INT1, 1)
MTH1 ()
}
dsdt.asl 22: MTH1 ()
Error 6152 - ^ Illegal recursive call to method
that creates named objects (MTH1)
Previous runtime exception:
ACPI Error: [INT1] Namespace lookup failure,
AE_ALREADY_EXISTS (20170831/dswload2-465)
iASL: Updated support for External() opcodes to improve namespace management and error detection. These changes are related to issues seen with multiple-segment namespace pathnames within External declarations, such as below:
External(\_SB.PCI0.GFX0, DeviceObj)
External(\_SB.PCI0.GFX0.ALSI)
iASL: Implemented support for multi-line error/warning messages. This enables more detailed and helpful error messages as below, from the initial deployment for the duplicate names error:
DSDT.iiii 1692: Device(PEG2) {
Error 6074 - ^ Name already exists in scope (PEG2)
Original name creation/declaration below:
DSDT.iiii 93: External(\_SB.PCI0.PEG2, DeviceObj)
AcpiXtract: Added additional flexibility to support differing input hex dump formats. Specifically, hex dumps that contain partial disassembly and/or comments within the ACPI table data definition. There exist some dump utilities seen in the field that create this type of hex dump (such as Simics). For example:
DSDT @ 0xdfffd0c0 (10999 bytes)
Signature DSDT
Length 10999
Revision 1
Checksum 0xf3 (Ok)
OEM_ID BXPC
OEM_table_id BXDSDT
OEM_revision 1
Creator_id 1280593481
Creator_revision 537399345
0000: 44 53 44 54 f7 2a 00 00 01 f3 42 58 50 43 00 00
...
2af0: 5f 4c 30 46 00 a4 01
Test suite: Miscellaneous changes/fixes:
More cleanup and simplification of makefiles
Continue compilation of test cases after a compile failure
Do not perform binary compare unless both files actually exist
iASL: Performed some code/module restructuring. Moved all memory allocation functions to new modules. Two new files, aslallocate.c and aslcache.c
4 years, 9 months
Re: [Devel] linux-4.14-rc2/drivers/acpi/acpica/utmath.c: 2 * suspicious expression ?
by Zheng, Lv
Hi, David
Not a fancy way, but just a bit clearing.
OK, style is changed here:
https://github.com/acpica/acpica/pull/321
And bug is recorded here:
https://bugs.acpica.org/show_bug.cgi?id=1422
Thanks for the report.
Best regards
Lv
> From: David Binderman [mailto:[email protected]]
> Subject: linux-4.14-rc2/drivers/acpi/acpica/utmath.c: 2 * suspicious expression ?
>
> Hello there,
>
> [linux-4.14-rc2/drivers/acpi/acpica/utmath.c:137] -> [linux-4.14-rc2/drivers/acpi/acpica/utmath.c:137]:
> (style) Same expression on both sides of '^='.
> [linux-4.14-rc2/drivers/acpi/acpica/utmath.c:174] -> [linux-4.14-rc2/drivers/acpi/acpica/utmath.c:174]:
> (style) Same expression on both sides of '^='.
>
> operand_ovl.part.lo ^= operand_ovl.part.lo;
>
> Is this just a fancy way to zero the field or should something more clever
> be happening ?
>
> Regards
>
> David Binderman
>
4 years, 9 months
[PATCH] ASLTS: provide proper PATH for acpibin in tests
by Al Stone
Recent versions of ASLTS now use the acpibin utility, much like they
use acpiexec. However, when use of acpibin was added, it was not
treated like acpiexec and was assumed to exist in whatever PATH a user
had set when running the tests. When trying to use ASLTS in a very
pristine environment (i.e., no previous version of ACPICA user space
tools is available), portions of the test suite will produce false
failures because acpibin cannot be found and run.
This patch fixes ASLTS so that the use of acpibin is treated exactly
the same as acpiexec -- an environment variable must be defined (in
this case, $acpibin) with the location of the executable, aslts.sh
makes sure a value for the variable is set, Do uses $acpibin (instead
of assuming acpibin exists in a user's PATH), and the various bits
of documentation are updated to note the new environment variable.
Signed-off-by: Al Stone <ahs3(a)redhat.com>
---
tests/aslts.sh | 10 ++++++++--
tests/aslts/HOW_TO_INSTALL | 6 +++++-
tests/aslts/HOW_TO_USE | 4 ++++
tests/aslts/bin/Do | 11 +++++++++--
4 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/tests/aslts.sh b/tests/aslts.sh
index 8df422fbc..d8b364be4 100755
--- a/tests/aslts.sh
+++ b/tests/aslts.sh
@@ -7,6 +7,7 @@
postfix=`date +%H%M%S`
tmp_iasl=/tmp/iasl-$postfix
tmp_acpiexec=/tmp/acpiexec-$postfix
+tmp_acpibin=/tmp/acpibin-$postfix
TEST_CASES=
TEST_MODES=
@@ -65,6 +66,7 @@ setup_environment() {
export ASL=$tmp_iasl
export acpiexec=$tmp_acpiexec
+ export acpibin=$tmp_acpibin
export ASLTSDIR=$aslts_dir
export PATH=$ASLTSDIR/bin:$PATH
}
@@ -75,7 +77,7 @@ build_acpi_tools() {
restore_dir=$PWD
cd ${generation_dir}
- rm -f $tmp_iasl $tmp_acpiexec
+ rm -f $tmp_iasl $tmp_acpiexec $tmp_acpibin
# Build native-width iASL compiler and acpiexec
if [ ! -e bin/iasl -o ! -e bin/acpiexec ]; then
@@ -91,6 +93,7 @@ build_acpi_tools() {
echo "Installing ACPICA tools"
cp bin/iasl $tmp_iasl
cp bin/acpiexec $tmp_acpiexec
+ cp bin/acpibin $tmp_acpibin
else
echo "Could not find iASL/acpiexec tools"
exit
@@ -103,6 +106,9 @@ build_acpi_tools() {
elif [ ! -f $tmp_acpiexec ] ; then
echo "acpiexec utility not found"
exit
+ elif [ ! -f $tmp_acpibin ] ; then
+ echo "acpibin utility not found"
+ exit
fi
cd $restore_dir
@@ -140,7 +146,7 @@ run_aslts() {
echo "ASL Test Suite Finished: `date`"
echo " Started: $start_time"
- rm -f $tmp_iasl $tmp_acpiexec
+ rm -f $tmp_iasl $tmp_acpiexec $tmp_acpibin
fi;
}
diff --git a/tests/aslts/HOW_TO_INSTALL b/tests/aslts/HOW_TO_INSTALL
index 44648e2fe..300a86310 100644
--- a/tests/aslts/HOW_TO_INSTALL
+++ b/tests/aslts/HOW_TO_INSTALL
@@ -49,12 +49,16 @@ ENVIRONMENT
> export ASL="c:/acpica/libraries/iasl.exe"
- For test execution, two additional variables are required:
+ For test execution, three additional variables are required:
acpiexec - path to acpiexec utility: (example)
> export acpiexec="c:/acpica/libraries/acpiexec.exe"
+ acpibin - path to acpibin utility: (example)
+
+ > export acpibin="c:/acpica/libraries/acpibin.exe"
+
ASLTSDIR - path to the aslts directory: (example)
> export ASLTSDIR="c:/acpica/tests/aslts"
diff --git a/tests/aslts/HOW_TO_USE b/tests/aslts/HOW_TO_USE
index 233fdbb03..d60945802 100644
--- a/tests/aslts/HOW_TO_USE
+++ b/tests/aslts/HOW_TO_USE
@@ -32,6 +32,10 @@ How to execute the run-time tests
> export acpiexec="c:/acpica/libraries/acpiexec.exe"
+ acpibin - path to acpibin utility: (example)
+
+ > export acpibin="c:/acpica/libraries/acpibin.exe"
+
ASLTSDIR - path to the aslts directory: (example)
> export ASLTSDIR="c:/acpica/tests/aslts"
diff --git a/tests/aslts/bin/Do b/tests/aslts/bin/Do
index d034072d4..f4742eda1 100755
--- a/tests/aslts/bin/Do
+++ b/tests/aslts/bin/Do
@@ -20,12 +20,13 @@
#
# ASL - iASL compiler
# acpiexec - AcpiExec utility
+# acpibin - AcpiBin utility
# ASLTSDIR - pathname of root directory of aslts test suite
#
# External definitions required for particular command:
#
# 0 - ASLTSDIR, ASL
-# 1 - ASLTSDIR, acpiexec
+# 1 - ASLTSDIR, acpiexec, acpibin
# 2 - ASLTSDIR
# 3 - none
# 4 - ASLTSDIR
@@ -346,7 +347,7 @@ binary_compare()
if [ ! -f "$normal_compile_dir/$filename" ]; then
echo " binary compare $mode the following file does not exist:
$normal_compile_dir/$filename"
else
- acpibin -a "$f" "$normal_compile_dir/$filename" > /dev/null
+ $acpibin -a "$f" "$normal_compile_dir/$filename" > /dev/null
if [ $? -ne 0 ]; then
echo " [[ Error: $mode Binary compare for $filename failed ]]"
else
@@ -809,6 +810,12 @@ elif [ $CMD == $RUNTESTS ]; then
do_exit 1 "Undefined acpiexec variable! Set it to pathname of AcpiExec utility."
fi
+ # Check access to AcpiBin utility
+
+ if [ ! -f "$acpibin" ]; then
+ do_exit 1 "Undefined acpibin variable! Set it to pathname of AcpiBin utility."
+ fi
+
shift 1
ASLTSRUN_PARAMS=
--
2.13.5
4 years, 9 months
Re: [Devel] [PATCH] tools/power/acpi: fix acpi power tool building error
by Zheng, Lv
Hi,
> From: winton.liu [mailto:[email protected]]
> Subject: [PATCH] tools/power/acpi: fix acpi power tool building error
>
> When we tried to build acpi power tool, just like the following:
> $make tools/acpi
> ... ...
> can't create power/acpi/tools/acpidbg/acpidbg.o: No such file or directory
> ... ...
>
> Root cause is that the 'tools' folder in the path
> 'power/acpi/tools/acpidbg/acpidbg.o' doesn't exist.
The problem actually is:
The tools/power/acpi makefiles tried to derive the descend mechanism from tools generic makefile.
And the generic descend mechanism contains a trick to hide the intermediate folder (ex., power) and finally it doesn't cover all build cases.
For example:
1. Stay in kernel source tree, type "make tools/acpi"
2. Stay in tools folder, type "make acpi"
3. Stay in tools/power/acpi, type "make"
4. Stay in tools/power/acpi/tools/acpidbg, type "make"
And if you combine -O, you'll find more problems.
It's not resolvable unless you can fix the descend mechanism.
Currently, we prepared the makefile to be safe for
1. Case 2,3,4 without -O.
2. Case 2 with -O
So you need to ensure all supported stuffs are still working after applying your change.
Thanks
Lv
>
> Signed-off-by: winton.liu <18502523564(a)163.com>
> ---
> tools/power/acpi/Makefile.config | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/power/acpi/Makefile.config b/tools/power/acpi/Makefile.config
> index a1883bb..fb5559f 100644
> --- a/tools/power/acpi/Makefile.config
> +++ b/tools/power/acpi/Makefile.config
> @@ -18,7 +18,7 @@ include $(srctree)/../../scripts/Makefile.include
>
> OUTPUT=$(srctree)/
> ifeq ("$(origin O)", "command line")
> - OUTPUT := $(O)/power/acpi/
> + OUTPUT := $(O)/tools/power/acpi/
> endif
> #$(info Determined 'OUTPUT' to be $(OUTPUT))
>
> --
> 1.9.1
>
4 years, 9 months
[PATCH v7 0/5] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
by Shameer Kolothum
On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.
The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.
This patch implements an ACPI and DT based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.
To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve the
associated ITS base address from a device IORT node.
2. Added a generic helper function to of iommu code to retrieve the
associated msi controller base address from for a PCI RC
msi-mapping and also platform device msi-parent.
3. Added quirk to SMMUv3 to retrieve the HW ITS address and replace
the default SW MSI reserve address based on the IORT SMMU model
or DT bindings.
Changelog:
v6 --> v7
Addressed request from Will to add DT support for the erratum:
- added bt binding
- add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions
v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
is not applicable. Provided a generic function in iommu code and added
back the quirk implementation in SMMU v3 driver(patch#3)
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward
HW topologies are handled while reserving ITS regions(patch #1).
v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into
iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).
v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
iort helper function.
v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.
RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead of vendor specific CSRT table.
John Garry (2):
Doc: iommu/arm-smmu-v3: Add workaround for HiSilicon erratum 161010801
iommu/of: Add msi address regions reservation helper
Shameer Kolothum (3):
ACPI/IORT: Add msi address regions reservation helper
iommu/dma: Add a helper function to reserve HW MSI address regions for
IOMMU drivers
iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
Documentation/arm64/silicon-errata.txt | 1 +
.../devicetree/bindings/iommu/arm,smmu-v3.txt | 3 +
drivers/acpi/arm64/iort.c | 96 ++++++++++++++++-
drivers/iommu/arm-smmu-v3.c | 28 ++++-
drivers/iommu/dma-iommu.c | 19 ++++
drivers/iommu/of_iommu.c | 117 +++++++++++++++++++++
drivers/irqchip/irq-gic-v3-its.c | 3 +-
include/linux/acpi_iort.h | 7 +-
include/linux/dma-iommu.h | 7 ++
include/linux/of_iommu.h | 10 ++
10 files changed, 281 insertions(+), 10 deletions(-)
--
1.9.1
4 years, 9 months
[PATCH v4 0/2] Make cppc acpi driver aware of pcc subspace ids
by George Cherian
The current cppc acpi driver works with only one pcc subspace id.
It maintains and registers only one pcc channel even if the acpi table has
different pcc subspace ids.
As per ACPI 6.2 spec all PCC registers, for all processors in the same
performance domain (as defined by _PSD), must be defined to be in the same
subspace. The series tries to address the same by making cppc acpi driver
aware of multiple possible pcc subspace ids.
Patch 1 : In preparation to share the MAX_PCC_SUBSPACE definition with cppc acpi
driver
Patch 2 : Make the cppc acpi driver aware of multiple pcc subspace ids.
Changes from v3:
- Address Issue reported by kbuild-robot.
Changes from v2:
- Addressed Prashanth's comments on
* Not to use local variables to update mpar_count, last_mpar_reset and
last_cmd_cmpl_time
* Add check for kzalloc failure in pcc_data_alloc()
* Initialize pcc_subspace_id to -1 in acpi_cppc_processor_probe()
* Check for pcc_subspace_id validity before registering pcc_channel
Changes from v1:
- Add last_cmd_cmpl_time, last_mpar_reset, mpar_count to the cppc_pcc_data to
make it per subspace.
- PCC per subspace dynamic allocation support added instead of static
allocation
- Added a new function pcc_data_alloc, In instances where CPU's with SMT
support same PCC subspace would be used for all CPU's belonging to same
physical core. This function adds the pcc_subspace refcounting and allocates
the cppc_pcc_data per unique subspace idx.
- Added cleanup in acpi_cppc_processor_exit. Free the mbox channel and free
the cppc_pcc_data in case refcount is zero.
George Cherian (2):
mailbox: PCC: Move the MAX_PCC_SUBSPACES definition to header file
ACPI / CPPC: Make cppc acpi driver aware of pcc subspace ids
drivers/acpi/cppc_acpi.c | 243 +++++++++++++++++++++++++++++------------------
drivers/mailbox/pcc.c | 1 -
include/acpi/pcc.h | 1 +
3 files changed, 154 insertions(+), 91 deletions(-)
--
2.1.4
4 years, 9 months
Re: [Devel] [PATCH v7 1/5] Doc: iommu/arm-smmu-v3: Add workaround for HiSilicon erratum 161010801
by Shameerali Kolothum Thodi
> -----Original Message-----
> From: Rob Herring [mailto:[email protected]]
> Sent: Tuesday, September 19, 2017 3:53 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> sudeep.holla(a)arm.com; will.deacon(a)arm.com; robin.murphy(a)arm.com;
> joro(a)8bytes.org; mark.rutland(a)arm.com; hanjun.guo(a)linaro.org; Gabriele
> Paoloni <gabriele.paoloni(a)huawei.com>; John Garry
> <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org; linux-arm-
> kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org;
> devicetree(a)vger.kernel.org; devel(a)acpica.org; Linuxarm
> <linuxarm(a)huawei.com>; Wangzhou (B) <wangzhou1(a)hisilicon.com>;
> Guohanjun (Hanjun Guo) <guohanjun(a)huawei.com>
> Subject: Re: [PATCH v7 1/5] Doc: iommu/arm-smmu-v3: Add workaround for
> HiSilicon erratum 161010801
>
> On Thu, Sep 14, 2017 at 01:57:52PM +0100, Shameer Kolothum wrote:
> > From: John Garry <john.garry(a)huawei.com>
> >
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> platforms
> > hip06/hip07 to support the SMMU mappings for MSI transactions.
> >
> > On these platforms, GICv3 ITS translator is presented with the deviceID
> > by extending the MSI payload data to 64 bits to include the deviceID.
> > Hence, the PCIe controller on this platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI.
> >
> > This patch adds a SMMUv3 binding to flag that the SMMU breaks msi
> > translation at ITS.
> >
> > Also, the arm64 silicon errata is updated with this same erratum.
> >
> > Signed-off-by: John Garry <john.garry(a)huawei.com>
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi(a)huawei.com>
[...]
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
> > @@ -55,6 +55,9 @@ the PCIe specification.
> > - hisilicon,broken-prefetch-cmd
> > : Avoid sending CMD_PREFETCH_* commands to the SMMU.
> >
> > +- hisilicon,broken-untranslated-msi
> > + : Reserve ITS HW region to avoid translating msi.
> > +
>
> This should be determined from the compatible string. Continuing to add
> properties for each errata doesn't scale.
Ok. I think the suggestion here is to follow the arm-smmu.c (SMMUv1/v2)
driver way of implementing the errata. As you might have noticed, the
SMMUv3 driver dt errata framework depends on properties and this will
change the way errata is implemented in the driver now.
Hi Will/Robin,
Could you please take a look and let us know your thoughts on changing
the SMMUv3 dt errata implementation to version/model/compatible string
framework for this quirk.
Thanks,
Shameer
4 years, 9 months
Re: [Devel] [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S
by Will Deacon
On Wed, Sep 13, 2017 at 06:11:13PM +0800, Yisheng Xie wrote:
> On 2017/9/13 11:06, Will Deacon wrote:
> > On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote:
> >> On 31/08/17 09:20, Yisheng Xie wrote:
> >>> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which
> >>> means we should not disable stall mode if stall/terminate mode is not
> >>> configuable.
> >>>
> >>> Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which
> >>> means if stall mode is force we should always set CD.S.
> >>>
> >>> This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use
> >>> TERMINATE feature checking to ensue above ILLEGAL cases from happening.
> >>>
> >>> Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
> >>> ---
> >>> drivers/iommu/arm-smmu-v3.c | 22 ++++++++++++++++------
> >>> 1 file changed, 16 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> >>> index dbda2eb..0745522 100644
> >>> --- a/drivers/iommu/arm-smmu-v3.c
> >>> +++ b/drivers/iommu/arm-smmu-v3.c
> >>> @@ -55,6 +55,7 @@
> >>> #define IDR0_STALL_MODEL_SHIFT 24
> >>> #define IDR0_STALL_MODEL_MASK 0x3
> >>> #define IDR0_STALL_MODEL_STALL (0 << IDR0_STALL_MODEL_SHIFT)
> >>> +#define IDR0_STALL_MODEL_NS (1 << IDR0_STALL_MODEL_SHIFT)
> >>> #define IDR0_STALL_MODEL_FORCE (2 << IDR0_STALL_MODEL_SHIFT)
> >>> #define IDR0_TTENDIAN_SHIFT 21
> >>> #define IDR0_TTENDIAN_MASK 0x3
> >>> @@ -766,6 +767,7 @@ struct arm_smmu_device {
> >>> #define ARM_SMMU_FEAT_SVM (1 << 15)
> >>> #define ARM_SMMU_FEAT_HA (1 << 16)
> >>> #define ARM_SMMU_FEAT_HD (1 << 17)
> >>> +#define ARM_SMMU_FEAT_TERMINATE (1 << 18)
> >>
> >> I'd rather introduce something like "ARM_SMMU_FEAT_STALL_FORCE" instead.
> >> Terminate model has another meaning, and is defined by a different bit in
> >> IDR0.
> >
> > Yes. What we need to do is:
> >
> > - If STALL_MODEL is 0b00, then set S1STALLD
>
> Yes, and within this case, we can only set the S1STALLD for masters which can
> not stall in the future?
Yeah, something like that. I'd probably predicate it on having afault
handler registered too.
Will
4 years, 9 months