linux-kernel - Re: [PATCH 6/8] iommu: Retire bus ops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <31e5007b-8151-4ec6-9b63-a64a5888d2a9@linux.intel.com>
Date:   Thu, 26 Jan 2023 20:37:17 +0800
From:   Baolu Lu <baolu.lu@...ux.intel.com>
To:     Robin Murphy <robin.murphy@....com>, joro@...tes.org,
        will@...nel.org
Cc:     baolu.lu@...ux.intel.com, hch@....de, jgg@...dia.com,
        iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 6/8] iommu: Retire bus ops

On 2023/1/20 20:31, Robin Murphy wrote:
> On 2023-01-20 00:27, Baolu Lu wrote:
>> On 2023/1/20 3:18, Robin Murphy wrote:
>>> +    /*
>>> +     * For FDT-based systems and ACPI IORT/VIOT, drivers register IOMMU
>>> +     * instances with non-NULL fwnodes, and client devices should 
>>> have been
>>> +     * identified with a fwspec by this point. For 
>>> Intel/AMD/s390/PAMU we
>>> +     * can assume a single active driver with global ops, and so 
>>> grab those
>>> +     * from any registered instance, cheekily co-opting the same 
>>> mechanism.
>>> +     */
>>> +    fwspec = dev_iommu_fwspec_get(dev);
>>> +    if (fwspec && fwspec->ops)
>>> +        ops = fwspec->ops;
>>> +    else
>>> +        ops = iommu_ops_from_fwnode(NULL);
>>
>> I'm imagining if Intel/AMD/s390 drivers need to give up global ops.
>> Is there any way to allow them to make such conversion? I am just
>> thinking about whether this is a hard limitation for these drivers.
> 
> Yes, they could perhaps bodge into the existing fwnode mechanism, or we 
> could make bigger changes to adapt and generalise the whole 
> instance-registration-token-lookup concept, or if the driver can resolve 
> the correct instance for a device internally, then it could suffice to 
> just have all its device ops share a single common .probe_device 
> implementation that does the right thing.

Yes. Sharing a common .probe_device entry and let the IOMMU driver
connect the device and its iommu ops is a feasible solution. Thanks!

> 
> The comment is merely noting the fact that we can get away without 
> having to worry about those changes just yet, since all the drivers 
> *are* currently still built around the hard constraint of a single set 
> of device ops per bus.

Yes. Fair enough.

--
Best regards,
baolu