SMMU permission fault on Dom0 when init vpu_decoder

[Xen-devel] SMMU permission fault on Dom0 when init vpu_decoder

Posted by Oleksii Moisieiev 1 year, 11 months ago

Hello,

I'm getting permission fault from SMMU when trying to init VPU_Encoder/Decoder
in Dom0 on IMX8QM board:
(XEN) smmu: /iommu@51400000: Unhandled context fault: fsr=0x408, iova=0x86000a60, fsynr=0x1c0062, cb=0
This error appears when vpu_encoder/decoder tries to memcpy firmware image to
0x86000000 address, which is defined in reserved-memory node in xen device-tree
as encoder_boot/decoder_boot region.

I'm using xen from branch xen-project/staging-4.16 + imx related patches, which were
taken from https://source.codeaurora.org/external/imx/imx-xen.

After some investigation I found that this issue was fixed by Peng Fan in
commit: 46b3dd3718144ca6ac2c12a3b106e57fb7156554 (Hash from codeaurora), but only for
the Guest domains.
It introduces new p2m_type p2m_mmio_direct_nc_x, which differs from
p2m_mmio_direct_nc by XN = 0. This type is set to the reserved memory region in
map_mmio_regions function.

I was able to fix issue in Dom0 by setting p2m_mmio_direct_nc_x type for the
reserved memory in map_regions_p2mt, which is used to map memory during Dom0 creation.
Patch can be found below.

Based on initial discussions on IRC channel - XN bit did the trick because looks
like vpu decoder is executing some code from this memory.

The purpose of this email is to discuss this issue and probably produce generic
solution for it.

Best regards,
Oleksii.

---
arm: Set p2m_type to p2m_mmio_direct_nc_x for reserved memory
regions

This is the enhancement of the 46b3dd3718144ca6ac2c12a3b106e57fb7156554.
Those patch introduces p2m_mmio_direct_nc_x p2m type which sets the
e->p2m.xn = 0 for the reserved-memory, such as vpu encoder/decoder.

Set p2m_mmio_direct_nc_x in map_regions_p2mt for reserved-memory the
same way it does in map_mmio_regions. This change is for the case
when vpu encoder/decoder works in DomO and not passed-through to the
Guest Domains.

Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
---
 xen/arch/arm/p2m.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index e9568dab88..bb1f681b71 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1333,6 +1333,13 @@ int map_regions_p2mt(struct domain *d,
                      mfn_t mfn,
                      p2m_type_t p2mt)
 {
+    if (((long)gfn_x(gfn) >= (GUEST_RAM0_BASE >> PAGE_SHIFT)) &&
+        (((long)gfn_x(gfn) + nr) <=
+        ((GUEST_RAM0_BASE + GUEST_RAM0_SIZE)>> PAGE_SHIFT)))
+    {
+        p2m_remove_mapping(d, gfn, nr, mfn);
+        return p2m_insert_mapping(d, gfn, nr, mfn, p2m_mmio_direct_nc_x);
+    }
     return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);
 }
 
-- 
2.27.0

RE: [Xen-devel] SMMU permission fault on Dom0 when init vpu_decoder

Posted by Peng Fan 1 year, 11 months ago

> Subject: [Xen-devel] SMMU permission fault on Dom0 when init vpu_decoder
> 
> Hello,
> 
> I'm getting permission fault from SMMU when trying to init
> VPU_Encoder/Decoder in Dom0 on IMX8QM board:
> (XEN) smmu: /iommu@51400000: Unhandled context fault: fsr=0x408,
> iova=0x86000a60, fsynr=0x1c0062, cb=0 This error appears when
> vpu_encoder/decoder tries to memcpy firmware image to
> 0x86000000 address, which is defined in reserved-memory node in xen
> device-tree as encoder_boot/decoder_boot region.
> 
> I'm using xen from branch xen-project/staging-4.16 + imx related patches,
> which were taken from
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.c
> odeaurora.org%2Fexternal%2Fimx%2Fimx-xen&amp;data=05%7C01%7Cpeng.f
> an%40nxp.com%7C91e3a953942d414dcc6208da425006e7%7C686ea1d3bc2b
> 4c6fa92cd99c5c301635%7C0%7C0%7C637895208732114203%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=no%2BV2ubjGmrsm96NP
> ybeeug4a3BXx3oX7xmylzZCU8E%3D&amp;reserved=0.
> 
> After some investigation I found that this issue was fixed by Peng Fan in
> commit: 46b3dd3718144ca6ac2c12a3b106e57fb7156554 (Hash from
> codeaurora), but only for the Guest domains.
> It introduces new p2m_type p2m_mmio_direct_nc_x, which differs from
> p2m_mmio_direct_nc by XN = 0. This type is set to the reserved memory region
> in map_mmio_regions function.
> 
> I was able to fix issue in Dom0 by setting p2m_mmio_direct_nc_x type for the
> reserved memory in map_regions_p2mt, which is used to map memory during
> Dom0 creation.
> Patch can be found below.
> 
> Based on initial discussions on IRC channel - XN bit did the trick because looks
> like vpu decoder is executing some code from this memory.
> 
> The purpose of this email is to discuss this issue and probably produce generic
> solution for it.
> 
> Best regards,
> Oleksii.
> 
> ---
> arm: Set p2m_type to p2m_mmio_direct_nc_x for reserved memory regions
> 
> This is the enhancement of the
> 46b3dd3718144ca6ac2c12a3b106e57fb7156554.
> Those patch introduces p2m_mmio_direct_nc_x p2m type which sets the
> e->p2m.xn = 0 for the reserved-memory, such as vpu encoder/decoder.
> 
> Set p2m_mmio_direct_nc_x in map_regions_p2mt for reserved-memory the
> same way it does in map_mmio_regions. This change is for the case when vpu
> encoder/decoder works in DomO and not passed-through to the Guest
> Domains.

For Dom0, there is no SMMU, so no need x. Just nc is enough.

Regards,
Peng.

> 
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> ---
>  xen/arch/arm/p2m.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index
> e9568dab88..bb1f681b71 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1333,6 +1333,13 @@ int map_regions_p2mt(struct domain *d,
>                       mfn_t mfn,
>                       p2m_type_t p2mt)
>  {
> +    if (((long)gfn_x(gfn) >= (GUEST_RAM0_BASE >> PAGE_SHIFT)) &&
> +        (((long)gfn_x(gfn) + nr) <=
> +        ((GUEST_RAM0_BASE + GUEST_RAM0_SIZE)>> PAGE_SHIFT)))
> +    {
> +        p2m_remove_mapping(d, gfn, nr, mfn);
> +        return p2m_insert_mapping(d, gfn, nr, mfn,
> p2m_mmio_direct_nc_x);
> +    }
>      return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);  }
> 
> --
> 2.27.0