Hi Ard, On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote: > As noted by Ian, many DMI based quirks for x86 ACPI machines disable > features that can also be disabled via the kernel command line. Similarly, > a quirk is under discussion for a arm64 ACPI machine [0] that explodes > when enabling support for hardware error reporting via the ACPI HEST table. > > When support for DMI tables was introduced to arm64 and ARM, the agreement > was that they are informational only, i.e., provided to userland to describe > the platform, not for keying off of to enable quirks in the kernel. > > There are a couple of reasons for this: > - Unlike the x86 architecture, where virtually all platforms are PC variants, > and the presence of ACPI and DMI tables may be assumed, the arm64 > architecture > is much more heterogeneous, and none of UEFI, ACPI or DMI or actually > mandated > or especially common across arm64 platforms; using DMI only makes sense for > working around a limited subset of platform issues that have to do with > firmware running on platforms that bother to implement it in the first > place. > - DMI is not initialized as early as it is on x86, and doing so is not > trivial. > This means that even on ACPI/DMI machines, some issues may require quirks > that > are enabled in a different way, or we need to refactor the DMI support so > that > we can enable it as early as x86 does. > - Using DMI tables fundamentally means quirking *after* the fact, which makes > it > a moving target. Some quirks may require the DMI match table to be updated > if > someone happens to change a string in the DMI tables when shipping a mostly > identical platform. > > So instead, let's provide these platforms with the facilities required to > enable > such quirks at the platform level. Especially for UEFI systems, if upgrading > firmware is a reasonable prerequisite for being able to upgrade to the latest > kernel, having to run a script that sets a UEFI variable (either via the Linux > command line of from the UEFI shell) should not be an unreasonable requirement > either, and so we can solve part of this issue by configuring extra command > line > arguments persistenly from the firmware environment. This solves all the above > issues in an unintrusive manner, given that the kernel command line is already > made available extremely early in the boot, and the fact that it already > permits > a wide range of configuration options and overrides to be set, including the > 'hest_disable=1' option that works around the issue addressed by [0].
I'm torn on this one. Whilst I strongly agree that keying off DMI tables to detect firmware quirks is a bad idea on arm64, silently extending the kernel command-line also has its downsides. The command-line provides ways to override kernel defaults, so if a user has forced a feature on/off, then I think this should take precedence over quirks and we should taint instead, rather than silently override the option. I'd be interested in other opinions on this. Will -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
