Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-Id: <35d65efa-e87b-4cc5-9c1a-e95dd6bf8edb@app.fastmail.com>
In-Reply-To: <20231023141955.GX3952@nvidia.com>
References: <20231023115520.3530120-1-arnd@kernel.org>
 <20231023120418.GH691768@ziepe.ca>
 <a16758d6-964d-4e46-9074-4d155f9b3703@oracle.com>
 <b3f7ecb1-9484-426b-8692-98706f7ff6d4@app.fastmail.com>
 <20231023132305.GT3952@nvidia.com>
 <5d7cb04d-9e79-43b9-9dd2-7d7803c93f4f@app.fastmail.com>
 <20231023141955.GX3952@nvidia.com>
Date:   Mon, 23 Oct 2023 16:35:15 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Jason Gunthorpe" <jgg@nvidia.com>
Cc:     "Joao Martins" <joao.m.martins@oracle.com>,
        "Arnd Bergmann" <arnd@kernel.org>,
        "Kevin Tian" <kevin.tian@intel.com>,
        "Yishai Hadas" <yishaih@nvidia.com>,
        "Shameerali Kolothum Thodi" <shameerali.kolothum.thodi@huawei.com>,
        "Alex Williamson" <alex.williamson@redhat.com>,
        "Brett Creeley" <brett.creeley@amd.com>,
        oushixiong <oushixiong@kylinos.cn>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfio: mlx5, pds: add IOMMU_SUPPORT dependency
Content-Type: text/plain
Precedence: bulk

On Mon, Oct 23, 2023, at 16:19, Jason Gunthorpe wrote:
> On Mon, Oct 23, 2023 at 04:02:11PM +0200, Arnd Bergmann wrote:
>> On Mon, Oct 23, 2023, at 15:23, Jason Gunthorpe wrote:
>> >
>> > I think the right thing is to combine IOMMU_SUPPORT and IOMMU_API into
>> > the same thing.
>> 
>> I've had a closer look now and I think the way it is currently
>> designed to be used makes some sense: IOMMU implementations almost
>> universally depend on both a CPU architecture and CONFIG_IOMMU_SUPPORT,
>> but select IOMMU_API. So if you enable IOMMU_SUPPORT on an
>> architecture that has no IOMMU implementations, none of the drivers
>> are visible and nothing happens. Similarly, almost all drivers
>> using the IOMMU interface depend on IOMMU_API, so they can only
>> be built if at least one IOMMU driver is configured.
>
> Maybe, but I don't think we need such micro-optimization.
>
> If someone selects 'enable IOMMU support' and doesn't turn on any
> drivers then they should still get the core API. That is how a lot of
> the kconfig stuff typically works in the kernel.

Agreed, that would be fine as well, and I agree it is less confusing.
A similar approach as in iommu is used in a couple of other subsystems
(regmap, gpiolib, sound, mfd, phy, virtio) where each provider selects
the subsystem as a library, but I'm not a huge fan of this either.
It's usually just easier to not make fundamental changes like this.

In this case, we can just use 'depends on' for one of the two
symbols everywhere and use to control both the providers and
consumers.

> Similarly, if they don't select 'enable IOMMU support' then they
> definitely shouldn't quitely get the core API turned on!
...
>> diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
>> index 4a79704b164f7..2902b89a48f17 100644
>> --- a/drivers/gpu/drm/nouveau/Kconfig
>> +++ b/drivers/gpu/drm/nouveau/Kconfig
>> @@ -4,7 +4,7 @@ config DRM_NOUVEAU
>>  	depends on DRM && PCI && MMU
>>  	depends on (ACPI_VIDEO && ACPI_WMI && MXM_WMI) || !(ACPI && X86)
>>  	depends on BACKLIGHT_CLASS_DEVICE
>> -	select IOMMU_API
>> +	depends on IOMMU_API
>>  	select FW_LOADER
>>  	select DRM_DISPLAY_DP_HELPER
>>  	select DRM_DISPLAY_HDMI_HELPER
>
> Like here, nouveau should still be compilable even if no iommu driver
> was selected, and it should compile on arches without iommu drivers at
> all.

Right, so with my draft patch, we can't build nouveau without
having an IOMMU driver, which matches the original intention
behind the Kconfig logic, while your suggestion would add the
same dependency here but still allow it to be compile tested
on target systems with no IOMMU. A minor downside of your
approach is that you end up building drivers (without
CONFIG_COMPILE_TEST) that currently exclude because we know
they will never work.

     Arnd