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 891C3C433EF for ; Mon, 4 Apr 2022 05:45:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242514AbiDDFp7 (ORCPT ); Mon, 4 Apr 2022 01:45:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232158AbiDDFpz (ORCPT ); Mon, 4 Apr 2022 01:45:55 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF900222BF for ; Sun, 3 Apr 2022 22:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649051038; x=1680587038; h=message-id:date:mime-version:cc:to:references:from: subject:in-reply-to:content-transfer-encoding; bh=yqOnayDDkq7B2kSo3PZODYxA79khTRkXoKtuKeni4h0=; b=ScDhPkcLSbSom3r4O863kq7ykfm9DFA5bXIHNPeMSerjwegZQa606GV0 XerPrejhfvDf/rEPSRzaw0zI3Lx/KAkFl/lDFFT0ywQhQ3MWEDznrfWeE GgVyPr/t3YqD2Gdy3vaDwhEHNK0z6jaKvGulPMurzuMkbUDdunonM3uA7 XjTdKlQpKFo6BUdPfBX0nM9XifYmsci3y8eYsIf49fTCLG+zmNP8O4hHC QBOT3nFHUibz+zpnDztvvqjQEgAfC34XIZsC+7IJFXVOgntRfXmUBf39r 3+NomntSf8XP2w+U4yXkVmFPjTR1W1/VYzUHvhL2fFjf3RdbMuDc3Sl1W Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10306"; a="258024643" X-IronPort-AV: E=Sophos;i="5.90,233,1643702400"; d="scan'208";a="258024643" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2022 22:43:55 -0700 X-IronPort-AV: E=Sophos;i="5.90,233,1643702400"; d="scan'208";a="548531610" Received: from blu2-mobl3.ccr.corp.intel.com (HELO [10.254.214.140]) ([10.254.214.140]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2022 22:43:52 -0700 Message-ID: <6ebd4f9b-5824-9489-43c3-7810963ec918@linux.intel.com> Date: Mon, 4 Apr 2022 13:43:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: baolu.lu@linux.intel.com, Joerg Roedel , Christoph Hellwig , "Raj, Ashok" , Will Deacon , Robin Murphy , Jean-Philippe Brucker , Eric Auger , "Liu, Yi L" , "Pan, Jacob jun" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" Content-Language: en-US To: Jason Gunthorpe , "Tian, Kevin" References: <20220329053800.3049561-1-baolu.lu@linux.intel.com> <20220329053800.3049561-3-baolu.lu@linux.intel.com> <20220329114259.GB1716663@nvidia.com> <20220330115820.GE1716663@nvidia.com> From: Lu Baolu Subject: Re: [PATCH RFC v2 02/11] iommu: Add iommu_group_singleton_lockdown() In-Reply-To: <20220330115820.GE1716663@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/3/30 19:58, Jason Gunthorpe wrote: >>> Testing the group size is inherently the wrong test to make. >> What is your suggestion then? > Add a flag to the group that positively indicates the group can never > have more than one member, even after hot plug. eg because it is > impossible due to ACS, or lack of bridges, and so on. The check method seems to be bus specific. For platform devices, perhaps this kind of information should be retrieved from firmware interfaces like APCI or DT. From this point of view, would it be simpler and more reasonable for the device driver to do such check? After all, it is the device driver that decides whether to provide SVA services to the application via uacce. Best regards, baolu