netdev - Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc

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]

Date:   Fri, 14 Feb 2020 16:29:40 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Pankaj Bansal <pankaj.bansal@....com>,
        Marc Zyngier <maz@...nel.org>
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Makarand Pawagi <makarand.pawagi@....com>,
        Calvin Johnson <calvin.johnson@....com>,
        "stuyoder@...il.com" <stuyoder@...il.com>,
        "nleeder@...eaurora.org" <nleeder@...eaurora.org>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Cristi Sovaiala <cristian.sovaiala@....com>,
        Hanjun Guo <guohanjun@...wei.com>,
        Will Deacon <will@...nel.org>,
        "jon@...id-run.com" <jon@...id-run.com>,
        Russell King <linux@...linux.org.uk>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Len Brown <lenb@...nel.org>,
        Jason Cooper <jason@...edaemon.net>,
        Andy Wang <Andy.Wang@....com>, Varun Sethi <V.Sethi@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Laurentiu Tudor <laurentiu.tudor@....com>,
        Paul Yang <Paul.Yang@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Shameerali Kolothum Thodi 
        <shameerali.kolothum.thodi@...wei.com>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc

On 14/02/2020 3:58 pm, Pankaj Bansal wrote:
[...]
>> I don't understand what you mean. Platform MSI using IORT uses the DevID of
>> end-points. How could the ITS could work without specifying a DevID?
>> See for example how the SMMUv3 driver uses platform MSI.
> 
> DevID is input ID for PCIe devices. BUT what would be the input ID for platform device? Are we saying that Platform devices can't specify an Input ID ?

No, from the IORT perspective, the input for the ID mappings belonging 
to a root complex is the PCI requester ID. The (ITS) DevID is the 
ultimate *output* of a root complex mapping.

Whilst you can indeed represent the MC as a black-box Named Component 
with an ID mapping range not using the "single mapping" flag, that means 
your input IDs come from some device-specific domain beyond the scope of 
IORT. That's why you can't easily get away from your special bus 
integration code.

>>> While, IORT spec doesn't specify any such limitation.
>>>
>>> we can easily update iort.c to remove this limitation.
>>> But, I am not sure how the input id would be passed from platform MSI
>>> GIC layer to IORT.
>>> Most obviously, the input id should be supplied by dev itself.
>>
>> Why should the device know about its own ID? That's a bus/interconnect thing.
>> And nothing should be passed *to* IORT. IORT is the source.
> 
> IORT is translation between Input IDs <-> Output IDs. The Input ID is still expected to be passed to parse IORT table.

...except for single mappings, where the input ID is ignored and the 
output ID is the "source", which is exactly what iort_node_get_id() 
deals with for devices represented in IORT. With what you're talking 
about, "the device" is *not* represented in IORT, but is something 
beyond the MC 'bridge'. Now it probably is technically possible to 
handle that somehow, but it's definitely not something that the existing 
code was ever designed to anticipate.

Robin.