Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Tue, 17 Oct 2023 12:53:01 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     "Tian, Kevin" <kevin.tian@intel.com>
Cc:     Nicolin Chen <nicolinc@nvidia.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "cohuck@redhat.com" <cohuck@redhat.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
        "chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
        "yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
        "peterx@redhat.com" <peterx@redhat.com>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>,
        "lulu@redhat.com" <lulu@redhat.com>,
        "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
        "Martins, Joao" <joao.m.martins@oracle.com>
Subject: Re: [PATCH v4 08/17] iommufd: Always setup MSI and anforce cc on
 kernel-managed domains
Message-ID: <20231017155301.GH3952@nvidia.com>
References: <20230921075138.124099-1-yi.l.liu@intel.com>
 <20230921075138.124099-9-yi.l.liu@intel.com>
 <BN9PR11MB527658EAF017FF3576667EEA8CC3A@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZSnkiKoCspmG1+/j@Asurada-Nvidia>
 <BN9PR11MB52763227866603ED7795AA068CD7A@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20231016115736.GP3952@nvidia.com>
 <BN9PR11MB5276FDC375685CE04A7AD93B8CD6A@BN9PR11MB5276.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BN9PR11MB5276FDC375685CE04A7AD93B8CD6A@BN9PR11MB5276.namprd11.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?jmpsXSMzZHs0BmAYSlaaSF6PBPRrTVQDLZkOxkH15XIWhzPOsWmrDyQwpwTK?=
 =?us-ascii?Q?eQSeslHE5Jx3Fdcmw+B7Dwcr5hx1mdmlG3f8fGShQHXl7unK4LFFTIkrXSj3?=
 =?us-ascii?Q?XX1mvBAKGZGC4iMh+hIzyhxMTkGukcjsQI5dv5qC9dccJVGQgsjdIjBvb8vm?=
 =?us-ascii?Q?p2aQ7iobo5YzeJO2wJ6CU2o/1Liz/NPjM4W61Qoz1F5bR6E5/TuqKK/wqmR3?=
 =?us-ascii?Q?D19mss2g02wTf0a+8DY+qCftL6NEkp0BAQiB0E1wTVaeHL02w5aOeWqhTxEs?=
 =?us-ascii?Q?WJCezL4/2n54GuG4g9iEFCEKIFVW3zk8m1uNd1E836Ts13pWzMuJNQyCprqO?=
 =?us-ascii?Q?kimN8OhD0WlITpTvAIAZZZmWQtvazZgu5QaNJT1XgUZDgPFx80C4H4XWNkZB?=
 =?us-ascii?Q?LUYPeQyGdWY9IEszoc2zo3HaAQNZTe2YWbqkNjUyPH86vYm7sJ3KRcgwOxVX?=
 =?us-ascii?Q?1uKvIJTm9ZKw+sju3wv2jdJE2jWFalj62pd8iYIhh+2za4Gtqtx7ORyVpbJU?=
 =?us-ascii?Q?TjqQdFi4EUbemrkTPoqci0fgMzAx1Xr9Ll6oEYUiOX+Vy3tQTAJewkBDrmV1?=
 =?us-ascii?Q?/CVAv2X/4z7gnR6p4IIFTeYQyopGCOG+jl0gWh8de9v48hcqPYjkHyLqkhZQ?=
 =?us-ascii?Q?LBPpl9hD1iwLPxQbQmR1Mf8SjIUBqSTHpT4pbh5nGNic2Ip64F5GvLgfl6Xm?=
 =?us-ascii?Q?tWRQyuZGOkg1vBuNhfyqTnvXDrjqISqLKHRdlM5kRsFkCiIWdvBYwblZ42lu?=
 =?us-ascii?Q?ZfDB3umqMRcSwUpWBTLI8ZoknYDbJuZ9gv8Au7fXQU+EL/b68gL+IrYEMpUE?=
 =?us-ascii?Q?cIrpSvYjC2+40vqRXwYANycINhCyI2sk+trb2/eR6IkhJym/gbyHMsA8ZAUO?=
 =?us-ascii?Q?gSt8859+Y8LNWbUR3sJjN7HHi8GtbL3gjEleU0xmzN4z55cmh/o3McLmOCQA?=
 =?us-ascii?Q?8LFXFmMv3kLVOhlYwE/pLmATsG3Any6LtZ34eqzFsnDLmHcCkuSW2OkOwPX7?=
 =?us-ascii?Q?P5C+a8U/78h/Ysd5xhmfP9j1SFN/vrY0pu8Kh3pdb50ZdhYiru8ccA6PRMEU?=
 =?us-ascii?Q?uhju0HVrmPjFmEWb16rw+98mM1KnjiZyRxjWdWOEzAr0C7AOoORBv0zzBI+A?=
 =?us-ascii?Q?/liCZsHgraO/MuibQtpS8kZ95gy2fmwlA/DFZezAxcgqdXAbcGAEDRP0gjMp?=
 =?us-ascii?Q?mHyyEkKPgR0EzX1LDss9hVFmlnoTTrZiCBCrtVVSfzWQQZNx4V5Al5FQf+4m?=
 =?us-ascii?Q?dKgxl+EVlojbx9+HR0NNRag5Spnvdw+zUhynlPfAIbLrv7vw5i5CxBb107oT?=
 =?us-ascii?Q?ke0CC9gEYxSG7fgc/ldTTxg9uIN9wKM2CDrwDiOMYpuQz6lCgHLcWI0sdt0C?=
 =?us-ascii?Q?+XQTzvvn0hK/ka/tD+J7dJqGlMDq1gdRa4uZ3xTbu/qftlQaNTMCDvHDitpi?=
 =?us-ascii?Q?E5plCsIE9uA9a4xfu8ArJC14g9zE1rxDjXinhNpEKMFz4U/WNCliMHlO+MsX?=
 =?us-ascii?Q?YlG4K0mk0EN2wku+CD21D7bkQexAncXpW2MCpC2Az83rASCy5rBgTZchNown?=
 =?us-ascii?Q?dDfGRbMsCoHTcjSzD3ygapur09PeHi2EIl+V6ja4?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3feea3a-a31e-4451-8cc2-08dbcf2924e0
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2023 15:53:02.3858
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: FsqY8J8neSPSEQaVShxGFdR+hIgCPnN2Bl2QRXZzSIzRWaW94u8VbrWwEdJ0YI1Z
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7875
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Tue, 17 Oct 2023 08:53:17 -0700 (PDT)

On Tue, Oct 17, 2023 at 08:52:49AM +0000, Tian, Kevin wrote:

> > This is why I wanted to get rid of this bad mechanism going forward.
> > 
> > Manually created hwpt should have a manual specification of cc and
> > then we don't have so many problems.
> > 
> > It means userspace needs to compute if they want to use CC or not, but
> > userspace already needs to figure this out since without autodomains
> > it must create two hwpts manually anyhow.
> > 
> 
> Now there is no interface reporting enforce_cc to userspace.

Yes..

> Actually the user doesn't need to know enforce_cc. As long as there is
> an attach incompatibility error the user has to create a 2nd hwpt for
> the to-be-attached device then enforce_cc will be handled automatically
> in hwpt_alloc.

Uh, OK we can do that.. It is a bit hacky because we don't know the
order do
 
> I prefer to removing enforce_cc in attach fn completely then no parent
> trick in this patch. Just keep it in hwpt_alloc and leave to iommu driver to
> figure out the attaching compatibility:

You are basically saying to set the cc mode during creation because we
know the idev at that moment and can tell if it should be on/off?

It seems reasonable, but I can't remember why it is in the attach path
at the moment.

Jason