Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp1610660ybb; Fri, 29 Mar 2019 07:53:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqy7DiUWNI+Du4zIDNUNl90GbykhBFcwnxNhGKtoOs+gMrF1iGdFuO4uK08xrVFOhG9Skh9P X-Received: by 2002:a63:3185:: with SMTP id x127mr45883961pgx.299.1553871208059; Fri, 29 Mar 2019 07:53:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553871208; cv=none; d=google.com; s=arc-20160816; b=UM1y82AcUMvAv4i4Q8p33flGL1hFsCsuOkAEukDXlcEtnfNFpwGafmF1V2471lfubQ 4DS0U0z/ZXT0CSTG/hIAwEQFhHfp1Sk28ME2PtvVPsRLIBrMb2YX8AMYYtcrZGXhgpkR vhWvylKpHM6pCye3REj+QLwfJSfqdyFoDiLo/4awDNqE262Nf9T1Bnj7vpN1M1ed++7l fal3vkXcK8jEo0QqG/58sSDClp/A9BLxmWAVJKvi7X/H62zWsPBTMTy8oyuWESoKp26/ GxxchuAFk2kHlcQ98LfjPVg9y5PUoj47UilLY8MIB/eNC2EWOBMHyd8hGmzFhXNIFn0d 3Ytg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=2sPOX8+9C9w1Vqs/yRFpGBBGww2PL7N6WBAb6xshcGk=; b=ab9dzUC4i98BMlh5xrMuuV9JCwBfMScDGcC0tZGeT28yEmJ6QSbipaSzWsReBeUUt8 6J05KP2AevRcFioa+SA9Os2sBlA9BpPB48VnHr699dh7vfBISwaynW9LRbrk+2uksBm2 ld7okzKfagmaDUy2MwNp8GDVIl+qMomQIiHAB+aFEZhm29sKVDQx+5S+YwO/kciH1s1s n7KWwTLHWJ41b15E1wJnaa5nAnFDfiq92BX4f/xjoeR4NBfCgnq2T+f4Vfei84jXYcA1 KaqTVW+Zo0WQfrJGkIqlBFQk5HHXz3P3zZUzXm7rEaJiCFwe40UM9VmExKO41KxFfq1X epPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q9si2017926pgq.173.2019.03.29.07.53.11; Fri, 29 Mar 2019 07:53:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729688AbfC2OvE (ORCPT + 99 others); Fri, 29 Mar 2019 10:51:04 -0400 Received: from 8bytes.org ([81.169.241.247]:59760 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729670AbfC2OvD (ORCPT ); Fri, 29 Mar 2019 10:51:03 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id A7DB7303; Fri, 29 Mar 2019 15:51:01 +0100 (CET) Date: Fri, 29 Mar 2019 15:51:01 +0100 From: Joerg Roedel To: Gary R Hook Cc: "iommu@lists.linux-foundation.org" , Joerg Roedel , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] iommu/amd: Reserve exclusion range in iova-domain Message-ID: <20190329145101.GA27670@8bytes.org> References: <20190328104459.18589-1-joro@8bytes.org> <3850c381-30d6-b2a3-d976-66939d8e612a@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3850c381-30d6-b2a3-d976-66939d8e612a@amd.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Gary, On Thu, Mar 28, 2019 at 02:52:19PM +0000, Gary R Hook wrote: > On 3/28/19 5:44 AM, Joerg Roedel wrote: > > + if (entry->prot & (1 << 2)) > > Could we add #define IOMMU_WRITE_EXCL (1 << 2) to amd_iommu_types.h? Yes, I replace that magic number with a descriptive name. > The problem I see here is that if, for some untold reason, there is more > than one exclusion range emitted, where only the last one wins in the > hardware, we'd still end up with more than one range reserved in the > IOVA tree. Clearly, this is extremely unlikely, but wouldn't we want to > protect against that sort of misuse/mistake? > > I could be missing something. No, you are not, this could still be a problem. Until now it isn't, because this week was the first time I have every seen an AMD IOMMU system making use of exclusion ranges, and it doesn't have this problem. But this problem has been in the code even before this patch and needs to be addressed separatly. I think it is the best option to cancel IOMMU initialization when the IVRS table defines conflicting exclusion ranges for a single IOMMU instance. Regards, Joerg