[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Peng Fan <peng.fan@xxxxxxx>
  • From: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>
  • Date: Wed, 1 Jun 2022 09:13:12 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OM5znaz24psi/QNH8B9NFjCmzETA9Q7J4ovVk/VtDI4=; b=KU03Pdepq0jf6RzCCjnefUolHE5sqKX7x4KCH2qdj/BM39J74iSOGExI1MVkWeABtT5Bm9ampjuYnueGh0XVBeCyfPJiIRi1GVkObFiWL2J3QYlEs9XuV6DX6M6LxFrh/m0nVLzxyrZANeFH9Eci9mfAKU+5y95Q0Cnn2bnWwYWAa0P6Ym9dU/QMvXOd4FpMSgGKcJ+G6zhqaVz9f/18J9ngSZP/Vj9GEma9MWQgFfqSrQnNGp4SIFuqQpxMwGFx2ES+v/8nL+kGw9heoMxCS1bo6MqStwd8oOYOSrlM78uGNufpy3yu7TpwkYOmgbT1+Rg5/yL7NGt/8W+hHXh/ug==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V5Awx9AZjco4DNey7vFy6j9S+rNY38kqGvWH+Mqz32lERtpzMHp0y1fDxAFOGnnAup+6G83kHn198iqcjALd4jqSGa7Aw3LEpIxt8ZUmyt0thHPdKsru7PWwSeEiDEwC+ZXBLk3KhqvkXuXD1Yl+zP05xDNvBWzP5z/FjufRkLAaUWT1kpGMx3pPUkYzjD0Iew36PxB4iU6mxcce1ijG8kyUexlyiqSWzik57NBG68PfViRrVcHXxwri/LRYX/DI7BohDUQ8ZcYd0SBhb9XCqnsjaCJvBaYgcQN+MEHqteF4wyWkfPCueoeErGhlhaA6JoKneeOxFEcqUe23UoYpCg==
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
  • Delivery-date: Wed, 01 Jun 2022 09:13:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYdDjfc3Z/1SeAUE+eDUzXC1OEPa06Mh/QgAAVEIA=
  • Thread-topic: [Xen-devel] SMMU permission fault on Dom0 when init vpu_decoder

On Wed, Jun 01, 2022 at 07:59:23AM +0000, Peng Fan wrote:
> > 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fsource.c__;JSUl!!GF_29dbcQIUBPA!wzoDdJsuf4bjXMe85tA46E0tLpFG5gqHoo-OeY6o_ARroNBmX7JByHW67qEUik7bNow0STgvAjR4rBkRu2Ux$
> >  [eur01[.]safelinks[.]protection[.]outlook[.]com]
> > 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.

I would say that SMMU is not neccessary for Dom0 because it's mapped
1:1. But using device under SMMU in Dom0 is still valid case. For
example to protect device from reaching address, assigned to another
domain, since Dom0 is trusted.

> 
> > 
> > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>
> > ---
> >  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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.