Date:   Fri, 10 Mar 2023 08:51:36 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Eric Auger <eric.auger@redhat.com>
Cc:     Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Nicolin Chen <nicolinc@nvidia.com>, robin.murphy@arm.com,
        will@kernel.org, kevin.tian@intel.com, baolu.lu@linux.intel.com,
        joro@8bytes.org, shameerali.kolothum.thodi@huawei.com,
        linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
        linux-kernel@vger.kernel.org, yi.l.liu@intel.com
Subject: Re: [PATCH v1 02/14] iommufd: Add nesting related data structures
 for ARM SMMUv3
Message-ID: <ZAsn2EkRnEmsfmmp@nvidia.com>
References: <cover.1678348754.git.nicolinc@nvidia.com>
 <364cfbe5b228ab178093db2de13fa3accf7a6120.1678348754.git.nicolinc@nvidia.com>
 <20230309134217.GA1673607@myrica>
 <5288c0e9-b806-370d-e7de-8d69d5b8e902@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5288c0e9-b806-370d-e7de-8d69d5b8e902@redhat.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9EoyXA5Zrgh8FC0YBzy6Rx+GX7zhcK7OC7GoFc5vhk0JHLCtuxUpOG3epxvr?=
 =?us-ascii?Q?ZjiZzLYsVcqTZanbDlQxJJkJhW6mdmEneB7cF6NynJ9LvnIhEckrhQXFd5Xp?=
 =?us-ascii?Q?hOLnek7445tZv0InTs5lVcHC9BUZmPVj6sU3ik3wqCeORA+Rv9Up51cyQxHf?=
 =?us-ascii?Q?qBuLnlv/y+4Cg+tq8tsnxHvTLcERcYDwMWPpzEGqh4ioPm43yrBfCG/5zxR7?=
 =?us-ascii?Q?eBeUNvg7VVUFvBZXvHQaABcMjtdva3iR8mlBl7sG67RBshetFQxPUiI35iOd?=
 =?us-ascii?Q?kgt+4o+Umrnv6FcYcW56IVdS5STtWgnbZlzExGMiJaJRdFdF4tDwICFzD2Rh?=
 =?us-ascii?Q?ghxgMrUPJaF4H/X/CXj/5iwRrLDixQHR/CM/cA/RXb/Wj0PVm1xWzg4hVtTx?=
 =?us-ascii?Q?Wu39eaONlp8lJgbgG2hlv4GANaM6enEoY4gM3YBJH6kDVhIcQ+UE2w529y91?=
 =?us-ascii?Q?6FbNBwKjCz/MWVbYTEqzkH0yz9uOW0l2bZ3kmNZKAY8fihMqHjb6I5KvzIih?=
 =?us-ascii?Q?ZIDlTZxxPrlimPxtgBqk9Ov9gEK1cZA+IoI5d26KTBiqXI5Xri1/ln8QGFWv?=
 =?us-ascii?Q?3XgXBsh4kM6B05CbnNtSPLtuJurZ4gcLjlCuOU+iGZwaCkTtHNaSktwUYQDp?=
 =?us-ascii?Q?FYH3yJq1Ccp+5RgrSADZVDR1akzXiu//KlhuUCeqECdfZhyrB7Y3bt0LaJgz?=
 =?us-ascii?Q?CDjp540RYEKTNOedq9pWZTiwG/sBnAy517+wQ4q8mxDujLjFeZLP65bga6aW?=
 =?us-ascii?Q?pBsJaOHEVqq5JXH2cnqQIMC4rbp403s8ipVt+RXUEOm8fHhakGft4zeyMMTN?=
 =?us-ascii?Q?1vQHkKzbgLe24qU8MnG+KIaG/JewsKqTBEA49XdARiZO7kBf4+FCz5P1JOEJ?=
 =?us-ascii?Q?AGuZ0mimgTSva0sQZbkiBWcvlFbPcjOZbc09DAnLIot7t/OxUXY0jHI57LWM?=
 =?us-ascii?Q?HIcMWnqnY0n8rUV6G9a4NrxuK1eZhYXdjixl3SBD+UlI4vERPQK++u8fbVjX?=
 =?us-ascii?Q?P9RRQ2gLw+vzvQ8JenDHE5Qe1M0KZpTWwvpxbqEu0ai3aWEu2DXF+Kt1yuxs?=
 =?us-ascii?Q?AzL8uVXLdjJUsstttdNKEZ6zmZimLK2teYz7uHdBtsFpoePr5DyOp/Wh556u?=
 =?us-ascii?Q?PxGtTEnSuYOui3wvfMMWXMfmdGdrIExYtSQFaJWQBnGc6X719S2zP7CfCjp4?=
 =?us-ascii?Q?MOUHB/UirmMofYZOBS7f10/Ldr2AfAMHo+IUv9U/Mr0psoKsqlBPsS26ZggW?=
 =?us-ascii?Q?qvHYPH72wjKpfu/wTN3uadLvI+te18GWP72oHseLbKI0rf8aj0qHsr9zB6ex?=
 =?us-ascii?Q?bNqgPNn6b1sOdL82zz+KsO/y4THeW0BzeGCi+yv6j7SmWQ6FVBxKKroC+WIV?=
 =?us-ascii?Q?a/Ihrkr9LWOnXsGduRwsqyVgRnI9SqPGbOvEBP8P7UNHwHRYGsKpeZiFTEvi?=
 =?us-ascii?Q?PKQevYTqJFoGgTLN/MEIL3WmQpSCh9E86t+6rTJTVyKXhKyMO2xX98xg9093?=
 =?us-ascii?Q?gs3/Yom3I9Euny1fkXdCxaSK+BQ5JjBVFvh25u8JLTWr+izLX3+HB2P/y/tg?=
 =?us-ascii?Q?xPT2M6oy8R9jS4kFqGevLtlS1+u3WOzEPU3GHDD7?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d5d75219-ab39-41bf-bca0-08db21663125
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2023 12:51:39.9726
 (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: SU30dnhpkPAELU7ijO2FnJyLKh8qNDG/x97WOPkt4UKhksqVjKzKTpBLWzjKVFej
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4941
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Mar 10, 2023 at 12:33:12PM +0100, Eric Auger wrote:

> I do agree with Jean. We spent a lot of efforts all together to define
> this generic invalidation API and if there is compelling reason that
> prevents from using it, we should try to reuse it.

That's the compelling reason in a nutshell right there.

Alot of time was invested to create something that might be
general. We still don't know if it is well defined and general. Even
more time is going to be required on it before it could go forward. In
future more time will be needed for every future HW to try and fit
into it. We don't even know if it will scale to future HW. Nobody has
even checked what today's POWER and S390 HW need.

vs, this stuff was made in a few days. We know it is correct as a uAPI
since it mirrors the HW and we know it is scalable to different HW
schemes if they come up.

So I don't see a good reason to take a risk on a "general" uAPI. If we
make this wrong it could seriously damage the main goal of iommufd -
to build accelerated vIOMMU models.

Especially since the motivating reason in this thread - use it for
virtio-iommu - doesn't even want to use it as a uAPI!

If we get a vhost-virtio then we can decide what to do in-kernel and
maybe this general API returns as an in-kernel API, I dont know, we
need to see what it is this thing ends up looking like.

Jason