From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A7E1C433B4 for ; Mon, 10 May 2021 08:41:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DE4C06143B for ; Mon, 10 May 2021 08:41:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230153AbhEJImF (ORCPT ); Mon, 10 May 2021 04:42:05 -0400 Received: from verein.lst.de ([213.95.11.211]:57650 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230029AbhEJImE (ORCPT ); Mon, 10 May 2021 04:42:04 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 4D61467373; Mon, 10 May 2021 10:40:57 +0200 (CEST) Date: Mon, 10 May 2021 10:40:57 +0200 From: Christoph Hellwig To: Julien Grall Cc: f.fainelli@gmail.com, Stefano Stabellini , "xen-devel@lists.xenproject.org" , linux-kernel@vger.kernel.org, osstest service owner , hch@lst.de, Konrad Rzeszutek Wilk , Boris Ostrovsky , iommu@lists.linux-foundation.org Subject: Re: Regression when booting 5.15 as dom0 on arm64 (WAS: Re: [linux-linus test] 161829: regressions - FAIL) Message-ID: <20210510084057.GA933@lst.de> References: <4ea1e89f-a7a0-7664-470c-b3cf773a1031@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ea1e89f-a7a0-7664-470c-b3cf773a1031@xen.org> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote: > The pointer dereferenced seems to suggest that the swiotlb hasn't been > allocated. From what I can tell, this may be because swiotlb_force is set > to SWIOTLB_NO_FORCE, we will still enable the swiotlb when running on top > of Xen. > > I am not entirely sure what would be the correct fix. Any opinions? Can you try something like the patch below (not even compile tested, but the intent should be obvious? diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 16a2b2b1c54d..7671bc153fb1 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -44,6 +44,8 @@ #include #include +#include + /* * We need to be able to catch inadvertent references to memstart_addr * that occur (potentially in generic code) before arm64_memblock_init() @@ -482,7 +484,7 @@ void __init mem_init(void) if (swiotlb_force == SWIOTLB_FORCE || max_pfn > PFN_DOWN(arm64_dma_phys_limit)) swiotlb_init(1); - else + else if (!IS_ENABLED(CONFIG_XEN) || !xen_swiotlb_detect()) swiotlb_force = SWIOTLB_NO_FORCE; set_max_mapnr(max_pfn - PHYS_PFN_OFFSET);