Re: [PATCH v3 3/3] iommu: mtk_iommu: Add support for MT6795 Helio X10 M4Us
On Thu, 2022-06-09 at 12:40 +0200, AngeloGioacchino Del Regno wrote:
> Add support for the M4Us found in the MT6795 Helio X10 SoC.
>
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delre...@collabora.com>
Retitle to: iommu/mediatek: Xxx, then
Reviewed-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8611cf8e4bd5..beca1c5a6c10 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -160,6 +160,7 @@
> enum mtk_iommu_plat {
> M4U_MT2712,
> M4U_MT6779,
> + M4U_MT6795,
> M4U_MT8167,
> M4U_MT8173,
> M4U_MT8183,
> @@ -1424,6 +1425,19 @@ static const struct mtk_iommu_plat_data
> mt6779_data = {
> .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
> };
>
> +static const struct mtk_iommu_plat_data mt6795_data = {
> + .m4u_plat = M4U_MT6795,
> + .flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
> + HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM |
> + TF_PORT_TO_ADDR_MT8173,
> + .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> + .banks_num= 1,
> + .banks_enable = {true},
> + .iova_region = single_domain,
> + .iova_region_nr = ARRAY_SIZE(single_domain),
> + .larbid_remap = {{0}, {1}, {2}, {3}, {4}}, /* Linear mapping.
> */
> +};
> +
> static const struct mtk_iommu_plat_data mt8167_data = {
> .m4u_plat = M4U_MT8167,
> .flags= RESET_AXI | HAS_LEGACY_IVRP_PADDR |
> MTK_IOMMU_TYPE_MM,
> @@ -1536,6 +1550,7 @@ static const struct mtk_iommu_plat_data
> mt8195_data_vpp = {
> static const struct of_device_id mtk_iommu_of_ids[] = {
> { .compatible = "mediatek,mt2712-m4u", .data = _data},
> { .compatible = "mediatek,mt6779-m4u", .data = _data},
> + { .compatible = "mediatek,mt6795-m4u", .data = _data},
> { .compatible = "mediatek,mt8167-m4u", .data = _data},
> { .compatible = "mediatek,mt8173-m4u", .data = _data},
> { .compatible = "mediatek,mt8183-m4u", .data = _data},
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 1/3] dt-bindings: mediatek: Add bindings for MT6795 M4U
On Thu, 2022-06-09 at 12:39 +0200, AngeloGioacchino Del Regno wrote: > Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U. > > Signed-off-by: AngeloGioacchino Del Regno < > angelogioacchino.delre...@collabora.com> > Acked-by: Rob Herring > --- > .../bindings/iommu/mediatek,iommu.yaml| 4 + > include/dt-bindings/memory/mt6795-larb-port.h | 96 > +++ > 2 files changed, 100 insertions(+) > create mode 100644 include/dt-bindings/memory/mt6795-larb-port.h > > diff --git > a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > index d5e3272a54e8..20902c387520 100644 > --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml > @@ -73,6 +73,7 @@ properties: >- mediatek,mt2701-m4u # generation one >- mediatek,mt2712-m4u # generation two >- mediatek,mt6779-m4u # generation two > + - mediatek,mt6795-m4u # generation two >- mediatek,mt8167-m4u # generation two >- mediatek,mt8173-m4u # generation two >- mediatek,mt8183-m4u # generation two > @@ -128,6 +129,7 @@ properties: >dt-binding/memory/mt2701-larb-port.h for mt2701 and mt7623, >dt-binding/memory/mt2712-larb-port.h for mt2712, >dt-binding/memory/mt6779-larb-port.h for mt6779, > + dt-binding/memory/mt6795-larb-port.h for mt6795, >dt-binding/memory/mt8167-larb-port.h for mt8167, >dt-binding/memory/mt8173-larb-port.h for mt8173, >dt-binding/memory/mt8183-larb-port.h for mt8183, > @@ -152,6 +154,7 @@ allOf: > enum: >- mediatek,mt2701-m4u >- mediatek,mt2712-m4u > + - mediatek,mt6795-m4u >- mediatek,mt8173-m4u >- mediatek,mt8186-iommu-mm >- mediatek,mt8192-m4u > @@ -181,6 +184,7 @@ allOf: >contains: > enum: >- mediatek,mt2712-m4u > + - mediatek,mt6795-m4u >- mediatek,mt8173-m4u > > then: > diff --git a/include/dt-bindings/memory/mt6795-larb-port.h > b/include/dt-bindings/memory/mt6795-larb-port.h > new file mode 100644 > index ..223aca8fd350 > --- /dev/null > +++ b/include/dt-bindings/memory/mt6795-larb-port.h > @@ -0,0 +1,96 @@ > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ > +/* > + * Copyright (c) 2022 Collabora Ltd. > + * Author: AngeloGioacchino Del Regno < > angelogioacchino.delre...@collabora.com> > + */ > + > +#ifndef _DT_BINDINGS_MEMORY_MT6795_LARB_PORT_H_ > +#define _DT_BINDINGS_MEMORY_MT6795_LARB_PORT_H_ > + > +#include > + > +#define M4U_LARB0_ID 0 > +#define M4U_LARB1_ID 1 > +#define M4U_LARB2_ID 2 > +#define M4U_LARB3_ID 3 > +#define M4U_LARB4_ID 4 > +#define M4U_LARB5_ID 5 Just a nitpick: M4U_LARB5_ID is not used, then remove this. > + > +/* larb0 */ > +#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_LARB0_ID, 0) > +#define M4U_PORT_DISP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 1) > +#define M4U_PORT_DISP_RDMA1 MTK_M4U_ID(M4U_LARB0_ID, 2) > +#define M4U_PORT_DISP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 3) > +#define M4U_PORT_DISP_OVL1 MTK_M4U_ID(M4U_LARB0_ID, 4) > +#define M4U_PORT_DISP_RDMA2 MTK_M4U_ID(M4U_LARB0_ID, 5) > +#define M4U_PORT_DISP_WDMA1 MTK_M4U_ID(M4U_LARB0_ID, 6) > +#define M4U_PORT_DISP_OD_R MTK_M4U_ID(M4U_LARB0_ID, 7) > +#define M4U_PORT_DISP_OD_W MTK_M4U_ID(M4U_LARB0_ID, 8) > +#define M4U_PORT_MDP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 9) > +#define M4U_PORT_MDP_RDMA1 MTK_M4U_ID(M4U_LARB0_ID, 10) > +#define M4U_PORT_MDP_WDMAMTK_M4U_ID(M4U_LARB0_ID, 11) > +#define M4U_PORT_MDP_WROT0 MTK_M4U_ID(M4U_LARB0_ID, 12) > +#define M4U_PORT_MDP_WROT1 MTK_M4U_ID(M4U_LARB0_ID, 13) > + > +/* larb1 */ > +#define M4U_PORT_VDEC_MC MTK_M4U_ID(M4U_LARB1_ID, 0) > +#define M4U_PORT_VDEC_PP MTK_M4U_ID(M4U_LARB1_ID, 1) > +#define M4U_PORT_VDEC_UFOMTK_M4U_ID(M4U_LARB1_ID, 2) > +#define M4U_PORT_VDEC_VLDMTK_M4U_ID(M4U_LARB1_ID, 3) > +#define M4U_PORT_VDEC_VLD2 MTK_M4U_ID(M4U_LARB1_ID, 4) > +#define M4U_PORT_VDEC_AVC_MV MTK_M4U_ID(M4U_LARB1_ID, 5) > +#define M4U_PORT_VDEC_PRED_RDMTK_M4U_ID(M4U_LARB1_ID > , 6) > +#define M4U_PORT_VDEC_PRED_WRMTK_M4U_ID(M4U_LARB1_ID > , 7) > +#define M4U_PORT_VDEC_PPWRAP MTK_M4U_ID(M4U_LARB1_ID, 8) > + > +/* larb2 */ > +#define M4U_PORT_CAM_IMGOMTK_M4U_ID(M4U_LARB2_ID, 0) > +#define M4U_PORT_CAM_RRZOMTK_M4U_ID(M4U_LARB2_ID, 1) > +#define M4U_PORT_CAM_AAO MTK_M4U_ID(M4U_LARB2_ID, 2) > +#define M4U_PORT_CAM_LCSOMTK_M4U_ID(M4U_LARB2_ID, 3) > +#define
Re: [PATCH v3 2/3] iommu: mtk_iommu: Introduce new flag TF_PORT_TO_ADDR_MT8173
On Thu, 2022-06-09 at 12:40 +0200, AngeloGioacchino Del Regno wrote:
> In preparation for adding support for MT6795, add a new flag named
> TF_PORT_TO_ADDR_MT8173 and use that instead of checking for m4u_plat
> type in mtk_iommu_hw_init() to avoid seeing a long list of m4u_plat
> checks there in the future.
>
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delre...@collabora.com>
Retitle to: iommu/mediatek: Xxx, then
Reviewed-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 0ea0848581e9..8611cf8e4bd5 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -140,6 +140,7 @@
> #define IFA_IOMMU_PCIE_SUPPORT BIT(16)
> /* IOMMU I/O (r/w) is enabled using PERICFG_IOMMU_1 register */
> #define HAS_PERI_IOMMU1_REG BIT(17)
> +#define TF_PORT_TO_ADDR_MT8173 BIT(18)
>
> #define MTK_IOMMU_HAS_FLAG_MASK(pdata, _x, mask) \
> pdata)->flags) & (mask)) == (_x))
> @@ -960,7 +961,7 @@ static int mtk_iommu_hw_init(const struct
> mtk_iommu_data *data, unsigned int ban
>* Global control settings are in bank0. May re-init these
> global registers
>* since no sure if there is bank0 consumers.
>*/
> - if (data->plat_data->m4u_plat == M4U_MT8173) {
> + if (MTK_IOMMU_HAS_FLAG(data->plat_data,
> TF_PORT_TO_ADDR_MT8173)) {
> regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
>F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> } else {
> @@ -1437,7 +1438,8 @@ static const struct mtk_iommu_plat_data
> mt8167_data = {
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
> - HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM,
> + HAS_LEGACY_IVRP_PADDR | MTK_IOMMU_TYPE_MM |
> + TF_PORT_TO_ADDR_MT8173,
> .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> .banks_num= 1,
> .banks_enable = {true},
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 6/6] iommu: mtk_iommu: Lookup phandle to retrieve syscon to pericfg
On Thu, 2022-06-09 at 12:08 +0200, AngeloGioacchino Del Regno wrote:
> On some SoCs (of which only MT8195 is supported at the time of
> writing),
> the "R" and "W" (I/O) enable bits for the IOMMUs are in the
> pericfg_ao
> register space and not in the IOMMU space: as it happened already
> with
> infracfg, it is expected that this list will grow.
Currently I don't see the list will grow. As commented before, In the
lastest SoC, The IOMMU enable bits for IOMMU will be in ATF, rather
than in this pericfg register region. In this case, Is this patch
unnecessary? or we could add this patch when there are 2 SoCs use this
setting at least? what's your opinion?
>
> Instead of specifying pericfg compatibles on a per-SoC basis,
> following
> what was done with infracfg, let's lookup the syscon by phandle
> instead.
>
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delre...@collabora.com>
> ---
> drivers/iommu/mtk_iommu.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 90685946fcbe..0ea0848581e9 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -138,6 +138,8 @@
> /* PM and clock always on. e.g. infra iommu */
> #define PM_CLK_AOBIT(15)
> #define IFA_IOMMU_PCIE_SUPPORT BIT(16)
> +/* IOMMU I/O (r/w) is enabled using PERICFG_IOMMU_1 register */
> +#define HAS_PERI_IOMMU1_REG BIT(17)
>
> #define MTK_IOMMU_HAS_FLAG_MASK(pdata, _x, mask) \
> pdata)->flags) & (mask)) == (_x))
> @@ -187,7 +189,6 @@ struct mtk_iommu_plat_data {
> u32 flags;
> u32 inv_sel_reg;
>
> - char*pericfg_comp_str;
> struct list_head*hw_list;
> unsigned intiova_region_nr;
> const struct mtk_iommu_iova_region *iova_region;
> @@ -1218,14 +1219,16 @@ static int mtk_iommu_probe(struct
> platform_device *pdev)
> goto out_runtime_disable;
> }
> } else if (MTK_IOMMU_IS_TYPE(data->plat_data,
> MTK_IOMMU_TYPE_INFRA) &&
> -data->plat_data->pericfg_comp_str) {
> - infracfg = syscon_regmap_lookup_by_compatible(data-
> >plat_data->pericfg_comp_str);
> - if (IS_ERR(infracfg)) {
> - ret = PTR_ERR(infracfg);
> - goto out_runtime_disable;
> +MTK_IOMMU_HAS_FLAG(data->plat_data,
> HAS_PERI_IOMMU1_REG)) {
> + data->pericfg = syscon_regmap_lookup_by_phandle(dev-
> >of_node, "mediatek,pericfg");
> + if (IS_ERR(data->pericfg)) {
> + p = "mediatek,mt8195-pericfg_ao";
> + data->pericfg =
> syscon_regmap_lookup_by_compatible(p);
Upstream doesn't have the mt8195 iommu node currently, thus We don't
need to recover for the previous dts case. right?
> + if (IS_ERR(data->pericfg)) {
> + ret = PTR_ERR(data->pericfg);
> + goto out_runtime_disable;
> + }
> }
> -
> - data->pericfg = infracfg;
> }
>
> platform_set_drvdata(pdev, data);
> @@ -1484,8 +1487,8 @@ static const struct mtk_iommu_plat_data
> mt8192_data = {
> static const struct mtk_iommu_plat_data mt8195_data_infra = {
> .m4u_plat = M4U_MT8195,
> .flags= WR_THROT_EN | DCM_DISABLE | STD_AXI_MODE |
> PM_CLK_AO |
> - MTK_IOMMU_TYPE_INFRA |
> IFA_IOMMU_PCIE_SUPPORT,
> - .pericfg_comp_str = "mediatek,mt8195-pericfg_ao",
> + HAS_PERI_IOMMU1_REG | MTK_IOMMU_TYPE_INFRA
> |
> + IFA_IOMMU_PCIE_SUPPORT,
> .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
> .banks_num= 5,
> .banks_enable = {true, false, false, false, true},
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 2/6] iommu: mtk_iommu: Lookup phandle to retrieve syscon to infracfg
On Thu, 2022-06-09 at 12:07 +0200, AngeloGioacchino Del Regno wrote:
> This driver will get support for more SoCs and the list of infracfg
> compatibles is expected to grow: in order to prevent getting this
> situation out of control and see a long list of compatible strings,
> add support to retrieve a handle to infracfg's regmap through a
> new "mediatek,infracfg" phandle.
>
> In order to keep retrocompatibility with older devicetrees, the old
> way is kept in place.
>
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delre...@collabora.com>
Retitle to: iommu/mediatek: Xxx, then
Reviewed-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 38 -
> -
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index bb9dd92c9898..90685946fcbe 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -1140,22 +1140,32 @@ static int mtk_iommu_probe(struct
> platform_device *pdev)
> data->protect_base = ALIGN(virt_to_phys(protect),
> MTK_PROTECT_PA_ALIGN);
>
> if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
> - switch (data->plat_data->m4u_plat) {
> - case M4U_MT2712:
> - p = "mediatek,mt2712-infracfg";
> - break;
> - case M4U_MT8173:
> - p = "mediatek,mt8173-infracfg";
> - break;
> - default:
> - p = NULL;
> + infracfg = syscon_regmap_lookup_by_phandle(dev-
> >of_node, "mediatek,infracfg");
> + if (IS_ERR(infracfg)) {
> + /*
> + * Legacy devicetrees will not specify a
> phandle to
> + * mediatek,infracfg: in that case, we use the
> older
> + * way to retrieve a syscon to infra.
> + *
> + * This is for retrocompatibility purposes
> only, hence
> + * no more compatibles shall be added to this.
> + */
> + switch (data->plat_data->m4u_plat) {
> + case M4U_MT2712:
> + p = "mediatek,mt2712-infracfg";
> + break;
> + case M4U_MT8173:
> + p = "mediatek,mt8173-infracfg";
> + break;
> + default:
> + p = NULL;
> + }
> +
> + infracfg =
> syscon_regmap_lookup_by_compatible(p);
> + if (IS_ERR(infracfg))
> + return PTR_ERR(infracfg);
> }
>
> - infracfg = syscon_regmap_lookup_by_compatible(p);
> -
> - if (IS_ERR(infracfg))
> - return PTR_ERR(infracfg);
> -
> ret = regmap_read(infracfg, REG_INFRA_MISC, );
> if (ret)
> return ret;
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 6/7] iommu/amd: Do not support IOMMU_DOMAIN_IDENTITY when SNP is enabled
Since DTE[Mode]=0 is prohibited on system, which enables SNP,
the passthrough domain (IOMMU_DOMAIN_IDENTITY) is not support.
Instead, only support IOMMU_DOMAIN_DMA[_FQ] domains.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/iommu.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index ca4647f04382..ecde9e08102d 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2379,6 +2379,17 @@ static int amd_iommu_def_domain_type(struct device *dev)
return 0;
}
+static bool amd_iommu_domain_type_supported(struct device *dev, int type)
+{
+ /*
+* Since DTE[Mode]=0 is prohibited on SNP-enabled system,
+* default to use IOMMU_DOMAIN_DMA[_FQ].
+*/
+ if (amd_iommu_snp_en && (type == IOMMU_DOMAIN_IDENTITY))
+ return false;
+ return true;
+}
+
struct iommu_ops amd_iommu_ops = {
.capable = amd_iommu_capable,
.domain_alloc = amd_iommu_domain_alloc,
@@ -2391,6 +2402,7 @@ struct iommu_ops amd_iommu_ops = {
.is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap = AMD_IOMMU_PGSIZES,
.def_domain_type = amd_iommu_def_domain_type,
+ .domain_type_supported = amd_iommu_domain_type_supported,
.default_domain_ops = &(const struct iommu_domain_ops) {
.attach_dev = amd_iommu_attach_device,
.detach_dev = amd_iommu_detach_device,
--
2.32.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 3/7] iommu/amd: Introduce function to check SEV-SNP support
From: Brijesh Singh
The SEV-SNP support requires that IOMMU must to enabled. It also prohibits
IOMMU configurations where DTE[Mode]=0, which means the SEV-SNP feature is
not supported with IOMMU passthrough domain (a.k.a IOMMU_DOMAIN_IDENTITY),
or when AMD IOMMU driver is configured to not use the IOMMU host (v1) page
table.
Otherwise, the SNP_INIT command (used for initializing firmware) will fail.
Unlike other IOMMU features, SNP feature does not have an enable bit in
the IOMMU control register. Instead, the feature is considered enabled
when SNP_INIT command is executed, which is done by a separte driver.
Introduce iommu_sev_snp_supported() for checking if IOMMU supports
the SEV-SNP feature, and an amd_iommu_snp_en global variable to keep track
of SNP enable status.
Please see the IOMMU spec section 2.12 for further details.
Tested-by: Ashish Kalra
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Brijesh Singh
---
drivers/iommu/amd/amd_iommu_types.h | 11
drivers/iommu/amd/init.c| 39 ++---
drivers/iommu/amd/iommu.c | 4 +--
include/linux/iommu.h | 9 +++
4 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu_types.h
b/drivers/iommu/amd/amd_iommu_types.h
index 328572cf6fa5..6552c0da8f32 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -450,6 +450,9 @@ extern bool amd_iommu_irq_remap;
/* kmem_cache to get tables with 128 byte alignement */
extern struct kmem_cache *amd_iommu_irq_cache;
+/* SNP is enabled on the system? */
+extern bool amd_iommu_snp_en;
+
#define PCI_SBDF_TO_SEGID(sbdf)(((sbdf) >> 16) & 0x)
#define PCI_SBDF_TO_DEVID(sbdf)((sbdf) & 0x)
#define PCI_SEG_DEVID_TO_SBDF(seg, devid) u32)(seg) & 0x) << 16)
| \
@@ -999,4 +1002,12 @@ extern struct amd_irte_ops irte_32_ops;
extern struct amd_irte_ops irte_128_ops;
#endif
+/*
+ * ACPI table definitions
+ *
+ * These data structures are laid over the table to parse the important values
+ * out of it.
+ */
+extern struct iommu_ops amd_iommu_ops;
+
#endif /* _ASM_X86_AMD_IOMMU_TYPES_H */
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 3965bd3f4f67..da32e7bdd1fa 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -88,15 +88,6 @@
#define IVRS_GET_SBDF_ID(seg, bus, dev, fd)(((seg & 0x) << 16) | ((bus
& 0xff) << 8) \
| ((dev & 0x1f) << 3) | (fn &
0x7))
-/*
- * ACPI table definitions
- *
- * These data structures are laid over the table to parse the important values
- * out of it.
- */
-
-extern const struct iommu_ops amd_iommu_ops;
-
/*
* structure describing one IOMMU in the ACPI table. Typically followed by one
* or more ivhd_entrys.
@@ -166,6 +157,9 @@ static int amd_iommu_target_ivhd_type;
static bool amd_iommu_snp_sup;
+bool amd_iommu_snp_en;
+EXPORT_SYMBOL(amd_iommu_snp_en);
+
LIST_HEAD(amd_iommu_pci_seg_list); /* list of all PCI segments */
LIST_HEAD(amd_iommu_list); /* list of all AMD IOMMUs in the
system */
@@ -3543,3 +3537,30 @@ int amd_iommu_pc_set_reg(struct amd_iommu *iommu, u8
bank, u8 cntr, u8 fxn, u64
return iommu_pc_get_set_reg(iommu, bank, cntr, fxn, value, true);
}
+
+bool iommu_sev_snp_supported(void)
+{
+ /*
+* The SEV-SNP support requires that IOMMU must be enabled, and is
+* not configured in the passthrough mode.
+*/
+ if (no_iommu || iommu_default_passthrough()) {
+ pr_err("SEV-SNP: IOMMU is either disabled or configured in
passthrough mode.\n");
+ return false;
+ }
+
+ amd_iommu_snp_en = amd_iommu_snp_sup;
+ if (amd_iommu_snp_en)
+ pr_info("SNP enabled\n");
+
+ /* Enforce IOMMU v1 pagetable when SNP is enabled. */
+ if ((amd_iommu_pgtable != AMD_IOMMU_V1) &&
+amd_iommu_snp_en) {
+ pr_info("Force to using AMD IOMMU v1 page table due to SNP\n");
+ amd_iommu_pgtable = AMD_IOMMU_V1;
+ amd_iommu_ops.pgsize_bitmap = AMD_IOMMU_PGSIZES;
+ }
+
+ return amd_iommu_snp_en;
+}
+EXPORT_SYMBOL_GPL(iommu_sev_snp_supported);
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 3e1f0fa42ec3..b9dc0d4b6d77 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -70,7 +70,7 @@ LIST_HEAD(acpihid_map);
* Domain for untranslated devices - only allocated
* if iommu=pt passed on kernel cmd line.
*/
-const struct iommu_ops amd_iommu_ops;
+struct iommu_ops amd_iommu_ops;
static ATOMIC_NOTIFIER_HEAD(ppr_notifier);
int amd_iommu_max_glx_val = -1;
@@ -2368,7 +2368,7 @@ static int amd_iommu_def_domain_type(struct device *dev)
return 0;
}
-const struct iommu_ops amd_iommu_ops
[PATCH 4/7] iommu/amd: Set translation valid bit only when IO page tables are in use
On AMD system with SNP enabled, IOMMU hardware checks the host translation
valid (TV) and guest translation valid (GV) bits in the device table entry
(DTE) before accessing the corresponded page tables.
However, current IOMMU driver sets the TV bit for all devices regardless
of whether the host page table is in use. This results in
ILLEGAL_DEV_TABLE_ENTRY event for devices, which do not the host page
table root pointer set up.
Thefore, when SNP is enabled, only set TV bit when DMA remapping is not
used, which is when domain ID in the AMD IOMMU device table entry (DTE)
is zero.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/init.c | 3 ++-
drivers/iommu/amd/iommu.c | 15 +--
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index da32e7bdd1fa..a9152d3f33bf 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -2546,7 +2546,8 @@ static void init_device_table_dma(struct
amd_iommu_pci_seg *pci_seg)
for (devid = 0; devid <= pci_seg->last_bdf; ++devid) {
__set_dev_entry_bit(dev_table, devid, DEV_ENTRY_VALID);
- __set_dev_entry_bit(dev_table, devid, DEV_ENTRY_TRANSLATION);
+ if (!amd_iommu_snp_en)
+ __set_dev_entry_bit(dev_table, devid,
DEV_ENTRY_TRANSLATION);
}
}
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index b9dc0d4b6d77..ca4647f04382 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1552,7 +1552,14 @@ static void set_dte_entry(struct amd_iommu *iommu, u16
devid,
pte_root |= (domain->iop.mode & DEV_ENTRY_MODE_MASK)
<< DEV_ENTRY_MODE_SHIFT;
- pte_root |= DTE_FLAG_IR | DTE_FLAG_IW | DTE_FLAG_V | DTE_FLAG_TV;
+ pte_root |= DTE_FLAG_IR | DTE_FLAG_IW | DTE_FLAG_V;
+
+ /*
+* When SNP is enabled, Only set TV bit when IOMMU
+* page translation is in use.
+*/
+ if (!amd_iommu_snp_en || (domain->id != 0))
+ pte_root |= DTE_FLAG_TV;
flags = dev_table[devid].data[1];
@@ -1612,7 +1619,11 @@ static void clear_dte_entry(struct amd_iommu *iommu, u16
devid)
struct dev_table_entry *dev_table = get_dev_table(iommu);
/* remove entry from the device table seen by the hardware */
- dev_table[devid].data[0] = DTE_FLAG_V | DTE_FLAG_TV;
+ dev_table[devid].data[0] = DTE_FLAG_V;
+
+ if (!amd_iommu_snp_en)
+ dev_table[devid].data[0] |= DTE_FLAG_TV;
+
dev_table[devid].data[1] &= DTE_FLAG_MASK;
amd_iommu_apply_erratum_63(iommu, devid);
--
2.32.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 7/7] iommu/amd: Do not support IOMMUv2 APIs when SNP is enabled
The IOMMUv2 APIs (for supporting shared virtual memory with PASID)
configures the domain with IOMMU v2 page table, and sets DTE[Mode]=0.
This configuration cannot be supported on SNP-enabled system.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/init.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index a9152d3f33bf..1565f0fb955a 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -3435,7 +3435,12 @@ __setup("ivrs_acpihid", parse_ivrs_acpihid);
bool amd_iommu_v2_supported(void)
{
- return amd_iommu_v2_present;
+ /*
+* Since DTE[Mode]=0 is prohibited on SNP-enabled system
+* (i.e. EFR[SNPSup]=1), IOMMUv2 page table cannot be used without
+* setting up IOMMUv1 page table.
+*/
+ return amd_iommu_v2_present && !amd_iommu_snp_en;
}
EXPORT_SYMBOL(amd_iommu_v2_supported);
--
2.32.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/7] iommu/amd: Process all IVHDs before enabling IOMMU features
The ACPI IVRS table can contain multiple IVHD blocks. Each block contains
information used to initialize each IOMMU instance.
Currently, init_iommu_all sequentially process IVHD block and initialize
IOMMU instance one-by-one. However, certain features require all IOMMUs
to be configured in the same way system-wide. In case certain IVHD blocks
contain inconsistent information (most likely FW bugs), the driver needs
to go through and try to revert settings on IOMMUs that have already been
configured.
A solution is to split IOMMU initialization into 2 phases:
Phase 1 processes information of the IVRS table for all IOMMU instances.
This allow all IVHDs to be processed prior to enabling features.
Phase 2 iterates through all IOMMU instances and enabling each features.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/init.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 8877d2a20398..6a4a019f1e1d 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -1687,7 +1687,6 @@ static int __init init_iommu_one(struct amd_iommu *iommu,
struct ivhd_header *h,
struct acpi_table_header *ivrs_base)
{
struct amd_iommu_pci_seg *pci_seg;
- int ret;
pci_seg = get_pci_segment(h->pci_seg, ivrs_base);
if (pci_seg == NULL)
@@ -1768,6 +1767,13 @@ static int __init init_iommu_one(struct amd_iommu
*iommu, struct ivhd_header *h,
if (!iommu->mmio_base)
return -ENOMEM;
+ return init_iommu_from_acpi(iommu, h);
+}
+
+static int __init init_iommu_one_late(struct amd_iommu *iommu)
+{
+ int ret;
+
if (alloc_cwwb_sem(iommu))
return -ENOMEM;
@@ -1789,10 +1795,6 @@ static int __init init_iommu_one(struct amd_iommu
*iommu, struct ivhd_header *h,
if (amd_iommu_pre_enabled)
amd_iommu_pre_enabled = translation_pre_enabled(iommu);
- ret = init_iommu_from_acpi(iommu, h);
- if (ret)
- return ret;
-
if (amd_iommu_irq_remap) {
ret = amd_iommu_create_irq_domain(iommu);
if (ret)
@@ -1803,7 +1805,7 @@ static int __init init_iommu_one(struct amd_iommu *iommu,
struct ivhd_header *h,
* Make sure IOMMU is not considered to translate itself. The IVRS
* table tells us so, but this is a lie!
*/
- pci_seg->rlookup_table[iommu->devid] = NULL;
+ iommu->pci_seg->rlookup_table[iommu->devid] = NULL;
return 0;
}
@@ -1873,6 +1875,12 @@ static int __init init_iommu_all(struct
acpi_table_header *table)
}
WARN_ON(p != end);
+ for_each_iommu(iommu) {
+ ret = init_iommu_one_late(iommu);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
--
2.32.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/7] iommu/amd: Introduce a global variable for tracking SNP enable status
IOMMU support for SNP feature is detected via the EFR[SNPSup] bit.
Also, it is required that EFR[SNPSup] are consistent across all IOMMU
instances.
This information is needed early in the boot process,
since it is used to determine how IOMMU driver configures several other
IOMMU features and data structures (e.g. as soon as the IOMMU driver
finishes parsing IVHDs).
Introduce a global variable for tracking the SNP support status, which is
initialized before enabling the rest of IOMMU features.
Also throw a warning if found inconsistency EFR[SNPSup] among IOMMU
instances.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/init.c | 42 ++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 6a4a019f1e1d..3965bd3f4f67 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -164,6 +164,8 @@ static bool amd_iommu_disabled __initdata;
static bool amd_iommu_force_enable __initdata;
static int amd_iommu_target_ivhd_type;
+static bool amd_iommu_snp_sup;
+
LIST_HEAD(amd_iommu_pci_seg_list); /* list of all PCI segments */
LIST_HEAD(amd_iommu_list); /* list of all AMD IOMMUs in the
system */
@@ -355,7 +357,7 @@ static void iommu_set_cwwb_range(struct amd_iommu *iommu)
u64 start = iommu_virt_to_phys((void *)iommu->cmd_sem);
u64 entry = start & PM_ADDR_MASK;
- if (!iommu_feature(iommu, FEATURE_SNP))
+ if (!amd_iommu_snp_sup)
return;
/* Note:
@@ -770,7 +772,7 @@ static void *__init iommu_alloc_4k_pages(struct amd_iommu
*iommu,
void *buf = (void *)__get_free_pages(gfp, order);
if (buf &&
- iommu_feature(iommu, FEATURE_SNP) &&
+ amd_iommu_snp_sup &&
set_memory_4k((unsigned long)buf, (1 << order))) {
free_pages((unsigned long)buf, order);
buf = NULL;
@@ -1836,6 +1838,37 @@ static u8 get_highest_supported_ivhd_type(struct
acpi_table_header *ivrs)
return last_type;
}
+/*
+ * SNP is enabled system-wide. So, iterate through all the IOMMUs to
+ * verify all EFR[SNPSup] bits are set, and use global variable to track
+ * whether the feature is supported.
+ */
+static void __init init_snp_global(void)
+{
+ struct amd_iommu *iommu;
+
+ for_each_iommu(iommu) {
+ if (iommu_feature(iommu, FEATURE_SNP)) {
+ amd_iommu_snp_sup = true;
+ continue;
+ }
+
+ /*
+* Warn and mark SNP as not supported if there is inconsistency
+* in any of the IOMMU.
+*/
+ if (amd_iommu_snp_sup && !list_is_first(>list,
_iommu_list)) {
+ pr_err(FW_BUG "iommu%d (%04x:%02x:%02x.%01x): Found
inconsistent EFR[SNPSup].\n",
+ iommu->index, iommu->pci_seg->id,
PCI_BUS_NUM(iommu->devid),
+ PCI_SLOT(iommu->devid), PCI_FUNC(iommu->devid));
+ pr_err(FW_BUG "Disable SNP support\n");
+ amd_iommu_snp_sup = false;
+ }
+ return;
+ }
+ amd_iommu_snp_sup = true;
+}
+
/*
* Iterates over all IOMMU entries in the ACPI table, allocates the
* IOMMU structure and initializes it with init_iommu_one()
@@ -1875,6 +1908,8 @@ static int __init init_iommu_all(struct acpi_table_header
*table)
}
WARN_ON(p != end);
+ init_snp_global();
+
for_each_iommu(iommu) {
ret = init_iommu_one_late(iommu);
if (ret)
@@ -2095,6 +2130,9 @@ static void print_iommu_info(void)
if (iommu->features & FEATURE_GAM_VAPIC)
pr_cont(" GA_vAPIC");
+ if (iommu->features & FEATURE_SNP)
+ pr_cont(" SNP");
+
pr_cont("\n");
}
}
--
2.32.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 5/7] iommu: Add domain_type_supported() callback in iommu_ops
When user requests to change IOMMU domain to a new type, IOMMU generic
layer checks the requested type against the default domain type returned
by vendor-specific IOMMU driver.
However, there is only one default domain type, and current mechanism
does not allow if the requested type does not match the default type.
Introducing check_domain_type_supported() callback in iommu_ops,
which allows IOMMU generic layer to check with vendor-specific IOMMU driver
whether the requested type is supported. This allows user to request
types other than the default type.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/iommu.c | 13 -
include/linux/iommu.h | 2 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index f2c45b85b9fc..4afb956ce083 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1521,6 +1521,16 @@ struct iommu_group *fsl_mc_device_group(struct device
*dev)
}
EXPORT_SYMBOL_GPL(fsl_mc_device_group);
+static bool iommu_domain_type_supported(struct device *dev, int type)
+{
+ const struct iommu_ops *ops = dev_iommu_ops(dev);
+
+ if (ops->domain_type_supported)
+ return ops->domain_type_supported(dev, type);
+
+ return true;
+}
+
static int iommu_get_def_domain_type(struct device *dev)
{
const struct iommu_ops *ops = dev_iommu_ops(dev);
@@ -2937,7 +2947,8 @@ static int iommu_change_dev_def_domain(struct iommu_group
*group,
* domain the device was booted with
*/
type = dev_def_dom ? : iommu_def_domain_type;
- } else if (dev_def_dom && type != dev_def_dom) {
+ } else if (!iommu_domain_type_supported(dev, type) ||
+ (dev_def_dom && type != dev_def_dom)) {
dev_err_ratelimited(prev_dev, "Device cannot be in %s domain\n",
iommu_domain_type_str(type));
ret = -EINVAL;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index fecb72e1b11b..40c47ab15005 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -214,6 +214,7 @@ struct iommu_iotlb_gather {
* - IOMMU_DOMAIN_IDENTITY: must use an identity domain
* - IOMMU_DOMAIN_DMA: must use a dma domain
* - 0: use the default setting
+ * @domain_type_supported: check if the specified domain type is supported
* @default_domain_ops: the default ops for domains
* @pgsize_bitmap: bitmap of all possible supported page sizes
* @owner: Driver module providing these ops
@@ -252,6 +253,7 @@ struct iommu_ops {
struct iommu_page_response *msg);
int (*def_domain_type)(struct device *dev);
+ bool (*domain_type_supported)(struct device *dev, int type);
const struct iommu_domain_ops *default_domain_ops;
unsigned long pgsize_bitmap;
--
2.32.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/7] iommu/amd: Enforce IOMMU restrictions for SNP-enabled system
SNP-enabled system requires IOMMU v1 page table to be configured with non-zero DTE[Mode] for DMA-capable devices. This effects a number of usecases such as IOMMU pass-through mode and AMD IOMMUv2 APIs for binding/unbinding pasid. The series introduce a global variable to check SNP-enabled state during driver initialization, and use it to enforce the SNP restrictions during runtime. Also, for non-DMA-capable devices such as IOAPIC, the recommendation is to set DTE[TV] and DTE[Mode] to zero on SNP-enabled system. Therefore, additinal checks is added before setting DTE[TV]. Testing: - Tested booting and verify dmesg. - Tested booting with iommu=pt - Tested loading amd_iommu_v2 driver - Tested changing the iommu domain at runtime - Tested booting SEV/SNP-enabled guest Pre-requisite: - [PATCH v3 00/35] iommu/amd: Add multiple PCI segments support https://lore.kernel.org/linux-iommu/20220511072141.15485-29-vasant.he...@amd.com/T/ Note: - Previously discussed on here: [PATCH v2] iommu/amd: Set translation valid bit only when IO page tables are in used https://www.spinics.net/lists/kernel/msg4351005.html Best Regards, Suravee Brijesh Singh (1): iommu/amd: Introduce function to check SEV-SNP support Suravee Suthikulpanit (6): iommu/amd: Process all IVHDs before enabling IOMMU features iommu/amd: Introduce a global variable for tracking SNP enable status iommu/amd: Set translation valid bit only when IO page tables are in use iommu: Add domain_type_supported() callback in iommu_ops iommu/amd: Do not support IOMMU_DOMAIN_IDENTITY when SNP is enabled iommu/amd: Do not support IOMMUv2 APIs when SNP is enabled drivers/iommu/amd/amd_iommu_types.h | 11 +++ drivers/iommu/amd/init.c| 111 +++- drivers/iommu/amd/iommu.c | 31 +++- drivers/iommu/iommu.c | 13 +++- include/linux/iommu.h | 11 +++ 5 files changed, 153 insertions(+), 24 deletions(-) -- 2.32.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v2] dt-bindings: iommu: renesas,ipmmu-vmsa: R-Car V3U is R-Car Gen4
Hi Geert-san, > From: Geert Uytterhoeven, Sent: Friday, June 10, 2022 7:10 PM > > Despite the name, R-Car V3U is the first member of the R-Car Gen4 > family. Hence move its compatible value to the R-Car Gen4 section. > > Signed-off-by: Geert Uytterhoeven > Acked-by: Krzysztof Kozlowski > Acked-by: Joerg Roedel > Reviewed-by: Wolfram Sang Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/4] dt-bindings: qcom-iommu: Add Qualcomm MSM8953 compatible
Document the compatible used for IOMMU on the msm8953 SoC. Signed-off-by: Luca Weiss --- Changes from v1: - new patch Documentation/devicetree/bindings/iommu/qcom,iommu.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt index 059139abce35..e6cecfd360eb 100644 --- a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt @@ -10,6 +10,7 @@ to non-secure vs secure interrupt line. - compatible : Should be one of: "qcom,msm8916-iommu" +"qcom,msm8953-iommu" Followed by "qcom,msm-iommu-v1". -- 2.36.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/4] MDSS support for MSM8953
This series adds the APPS IOMMU and the MDSS block for display that is found on msm8953 SoCs. Luca Weiss (1): dt-bindings: qcom-iommu: Add Qualcomm MSM8953 compatible Vladimir Lypak (3): arm64: dts: qcom: msm8953: add APPS IOMMU drm/msm/mdp5: Add perf data for MDP v1.16 arm64: dts: qcom: msm8953: add MDSS .../devicetree/bindings/iommu/qcom,iommu.txt | 1 + arch/arm64/boot/dts/qcom/msm8953.dtsi | 244 ++ drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 5 + 3 files changed, 250 insertions(+) -- 2.36.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC PATCH 3/3] iommu/vt-d: Show region type in arch_rmrr_sanity_check()
This patch will attempt to describe the region type in the event
that a given RMRR entry is not within a reserved region.
Signed-off-by: Aaron Tomlin
---
arch/x86/include/asm/iommu.h | 9 ++---
arch/x86/kernel/e820.c | 5 +++--
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h
index bf1ed2ddc74b..d21366644520 100644
--- a/arch/x86/include/asm/iommu.h
+++ b/arch/x86/include/asm/iommu.h
@@ -17,12 +17,15 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory
*rmrr)
{
u64 start = rmrr->base_address;
u64 end = rmrr->end_address + 1;
+ struct e820_entry *entry;
- if (e820__mapped_all(start, end, E820_TYPE_RESERVED))
+ entry = __e820__mapped_all(start, end, 0);
+
+ if (entry && entry->type == E820_TYPE_RESERVED)
return 0;
- pr_err(FW_BUG "No firmware reserved region can cover this RMRR
[%#018Lx-%#018Lx], contact BIOS vendor for fixes\n",
- start, end - 1);
+ pr_err(FW_BUG "No firmware reserved region can cover this RMRR [%s:
%#018Lx-%#018Lx], contact BIOS vendor for fixes\n",
+ e820_type_to_string(entry), start, end - 1);
return -EINVAL;
}
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 95b994cf80cd..165e9a444bb9 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1073,7 +1073,7 @@ void __init e820__finish_early_params(void)
const char *__init e820_type_to_string(struct e820_entry *entry)
{
- switch (entry->type) {
+ switch (entry && entry->type) {
case E820_TYPE_RESERVED_KERN: /* Fall-through: */
case E820_TYPE_RAM: return "System RAM";
case E820_TYPE_ACPI:return "ACPI Tables";
@@ -1083,8 +1083,9 @@ const char *__init e820_type_to_string(struct e820_entry
*entry)
case E820_TYPE_PMEM:return "Persistent Memory";
case E820_TYPE_RESERVED:return "Reserved";
case E820_TYPE_SOFT_RESERVED: return "Soft Reserved";
- default:return "Unknown E820 type";
+ default:break;
}
+ return "Unknown E820 type";
}
static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry)
--
2.34.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC PATCH 1/3] x86/boot/e820: Make __e820__mapped_all() external
No functional change.
This patch allows __e820__mapped_all() to be available for
external use, in preparation to enhance the error message
generated by arch_rmrr_sanity_check().
Signed-off-by: Aaron Tomlin
---
arch/x86/include/asm/e820/api.h | 1 +
arch/x86/kernel/e820.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
index e8f58ddd06d9..bf78daa08897 100644
--- a/arch/x86/include/asm/e820/api.h
+++ b/arch/x86/include/asm/e820/api.h
@@ -13,6 +13,7 @@ extern unsigned long pci_mem_start;
extern bool e820__mapped_raw_any(u64 start, u64 end, enum e820_type type);
extern bool e820__mapped_any(u64 start, u64 end, enum e820_type type);
extern bool e820__mapped_all(u64 start, u64 end, enum e820_type type);
+struct e820_entry *__e820__mapped_all(u64 start, u64 end, enum e820_type type);
extern void e820__range_add (u64 start, u64 size, enum e820_type type);
extern u64 e820__range_update(u64 start, u64 size, enum e820_type old_type,
enum e820_type new_type);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index f267205f2d5a..09b1c863a766 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -109,7 +109,7 @@ EXPORT_SYMBOL_GPL(e820__mapped_any);
* Note: this function only works correctly once the E820 table is sorted and
* not-overlapping (at least for the range specified), which is the case
normally.
*/
-static struct e820_entry *__e820__mapped_all(u64 start, u64 end,
+struct e820_entry *__e820__mapped_all(u64 start, u64 end,
enum e820_type type)
{
int i;
--
2.34.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC PATCH 2/3] x86/boot/e820: Make e820_type_to_string() external
No functional change.
This patch allows e820_type_to_string() to be available for
external use, in preparation to enhance the error message
generated by arch_rmrr_sanity_check().
Signed-off-by: Aaron Tomlin
---
arch/x86/include/asm/e820/api.h | 1 +
arch/x86/kernel/e820.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
index bf78daa08897..ceb301e591de 100644
--- a/arch/x86/include/asm/e820/api.h
+++ b/arch/x86/include/asm/e820/api.h
@@ -43,6 +43,7 @@ extern void e820__reallocate_tables(void);
extern void e820__register_nosave_regions(unsigned long limit_pfn);
extern int e820__get_entry_type(u64 start, u64 end);
+const char *e820_type_to_string(struct e820_entry *entry);
/*
* Returns true iff the specified range [start,end) is completely contained
inside
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 09b1c863a766..95b994cf80cd 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1071,7 +1071,7 @@ void __init e820__finish_early_params(void)
}
}
-static const char *__init e820_type_to_string(struct e820_entry *entry)
+const char *__init e820_type_to_string(struct e820_entry *entry)
{
switch (entry->type) {
case E820_TYPE_RESERVED_KERN: /* Fall-through: */
--
2.34.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
