Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4274947pxf; Tue, 16 Mar 2021 09:29:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmv2+ofuPzGq1Y1XS4OsF1f3QomIWUrxU5mVBiaVmaJ65r+Rf5lBBMEowRPCABP+jg/QG5 X-Received: by 2002:aa7:d98b:: with SMTP id u11mr37894138eds.352.1615912163889; Tue, 16 Mar 2021 09:29:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615912163; cv=none; d=google.com; s=arc-20160816; b=R3UUUDU6QUVBkL/tGMswjxIBUh9Bz35ztW+v7b2QMQWY+AaGZhpEwBDtKpYla6MEEa a94gsyfX6BfK6pelnSH185ZBd8YGKl2ZCLh2/SbZara7WC9kY0XNhqKNbKFzJrtpCs/c UEBl0gotxU8dLkKf7eoThI14e16z/Kw1tTUqkVVjX4G3n0rbMl187qWDfeR/Qgp1u/j6 KC6nYdOPSH94oYkrqHI0tBU1Oji1llG1HEhALkuVPXX6cciohBohgeq2cCB7tICFPPi+ OO3Or5JZwA0Pjr2ztjPwLiq/YTwPindUZ2STpiZuv+q50OhsbemUQiD0FZSn+cYn0W0y LZaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=nn6ZIeayCYdQJM10popUqbGZpIQQdeN/8MeAwmFE5UQ=; b=GMdKfm4OuESHZfnOuLU2/Hk1jSgvY0aIcDPxVubYfgrbEGJpl+Rwz3SosrQk0cbCe7 uh3C8IKnLeBuz1IIVahQHg97rar+e5cGUYTl1ph6vL3Fmty5A5AwGw6kiQtkriYfEE2o xlQ+AiVpcuVFtHjtUaHXAl9a/CR2+WseGp67LjdMAbi/EqtjPFMNdKMsA2qQEFDRusI3 b2Lme0BnsipaCww94yoTfk74WQ20sE3VucmJluQ0dqbeFQ7/3NikB35DqKCcehUcD1hb ZNZaYyD3c/P+5bapJg2ViT4LAJLm+d5mo1YX2Y0ntZyZgubYPc2y4jDR86k27mSCKmQT IGwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw1si15017610edb.412.2021.03.16.09.29.00; Tue, 16 Mar 2021 09:29:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233000AbhCPPA4 (ORCPT + 99 others); Tue, 16 Mar 2021 11:00:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:47942 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229944AbhCPPA3 (ORCPT ); Tue, 16 Mar 2021 11:00:29 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9D5C5AC24; Tue, 16 Mar 2021 15:00:28 +0000 (UTC) Date: Tue, 16 Mar 2021 16:00:26 +0100 From: Joerg Roedel To: Huang Rui Cc: "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , Joerg Roedel , "Suthikulpanit, Suravee" , "Deucher, Alexander" , "Du, Xiaojian" , "stable@vger.kernel.org" Subject: Re: [PATCH] iommu/amd: Fix iommu remap panic while amd_iommu is set to disable Message-ID: References: <20210311142807.705080-1-ray.huang@amd.com> <20210316133602.GB2497230@hr-amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210316133602.GB2497230@hr-amd> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 16, 2021 at 09:36:02PM +0800, Huang Rui wrote: > Thanks for the comments. Could you please elaborate this? > > Do you mean while amd_iommu=off, we won't prepare the IVRS, and even > needn't get all ACPI talbes. Because they are never be used and the next > state will always goes into IOMMU_CMDLINE_DISABLED, am I right? The first problem was that amd_iommu_irq_remap is never set back to false when irq-remapping initialization fails in amd_iommu_prepare(). But there are other problems, like that even when the IOMMU is set to disabled on the command line with amd_iommu=off, the code still sets up all IOMMUs and registers IRQ domains for them. Later the code checks wheter the IOMMU should stay disabled and tears everything down, except for the IRQ domains, which stay in the global list. The APIs do not really support tearing down IRQ domains well, so its not so easy to add this to the tear-down path. Now that the IRQ domains stay in the list, the ACPI code will come along later and calls the ->select() call-back for every IRQ domain, which gets execution to irq_remapping_select(), depite IOMMU being disabled and amd_iommu_rlookup_table already de-allocated. But since amd_iommu_irq_remap is still true the NULL pointer is dereferenced, causing the crash. When the IRQ domains would not be around, this would also not happen. So my patches also change the initializtion to not do all the setup work when amd_iommu=off was passed on the command line. Regards, Joerg