linux-kernel - Re: [PATCH] arm64: PCI: Enable SMC conduit

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: <20210616173646.GA1840163@nvidia.com>
Date:   Wed, 16 Jun 2021 14:36:46 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     Will Deacon <will@...nel.org>, Vikram Sethi <vsethi@...dia.com>,
        vidyas@...dia.com, treding@...dia.com,
        Jon Masters <jcm@...masters.org>,
        Jeremy Linton <jeremy.linton@....com>, mark.rutland@....com,
        linux-pci@...r.kernel.org, sudeep.holla@....com,
        linux-kernel@...r.kernel.org, catalin.marinas@....com,
        bhelgaas@...gle.com, linux-arm-kernel@...ts.infradead.org,
        ebrower@...dia.com, jcm@...hat.com, Grant.Likely@....com
Subject: Re: [PATCH] arm64: PCI: Enable SMC conduit

On Thu, Mar 25, 2021 at 01:12:31PM +0000, Lorenzo Pieralisi wrote:

> A discussion was held between me, Will Deacon, Bjorn Helgaas and Jon
> Masters to agree on a proposed solution for this matter, a summary of the
> outcome below:
> 
> - The PCI SMC conduit and related specifications are seen as firmware
>   kludge to a long-standing HW compliance issue. The SMC interface does
>   not encourage Arm partners to fix their IPs and its only purpose
>   consists in papering over HW issues that should have been fixed by
>   now; were the PCI SMC conduit introduced at arm64 ACPI inception as
>   part of the standardization effort the matter would have been different
>   but introducing it now brings about more shortcomings than benefits on
>   balance, especially if MCFG quirks can be controlled and monitored (and
>   they will).

I wanted to inject a slightly different viewpoint on this (old thread,
since it was revisited in some other forum) - I'm not so interested in
this firmware interface to fix ECAM compliance/quirks/etc.

However, in modern server type systems the PCI config space is often a
software fiction being created by firmware throughout the PCI
space. This has become necessary as the config space has exploded in
size and complexity and PCI devices themselves have become very, very
complicated. Not just the config space of single devices, but even
bridges and topology are SW created in some cases.

HW that is doing this is already trapping the config cycles somehow,
presumably with some very ugly way like x86's SMM. Allowing a designed
in way to inject software into the config space cycles does sound a
lot cleaner and better to me.

For instance it may solve other pain points if ARM systems had a cheap
way to emulate up a "PCI device" to wrapper around some IP blob on
chip. The x86 world has really driven this approach where everything
on SOC is PCI discoverable, and it does seem to work well.

IMHO SW emulation of config space is an important ingredient to do
this.

Jason