From patchwork Wed Mar 9 03:08:08 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quan Xu X-Patchwork-Id: 8541781 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8BDE79F8A8 for ; Wed, 9 Mar 2016 03:14:12 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A659920218 for ; Wed, 9 Mar 2016 03:14:11 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9BE7620204 for ; Wed, 9 Mar 2016 03:14:10 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xen.org with esmtp (Exim 4.84) (envelope-from ) id 1adUWX-0000Ke-Mp; Wed, 09 Mar 2016 03:10:57 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.84) (envelope-from ) id 1adUWW-0000KY-S9 for xen-devel@lists.xen.org; Wed, 09 Mar 2016 03:10:56 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id DF/1E-02901-0449FD65; Wed, 09 Mar 2016 03:10:56 +0000 X-Env-Sender: quan.xu@intel.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1457493054!21205108!1 X-Originating-IP: [192.55.52.88] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDM3NDcyNQ==\n X-StarScan-Received: X-StarScan-Version: 8.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15334 invoked from network); 9 Mar 2016 03:10:55 -0000 Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by server-11.tower-27.messagelabs.com with SMTP; 9 Mar 2016 03:10:55 -0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 08 Mar 2016 19:10:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,559,1449561600"; d="scan'208";a="929838403" Received: from xen-commits.sh.intel.com ([10.239.82.178]) by orsmga002.jf.intel.com with ESMTP; 08 Mar 2016 19:10:29 -0800 From: Quan Xu To: xen-devel@lists.xen.org Date: Wed, 9 Mar 2016 11:08:08 +0800 Message-Id: <1457492889-36625-2-git-send-email-quan.xu@intel.com> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: <1457492889-36625-1-git-send-email-quan.xu@intel.com> References: <1457492889-36625-1-git-send-email-quan.xu@intel.com> Cc: Dario Faggioli , Jan Beulich , Suravee Suthikulpanit , Quan Xu Subject: [Xen-devel] [PATCH v2 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When iommu_setup() is called in __start_xen(), interrupts have already been enabled, and nothing disables (without reenabling) them again in the path that leads to calling set_iommu_interrupt_handler(). There's therefore no risk of them being disabled and needing remaining so, and hence no need for saving and restoring the flags. This means that, even if interrupt would need to be disabled when taking pcidevs_lock, spin_lock_irq() and spin_unlock_irq() could be used. Inside set_iommu_interrupt_handler(), pcidevs_lock serializes calls to pci_get_pdev(), which does not require interrupts to be disabled during its execution. In fact, pcidevs_lock is always (except for this case) taken without disabling interrupts, and disabling them in this case would make the BUG_ON() in check_lock() trigger, if it wasn't for the fact that spinlock debugging checks are still disabled, during initialization, when iommu_setup() (which then end up calling set_iommu_interrupt_handler()) is called. In order to fix this, we can use just plain spin_lock() and spin_unlock(), instead of spin_lock_irqsave() and spin_unlock_irqrestore(). Signed-off-by: Quan Xu Reviewed-by: Dario Faggioli CC: Suravee Suthikulpanit CC: Dario Faggioli CC: Jan Beulich --- xen/drivers/passthrough/amd/iommu_init.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/drivers/passthrough/amd/iommu_init.c b/xen/drivers/passthrough/amd/iommu_init.c index d90a2d2..a400497 100644 --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -778,7 +778,6 @@ static bool_t __init set_iommu_interrupt_handler(struct amd_iommu *iommu) { int irq, ret; hw_irq_controller *handler; - unsigned long flags; u16 control; irq = create_irq(NUMA_NO_NODE); @@ -788,10 +787,10 @@ static bool_t __init set_iommu_interrupt_handler(struct amd_iommu *iommu) return 0; } - spin_lock_irqsave(&pcidevs_lock, flags); + spin_lock(&pcidevs_lock); iommu->msi.dev = pci_get_pdev(iommu->seg, PCI_BUS(iommu->bdf), PCI_DEVFN2(iommu->bdf)); - spin_unlock_irqrestore(&pcidevs_lock, flags); + spin_unlock(&pcidevs_lock); if ( !iommu->msi.dev ) { AMD_IOMMU_DEBUG("IOMMU: no pdev for %04x:%02x:%02x.%u\n",