On Thu, Aug 17, 2023 at 4:03 PM Yong Wu (吴勇) <Yong.Wu@xxxxxxxxxxxx> wrote:
>
> On Mon, 2023-08-14 at 16:21 +0800, Chen-Yu Tsai wrote:
> >
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> > On Mon, Aug 14, 2023 at 3:14 PM Yong Wu (吴勇) <Yong.Wu@xxxxxxxxxxxx>
> > wrote:
> > >
> > > On Fri, 2023-08-11 at 11:30 +0800, Chen-Yu Tsai wrote:
> > > >
> > > > External email : Please do not click links or open attachments
> > until
> > > > you have verified the sender or the content.
> > > > On Thu, Aug 10, 2023 at 8:23 PM Yong Wu (吴勇) <
> > Yong.Wu@xxxxxxxxxxxx>
> > > > wrote:
> > > > >
> > > > > On Tue, 2023-08-08 at 17:53 +0800, Chen-Yu Tsai wrote:
> > > > > >
> > > > > > External email : Please do not click links or open
> > attachments
> > > > until
> > > > > > you have verified the sender or the content.
> > > > > > On Fri, Jun 2, 2023 at 5:04 PM Yong Wu <yong.wu@xxxxxxxxxxxx
> > >
> > > > wrote:
> > > > > > >
> > > > > > > From: "Chengci.Xu" <chengci.xu@xxxxxxxxxxxx>
> > > > > > >
> > > > > > > MT8188 has 3 IOMMU, containing 2 MM IOMMUs, one is for vdo,
> > the
> > > > > > other
> > > > > > > is for vpp. and 1 INFRA IOMMU.
> > > > > > >
> > > > > > > Signed-off-by: Chengci.Xu <chengci.xu@xxxxxxxxxxxx>
> > > > > > > Signed-off-by: Yong Wu <yong.wu@xxxxxxxxxxxx>
> > > > > > > Reviewed-by: AngeloGioacchino Del Regno <
> > > > > > angelogioacchino.delregno@xxxxxxxxxxxxx>
> > > > > > > ---
> > > > > > > drivers/iommu/mtk_iommu.c | 49
> > > > > > +++++++++++++++++++++++++++++++++++++++
> > > > > > > 1 file changed, 49 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/iommu/mtk_iommu.c
> > > > b/drivers/iommu/mtk_iommu.c
> > > > > > > index 9c89cf894a4d..5c66af0c45a8 100644
> > > > > > > --- a/drivers/iommu/mtk_iommu.c
> > > > > > > +++ b/drivers/iommu/mtk_iommu.c
> > > > > > > @@ -170,6 +170,7 @@ enum mtk_iommu_plat {
> > > > > > > M4U_MT8173,
> > > > > > > M4U_MT8183,
> > > > > > > M4U_MT8186,
> > > > > > > + M4U_MT8188,
> > > > > > > M4U_MT8192,
> > > > > > > M4U_MT8195,
> > > > > > > M4U_MT8365,
> > > > > > > @@ -1593,6 +1594,51 @@ static const struct
> > mtk_iommu_plat_data
> > > > > > mt8186_data_mm = {
> > > > > > > .iova_region_larb_msk = mt8186_larb_region_msk,
> > > > > > > };
> > > > > > >
> > > > > > > +static const struct mtk_iommu_plat_data mt8188_data_infra
> > = {
> > > > > > > + .m4u_plat = M4U_MT8188,
> > > > > > > + .flags = WR_THROT_EN | DCM_DISABLE |
> > > > > > STD_AXI_MODE | PM_CLK_AO |
> > > > > > > + MTK_IOMMU_TYPE_INFRA |
> > > > > > IFA_IOMMU_PCIE_SUPPORT |
> > > > > > > + PGTABLE_PA_35_EN |
> > > > > > CFG_IFA_MASTER_IN_ATF,
> > > > > >
> > > > > > FWIW, CFG_IFA_MASTER_IN_ATF should not be tied to the
> > compatible
> > > > > > string,
> > > > > > but set via a DT property. The IOMMU controls are secured by
> > > > > > firmware.
> > > > > > It is not a property intrinsically tied to the hardware.
> > > > >
> > > > > The flag CFG_IFA_MASTER_IN_ATF means the registers which
> > > > enable/disable
> > > > > iommu are in the secure world. If the master like pcie want to
> > > > enable
> > > > > iommu, we have to enter secure world to configure it. It should
> > be
> > > > HW
> > > > > intrinsical, right?
> > > >
> > > > If I understand correctly, this is forced by setting some
> > registers.
> > > > The registers are set by the firmware at boot time.
> > >
> > > The register will be set before the masters that have the "iommus="
> > > property probe. If the master doesn't have "iommus=" property in
> > its
> > > dtsi node, this register won't be set, then its iommu will be
> > disabled
> > > and it has to access continuous buffer.
> > >
> > > >
> > > > So if a different firmware that doesn't set the registers is
> > used,
> > > > then the IOMMU is available to non-secure kernel, correct?
> > >
> > > No. The meaning of this register is whether to enable iommu. If the
> > > register are not set, the IOMMU for that master is disabled.
> >
> > For clarity, I'm referring to PERI_MST_PROT [1], not the registers in
> > the
> > IOMMU or LARBs. So not any of the registers used in this patch.
> >
> > If that register doesn't restrict access to IOMMU register space to
> > secure
> > only, then I assume it is controlled by fuses?
>
> Thanks for the clarification. Understand this now. If that register
> doesn't restrict this, the register for enabling the iommu could be
> accessed in normal world.
>
> > [1]
> > https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/be457248c6b0a7f3c61bd95af58372938d13decd/plat/mediatek/drivers/iommu/mt8188/mtk_iommu_plat.c#93
> >
> > > >
> > > > That's why I said that it should not be tied to a particular
> > hardware
> > > > platform, but set using a boolean device tree property.
> > > >
> > > > > >
> > > > > > If on some other project there is no such security
> > requirement
> > > > and
> > > > > > the
> > > > > > IOMMU is opened up to non-secure world, and ATF not even
> > having
> > > > > > support
> > > > > > for the SMC call, this becomes unusable and hard to rectify
> > > > without
> > > > > > introducing a new compatible string.
>
> Then this make sense. Sorry, I don't know if such project exist, I
> guess no, right? we could add it when necessary?
I guess that works. It would be a negative property, such as
"mediatek,iommu-is-non-secure". However, since this lock down is orthogonal
to the SoC model, it would be better to model it as such from the beginning.
ChenYu
