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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D5E0C433F5 for ; Fri, 19 Nov 2021 11:14:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A8AC61353 for ; Fri, 19 Nov 2021 11:14:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234715AbhKSLRU (ORCPT ); Fri, 19 Nov 2021 06:17:20 -0500 Received: from mga05.intel.com ([192.55.52.43]:33847 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229521AbhKSLRT (ORCPT ); Fri, 19 Nov 2021 06:17:19 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10172"; a="320612641" X-IronPort-AV: E=Sophos;i="5.87,247,1631602800"; d="scan'208";a="320612641" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2021 03:14:17 -0800 X-IronPort-AV: E=Sophos;i="5.87,247,1631602800"; d="scan'208";a="507861408" Received: from blu2-mobl3.ccr.corp.intel.com (HELO [10.254.208.131]) ([10.254.208.131]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2021 03:14:13 -0800 Message-ID: <75100dfd-9cfe-9f3d-531d-b4d30de03e76@linux.intel.com> Date: Fri, 19 Nov 2021 19:14:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Cc: baolu.lu@linux.intel.com, Christoph Hellwig , Greg Kroah-Hartman , Joerg Roedel , Alex Williamson , Bjorn Helgaas , "Raj, Ashok" , Chaitanya Kulkarni , "kvm@vger.kernel.org" , "rafael@kernel.org" , "linux-pci@vger.kernel.org" , Cornelia Huck , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "Pan, Jacob jun" , Diana Craciun , Will Deacon Content-Language: en-US To: "Tian, Kevin" , Jason Gunthorpe References: <20211115020552.2378167-1-baolu.lu@linux.intel.com> <20211115020552.2378167-2-baolu.lu@linux.intel.com> <20211116134603.GA2105516@nvidia.com> <20211118133325.GO2105516@nvidia.com> From: Lu Baolu Subject: Re: [PATCH 01/11] iommu: Add device dma ownership set/release interfaces In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On 2021/11/19 13:44, Tian, Kevin wrote: >> From: Jason Gunthorpe >> Sent: Thursday, November 18, 2021 9:33 PM >> >>> In concept a singleton group is different from a >>> multi-devices group which has only one device bound to driver... >> >> Really? Why? I don't see it that way.. >> >> A singleton group is just a multi-device group that hasn't been >> hotplugged yet. >> >> We don't seem to have the concept of a "true" singleton group which is >> permanently single due to HW features. >> >>> This series aims to avoid conflict having both user and kernel drivers >>> mixed in a multi-devices group. > > Well, the difference is just in literal. I don't know the background > why the existing iommu_attach_device() users want to do it this > way. But given the condition in iommu_attach_device() it could > in theory imply some unknown hardware-level side effect which > may break the desired functionality once the group size grows > beyond singleton. Is it a real case? I don't know... > > You are now redefining that condition from singleton group to > multi-devices group with single driver bound. As long as no object > from existing driver users, I'm fine with it. But still want to raise > awareness as it does change the existing semantics (though might > be considered as an imperfect way). The singleton group requirement for iommu_attach/detach_device() was added by below commit: commit 426a273834eae65abcfc7132a21a85b3151e0bce Author: Joerg Roedel Date: Thu May 28 18:41:30 2015 +0200 iommu: Limit iommu_attach/detach_device to devices with their own group This patch changes the behavior of the iommu_attach_device and iommu_detach_device functions. With this change these functions only work on devices that have their own group. For all other devices the iommu_group_attach/detach functions must be used. Signed-off-by: Joerg Roedel Joerg,can you please shed some light on the background of this requirement? Does above idea of transition from singleton group to group with single driver bound make sense to you? Best regards, baolu