[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aEsP3odkscXw8l5/@nvidia.com>
Date: Thu, 12 Jun 2025 10:35:26 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
CC: Baolu Lu <baolu.lu@...ux.intel.com>, "jgg@...dia.com" <jgg@...dia.com>,
"will@...nel.org" <will@...nel.org>, "robin.murphy@....com"
<robin.murphy@....com>, "joro@...tes.org" <joro@...tes.org>,
"ddutile@...hat.com" <ddutile@...hat.com>, "Liu, Yi L" <yi.l.liu@...el.com>,
"peterz@...radead.org" <peterz@...radead.org>, "jsnitsel@...hat.com"
<jsnitsel@...hat.com>, "praan@...gle.com" <praan@...gle.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "iommu@...ts.linux.dev"
<iommu@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "patches@...ts.linux.dev"
<patches@...ts.linux.dev>
Subject: Re: [PATCH v1 08/12] iommufd/viommu: Replace ops->viommu_alloc with
ops->viommu_init
On Thu, Jun 12, 2025 at 08:22:49AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@...dia.com>
> > Sent: Tuesday, June 10, 2025 2:20 PM
> >
> > On Tue, Jun 10, 2025 at 01:55:05PM +0800, Baolu Lu wrote:
> > > On 6/10/25 01:13, Nicolin Chen wrote:
> > > > To ease the for-driver iommufd APIs, get_viommu_size and viommu_init
> > ops
> > > > are introduced. Now, those existing vIOMMU supported drivers
> > implemented
> > > > these two ops too.
> > > >
> > > > Relace the ops->viommu_alloc call with the two new ones.
> > > >
> > > > Note that this will fail a !viommu->ops case from now on, since a
> > vIOMMU
> > > > is expected to support alloc_domain_nested at least.
> > >
> > > Does this mean that the viommu implementation in the iommu driver is
> > > required to implement alloc_domain_nested? I suppose viommu should
> > soon
> > > be extended to support TEE/IO.
> >
> > It's a good point that CCA might not need a nested domain. So,
> > it's inaccurate to say that, although I suspect that CCA would
> > need some other viommu op then the check here would be sane.
> >
> > With that being said, it's probably not worth adding that until
> > we are 100% sure that no case will work with a !viommu->ops, so
> > let's drop this new rejection, since we haven't had it so far.
> >
>
> WARN_ON_ONCE() is built on the current context, not the future
> usage. So I'd prefer to keeping it until there is a real need to revert.
>
> Reviewed-by: Kevin Tian <kevin.tian@...el.com>
Okay. And I can make the commit message clearer.
Thanks
Nicolin
Powered by blists - more mailing lists