Date:   Fri, 25 Mar 2022 19:06:03 +0000
From:   Joao Martins <joao.m.martins@...cle.com>
To:     Robin Murphy <robin.murphy@....com>,
        Miguel Luis <miguel.luis@...cle.com>
Cc:     Will Deacon <will@...nel.org>, Joerg Roedel <joro@...tes.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        David Edmondson <david.edmondson@...cle.com>
Subject: Re: [PATCH] iommu/arm: Expose ARM SMMUv3 related registers via sysfs

On 3/25/22 18:03, Robin Murphy wrote:
> On 2022-03-23 15:09, Miguel Luis wrote:
>>> On 23 Mar 2022, at 12:40, Robin Murphy <robin.murphy@....com> wrote:
>>> On 2022-03-23 12:54, Miguel Luis wrote:
>>>> Allows userspace to check for SMMUv3 features.
>>>
>>> What will userspace do with that information?
>>>
>>> It hardly matters what fancy new features might be present, if the kernel and/or the abstracted interfaces available to userspace aren't using them. Any functionality which is supported by a usable interface should ideally be represented via that interface itself.
>>>
>>
>> The inspiration was the same that Intel (cap/ecap) and AMD (cap/features) took
>> exposing it's iommu feature registers on sysfs. It's an easy way to understand
>> which features are supported by the hardware regardless of what the kernel
>> supports.
> 
> OK, so what do end-users of Intel and AMD systems do with that 
> understanding then?
> 
It's features probing and informational purposes really -- that's all
one can do with these registers regardless of IOMMU implementation.
There some others which print the version of the iommu that also appear
as RO sysfs entries.

Those two registers on those two implementations have proved useful the
last couple of years when I got new SDPs/machines.

At the end of the day some tool (or script) pretty prints what's
supported.. on what usually is depicted in very lenghty manuals.
And that's fed into a toolbox that prints all hardware and software
capabilities alongside diagnostics / etc (for troubleshooting).
You know, similar to `cpuid` on the x86 cpuid side (albeit you could
argue that it's behind a 'special' instruction). And that 'decodes' to
an human-friendly on what goes in those lenghty SDMs. `/proc/cpuinfo`
translates that into a set of keywords (which may be software-specific or
hardware features). And more recently `kcpuid` for raw-supported
features. I am sure there's more examples.

>> For example I could print the smmu->features and that would cover kernel
>> supported features but wouldn't help when new hardware arrives to know which
>> features are supported by the hardware.
> 
> Indeed the driver already prints the supported features at boot, largely 
> because it's useful for debugging. But again, what's the advantage of 
> knowing what you might theoretically be able to do with a machine if you 
> don't have the software support to actually do it? Are there users out 
> there who aren't going to update their OS *unless* they can cling to the 
> hope that a new OS might see the opportunity to use foreign-endianness 
> pagetables and finally take it?
> 
> I appreciate the natural human instinct to want to poke around at and 
> evaluate a new shiny thing, but a sufficiently interested user can 
> already do that with /dev/mem or any number of other ways. We don't need 
> the burden of maintaining an upstream sysfs ABI for curiosity.
> 
/dev/mem is an interesting alternative -- I wasn't quite sure you could use
the register addresses here arbitrarily on ARM. Anyways, I suppose it's an
worthwhile alternative in case it works.

> The other fact of the matter is that a great deal of systems with SMMUv3 
> will be using one of Arm Ltd's implementations, and as soon as one knows 
> that one can readily look up all the details in Arm's documentation. 
> Especially when one already has that site open to find the SMMUv3 
> architecture spec to make sense of cryptic register dumps, right?
> 
Heh, the idea was to avoid going to those specs all the time, but I understand
your earlier point(s).

Also, IOMMUs are getting bigger in terms of featureset -- so it would be nice to
better introspect what iommus can do (in the whatever mix of implementations)
in a less chaotic manner. Maybe implementation-specific sysfs entries are not it,
but hopefully something else in a more generic-way, in the advent of a more
direct interface to iommus.

Powered by blists - more mailing lists