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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A96D9C433F5 for ; Thu, 6 Jan 2022 18:32:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242910AbiAFSc3 (ORCPT ); Thu, 6 Jan 2022 13:32:29 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:34342 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242799AbiAFSc2 (ORCPT ); Thu, 6 Jan 2022 13:32:28 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2C008B8230F; Thu, 6 Jan 2022 18:32:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93DE9C36AE3; Thu, 6 Jan 2022 18:32:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641493946; bh=5lY+HI8ihg/c9/B+VNUfvaxm/xosjyotG49pQ10u82w=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=XirhBewNwMlp7K0TCeGeOUGw2hgP2JEu1cZv3AQV10PBvw4ZYBsmz1pS++baJq9Jo Ww61H9RCyVHw3Jrl2sXCb1ZpBTdnroTskdtVAeNshmtbcDd7nlb/0XYkyhoR5QrKVJ ZwBCnVA7Kpd/0ysferdN+9JZ9Q1XD6YGR43u+rzEXz6f+yzhZDs5aMEwxyE7Uobcf/ N/UZzPr5bseDS1LN3Kzfaebpd8kC2ZQ3iw5nipIQOwDwjWO1el3C8Y4IX+ur6mWwCM s8UxZTMQAIYCBcEiAOVMEn7Hz32j1uXUqSo0YisNm9Ieomh0FRj7R7dgkX6s231e08 Y/edU4bUVxa2w== Date: Thu, 6 Jan 2022 12:32:24 -0600 From: Bjorn Helgaas To: Lu Baolu Cc: Greg Kroah-Hartman , Joerg Roedel , Alex Williamson , Bjorn Helgaas , Jason Gunthorpe , Christoph Hellwig , Kevin Tian , Ashok Raj , Will Deacon , Robin Murphy , Dan Williams , rafael@kernel.org, Diana Craciun , Cornelia Huck , Eric Auger , Liu Yi L , Jacob jun Pan , Chaitanya Kulkarni , Stuart Yoder , Laurentiu Tudor , Thierry Reding , David Airlie , Daniel Vetter , Jonathan Hunter , Li Yang , Dmitry Osipenko , iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 09/14] PCI: portdrv: Suppress kernel DMA ownership auto-claiming Message-ID: <20220106183224.GA298861@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039bbcf3-ccc6-f3b0-172e-9caa0866bb9e@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 06, 2022 at 12:12:35PM +0800, Lu Baolu wrote: > On 1/5/22 1:06 AM, Bjorn Helgaas wrote: > > On Tue, Jan 04, 2022 at 09:56:39AM +0800, Lu Baolu wrote: > > > If a switch lacks ACS P2P Request Redirect, a device below the switch can > > > bypass the IOMMU and DMA directly to other devices below the switch, so > > > all the downstream devices must be in the same IOMMU group as the switch > > > itself. > > Help me think through what's going on here. IIUC, we put devices in > > the same IOMMU group when they can interfere with each other in any > > way (DMA, config access, etc). > > > > (We said "DMA" above, but I guess this would also apply to config > > requests, right?) > > I am not sure whether devices could interfere each other through config > space access. The IOMMU hardware only protects and isolates DMA > accesses, so that userspace could control DMA directly. The config > accesses will always be intercepted by VFIO. Hence, I don't see a > problem. I was wondering about config accesses generated by an endpoint, e.g., an endpoint doing config writes to a peer or the upstream bridge. But I think that is prohibited by spec - PCIe r5.0, sec 7.3.3, says "Propagation of Configuration Requests from Downstream to Upstream as well as peer-to-peer are not supported" and "Configuration Requests are initiated only by the Host Bridge, including those passed through the SFI CAM mechanism." Bjorn