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 6AB8BC433FE for ; Thu, 30 Dec 2021 05:35:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236283AbhL3FfM (ORCPT ); Thu, 30 Dec 2021 00:35:12 -0500 Received: from mga02.intel.com ([134.134.136.20]:60427 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229478AbhL3FfL (ORCPT ); Thu, 30 Dec 2021 00:35:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1640842511; x=1672378511; h=cc:subject:to:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JyIRfdKyDD8fBL5wItWhLvIY7ErrRHB7nNqaDZhNdD0=; b=SR3WXpGcrQZrwp0PcH21sjGaItIhmLbpIw4RIYD9IC8yOL3SvN9C8/qm 5bu7ffZli5rgBMtSDEmx+lI6MjMUCZUKdJuF1k2seMTYZByQvRvjSgp9e Z2rnPV8CE0KOKtsbV0QXjohepwiOmy8qSQxqmBF1kRjax4JHQ3Xcp+Q+w NQQ479BQmP+VlCraaRosy00kgdVfW0JAIale7HCnkJcPE9ZRZVm6lBDHO Ot6yhT5TpnfnsChBZmEF/z1Fuk72wgY0gHfOHvfryu4aph1vMG6HYm21k H6PQP147PFqkkFF6M5IiZIqKGMdiwVJQLVvnmy+1SKu6wmmekdOYJ28md w==; X-IronPort-AV: E=McAfee;i="6200,9189,10212"; a="228929801" X-IronPort-AV: E=Sophos;i="5.88,247,1635231600"; d="scan'208";a="228929801" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Dec 2021 21:35:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,247,1635231600"; d="scan'208";a="524266151" Received: from allen-box.sh.intel.com (HELO [10.239.159.118]) ([10.239.159.118]) by orsmga008.jf.intel.com with ESMTP; 29 Dec 2021 21:34:58 -0800 Cc: baolu.lu@linux.intel.com, 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 v4 03/13] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming To: Bjorn Helgaas References: <20211229204202.GA1700874@bhelgaas> From: Lu Baolu Message-ID: <568b6d1d-69df-98ad-a864-dd031bedd081@linux.intel.com> Date: Thu, 30 Dec 2021 13:34:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211229204202.GA1700874@bhelgaas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, On 12/30/21 4:42 AM, Bjorn Helgaas wrote: > On Fri, Dec 17, 2021 at 02:36:58PM +0800, Lu Baolu wrote: >> The pci_dma_configure() marks the iommu_group as containing only devices >> with kernel drivers that manage DMA. > > I'm looking at pci_dma_configure(), and I don't see the connection to > iommu_groups. The 2nd patch "driver core: Set DMA ownership during driver bind/unbind" sets all drivers' DMA to be kernel-managed by default except a few ones which has a driver flag set. So by default, all iommu groups contains only devices with kernel drivers managing DMA. > >> Avoid this default behavior for the >> pci_stub because it does not program any DMA itself. This allows the >> pci_stub still able to be used by the admin to block driver binding after >> applying the DMA ownership to vfio. > >> >> Signed-off-by: Lu Baolu >> --- >> drivers/pci/pci-stub.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/pci/pci-stub.c b/drivers/pci/pci-stub.c >> index e408099fea52..6324c68602b4 100644 >> --- a/drivers/pci/pci-stub.c >> +++ b/drivers/pci/pci-stub.c >> @@ -36,6 +36,9 @@ static struct pci_driver stub_driver = { >> .name = "pci-stub", >> .id_table = NULL, /* only dynamic id's */ >> .probe = pci_stub_probe, >> + .driver = { >> + .suppress_auto_claim_dma_owner = true, > > The new .suppress_auto_claim_dma_owner controls whether we call > iommu_device_set_dma_owner(). I guess you added > .suppress_auto_claim_dma_owner because iommu_device_set_dma_owner() > must be done *before* we call the driver's .probe() method? As explained above, all drivers are set to kernel-managed dma by default. For those vfio and vfio-approved drivers, suppress_auto_claim_dma_owner is used to tell the driver core that "this driver is attached to device for userspace assignment purpose, do not claim it for kernel-management dma". > > Otherwise, we could call some new interface from .probe() instead of > adding the flag to struct device_driver. Most device drivers are of the kernel-managed DMA type. Only a few vfio and vfio-approved drivers need to use this flag. That's the reason why we claim kernel-managed DMA by default. > >> + }, >> }; >> >> static int __init pci_stub_init(void) >> -- >> 2.25.1 >> Best regards, baolu 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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2B5BFC433EF for ; Thu, 30 Dec 2021 05:35:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9BB508143C; Thu, 30 Dec 2021 05:35:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFqjC4iYxF_e; Thu, 30 Dec 2021 05:35:09 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 8A93481386; Thu, 30 Dec 2021 05:35:09 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 64A1DC002F; Thu, 30 Dec 2021 05:35:09 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 08AEDC0012 for ; Thu, 30 Dec 2021 05:35:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id EA1AA813B1 for ; Thu, 30 Dec 2021 05:35:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94zWwhsyI655 for ; Thu, 30 Dec 2021 05:35:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by smtp1.osuosl.org (Postfix) with ESMTPS id A475B81386 for ; Thu, 30 Dec 2021 05:35:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1640842506; x=1672378506; h=cc:subject:to:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JyIRfdKyDD8fBL5wItWhLvIY7ErrRHB7nNqaDZhNdD0=; b=koO+2+0pEeF8DY/hKcqTTxQtOEOtpo8Vit9Vp2Kb53cyNIT0WRzDCsaK NYkc6tNEAdjDn2XqYDaI9pHQPlOEG6LozeXEw7NAu4Gtnaw9fFbP0NvEJ YmozZqLL0TYl9EaG5ixm51sPMIFQRO5BvpWw6WiQZ52yZ/p6kdo9ColPi Yoxv7CUJiMlhh5GrdlZeKGBctGeliTMi68UMDJJNiY2Jem7NUXvcXgVuI 7JGQ7QRnF+adw1ROX/FBHhapE6J8XYTSRc1aLHO6/n6frhhDVqdqXm9jq lc38x733hKew7LHhLRDBk33K/1bqG2cq95oOnSf5raBKhO9wznxRsLqck w==; X-IronPort-AV: E=McAfee;i="6200,9189,10212"; a="304980513" X-IronPort-AV: E=Sophos;i="5.88,247,1635231600"; d="scan'208";a="304980513" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Dec 2021 21:35:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,247,1635231600"; d="scan'208";a="524266151" Received: from allen-box.sh.intel.com (HELO [10.239.159.118]) ([10.239.159.118]) by orsmga008.jf.intel.com with ESMTP; 29 Dec 2021 21:34:58 -0800 Subject: Re: [PATCH v4 03/13] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming To: Bjorn Helgaas References: <20211229204202.GA1700874@bhelgaas> From: Lu Baolu Message-ID: <568b6d1d-69df-98ad-a864-dd031bedd081@linux.intel.com> Date: Thu, 30 Dec 2021 13:34:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211229204202.GA1700874@bhelgaas> Content-Language: en-US Cc: Stuart Yoder , rafael@kernel.org, David Airlie , linux-pci@vger.kernel.org, Thierry Reding , Diana Craciun , Dmitry Osipenko , Will Deacon , Ashok Raj , Jonathan Hunter , Christoph Hellwig , Jason Gunthorpe , Kevin Tian , Chaitanya Kulkarni , Alex Williamson , kvm@vger.kernel.org, Bjorn Helgaas , Dan Williams , Greg Kroah-Hartman , Cornelia Huck , linux-kernel@vger.kernel.org, Li Yang , iommu@lists.linux-foundation.org, Jacob jun Pan , Daniel Vetter , Robin Murphy X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Hi Bjorn, On 12/30/21 4:42 AM, Bjorn Helgaas wrote: > On Fri, Dec 17, 2021 at 02:36:58PM +0800, Lu Baolu wrote: >> The pci_dma_configure() marks the iommu_group as containing only devices >> with kernel drivers that manage DMA. > > I'm looking at pci_dma_configure(), and I don't see the connection to > iommu_groups. The 2nd patch "driver core: Set DMA ownership during driver bind/unbind" sets all drivers' DMA to be kernel-managed by default except a few ones which has a driver flag set. So by default, all iommu groups contains only devices with kernel drivers managing DMA. > >> Avoid this default behavior for the >> pci_stub because it does not program any DMA itself. This allows the >> pci_stub still able to be used by the admin to block driver binding after >> applying the DMA ownership to vfio. > >> >> Signed-off-by: Lu Baolu >> --- >> drivers/pci/pci-stub.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/pci/pci-stub.c b/drivers/pci/pci-stub.c >> index e408099fea52..6324c68602b4 100644 >> --- a/drivers/pci/pci-stub.c >> +++ b/drivers/pci/pci-stub.c >> @@ -36,6 +36,9 @@ static struct pci_driver stub_driver = { >> .name = "pci-stub", >> .id_table = NULL, /* only dynamic id's */ >> .probe = pci_stub_probe, >> + .driver = { >> + .suppress_auto_claim_dma_owner = true, > > The new .suppress_auto_claim_dma_owner controls whether we call > iommu_device_set_dma_owner(). I guess you added > .suppress_auto_claim_dma_owner because iommu_device_set_dma_owner() > must be done *before* we call the driver's .probe() method? As explained above, all drivers are set to kernel-managed dma by default. For those vfio and vfio-approved drivers, suppress_auto_claim_dma_owner is used to tell the driver core that "this driver is attached to device for userspace assignment purpose, do not claim it for kernel-management dma". > > Otherwise, we could call some new interface from .probe() instead of > adding the flag to struct device_driver. Most device drivers are of the kernel-managed DMA type. Only a few vfio and vfio-approved drivers need to use this flag. That's the reason why we claim kernel-managed DMA by default. > >> + }, >> }; >> >> static int __init pci_stub_init(void) >> -- >> 2.25.1 >> Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu