[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: Julien Grall <julien@xxxxxxx>
  • From: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>
  • Date: Wed, 1 Jun 2022 09:04:35 +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=FJGi0jDrsdDVUTUEv+r1p4LlW3UjXyOGb5PcbVcR0pw=; b=PZSI866UMfDLuy7DQSZgZMOKpLcsXBpYaW6qFpVGUyG7IqQkAesX+kdunrPP7I6b+SDewKl7lkfVMH3MaP9qA/SdKOU3NwLv6lRXtPA/4KBUK7+mqbX+9yyDVDmWRA4Z/tPJhxPIxs7ordZIBwqAwVEqY5NJXqS8km8GZuzMSggcUaMlCQ+++PKRfDkgWjUKLOSks8APy1Ly+Rpqx/oBL1gJSYh/DHrJ0F7TYmTtsqryEfPDfNEE7RNMWyei5+9aAfKRqHv0KsATpqUTA16jM6+FQaD1MFPSXDeXEOQCEfJ/jYdJpTX6D6r5avvKerw+AmpYW3bzNvmr4bt1lDgOXA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TmsHQLJO7V2Svpj9+yx/nFs1XzrUQ6D5egy+K+2Py4H67PcfIisVHOe7OSdqONjLYMhMGDx7bYCYdrj4KmB06gPIFv+QcsyLSYBUDIBOVHRfDIAQV4OO0RnlyBEVLpBtD/yn1kmcspztdqe/1wrADEMyAbh7yH08psoJ/2qbE3RiVSrNRSlivXs/zYs2EtUnSd6fwbcaF3xsppWSioAw9cqLuqZPJJJYFGqKZszFY9i+XFI4lWoBkdThYjDM3Ngw/o9YTewe5p5W1b/8LHGo5HVgsr4tQYYOvd5gcC1IvebcxZ+gZvH1vv6GqZyodSe9eOcU32Ilx2skpGmQr4No8w==
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Peng Fan <peng.fan@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 01 Jun 2022 09:04:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYdDjfc3Z/1SeAUE+eDUzXC1OEPa03j+IAgAK05QA=
  • Thread-topic: [Xen-devel] SMMU permission fault on Dom0 when init vpu_decoder

On Mon, May 30, 2022 at 04:44:36PM +0100, Julien Grall wrote:
Hi Julien,

> (+ Stefano)
> 
> On 30/05/2022 16:21, Oleksii Moisieiev wrote:
> > Hello,
> 
> Hi Oleksii,
> 
> > 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.
> 
> It is not clear to me who is executing the memcpy(). Is it the device or
> your domain? If the former, where was the instruction fetch from?
> 
> The reason I am asking that is, from what you wrote, mempcy() will write to
> 0x86000000. So the write should not result to a instruction abort. Only an
> instruction fetch would lead to such abort.

My configuration is the following: 
In Dom0 I have vpu_decoder, operated by vpu_malone driver.
During initialization, in function vpu_firmware_download it requests
firmware and put it to decoder_boot memory using memcpy. Then waiting
for the interrupt from the device. Looks like, device decoder tries to
execute something from this memory.

> 
> > 
> > I'm using xen from branch xen-project/staging-4.16 + imx related patches, 
> > which were
> > taken from 
> > https://urldefense.com/v3/__https://source.codeaurora.org/external/imx/imx-xen__;!!GF_29dbcQIUBPA!xy4tOkXLiMzvC0wg_Me93zTZ4sZBZ7dq_-zkwYSaJvqt5vNVEOa-mV7Li2crSK3OBTQFb396tUDElwtpiw$
> >  [source[.]codeaurora[.]org].
> > 
> > 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.
> 
> This was a surprise to me that device could also execute memory. From the
> SMMU spec, this looks a legit things. Before relaxing the type, I would like
> to confirm this is what's happenning in your case.
> 
> [...]
> 
> > ---
> > 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@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)))
> 
> I am afraid I don't understand what this check is for. In a normal setup, we
> don't know where the reserved regions are mapped. Only the caller may know
> that.
> 
> For dom0, this decision could be taken in map_range_to_domain(). For the
> domU, we would need to let the toolstack to chose the memory attribute.
> Stefano attempted to do that a few years ago (see [1]). Maybe we should
> revive it?
> 
> > +    {
> > +        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);
> >   }
> 
> Cheers,
> 
> [1] 
> https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/alpine.DEB.2.10.1902261501020.20689@sstabellini-ThinkPad-X260/__;!!GF_29dbcQIUBPA!xy4tOkXLiMzvC0wg_Me93zTZ4sZBZ7dq_-zkwYSaJvqt5vNVEOa-mV7Li2crSK3OBTQFb396tUBARsu3hw$
> [lore[.]kernel[.]org]
> 
> -- 
> Julien Gral


 


Rackspace

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