Messages in this thread | | | Date | Tue, 29 Nov 2022 18:41:22 +0000 | Subject | Re: [PATCH v2 4/7] iommu: Let iommu.strict override ops->def_domain_type | From | Robin Murphy <> |
| |
On 2022-11-29 17:33, Jason Gunthorpe wrote: > On Mon, Nov 28, 2022 at 09:01:43PM +0000, Robin Murphy wrote: > >> I'm hardly an advocate for trying to save users from themselves, but I >> honestly can't see any justifiable reason for not having sysfs respect >> iommu_get_def_domain_type(). > > We really need to rename this value if it is not actually just an > advisory "default" but a functional requirement ..
It represents a required default domain type. As in, the type for the device's default domain. Not the default type for a domain. It's the iommu_def_domain_type variable that holds the *default* default domain type ;)
Which reminds me I should finish that patch undoing my terrible ops->default_domain_ops idea, not least because they are misleadingly unrelated to default domains...
>>> The driver should have no say in how dma-iommu.c works beyond if it >>> provides the required ops functionalities, and hint(s) as to what >>> gives best performance. >> >> That should already be the case today, as outlined in my other mail. It's >> just somewhat more evolved than designed, so may not be so clear to >> everyone. > > It is close to being clear, once we get the last touches of dma-iommu > stuff out of the drivers it should be quite clear
Cool, some upheaval of .domain_alloc is next on my hitlist anyway, so that might be a good excuse to upheave it a bit more and streamline the type stuff along the way.
Cheers, Robin.
| |