Re: [PATCH v2 1/6][4.16?] x86/x2APIC: defer probe until after IOMMU ACPI table parsing

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.11.2021 16:47, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH v2 1/6][4.16?] x86/x2APIC: defer probe 
> until after IOMMU ACPI table parsing"):
>>> 4.16: While investigating the issue addressed by the referenced commit,
>>>       a variant of that problem was identified when firmware pre-enables
>>>       x2APIC mode. Whether that's something sane firmware would do when
>>>       at the same time IOMMU(s) is/are disabled is unclear, so this may
>>>       be a purely academical consideration. Working around the problem
>>>       also ought to be as simple as passing "iommu=no-intremap" on the
>>>       command line. Considering the fragility of the code (as further
>>>       demonstrated by v1 having been completely wrong), it may therefore
>>>       be advisable to defer this change until after branching.
> 
> Thanks for the frank analysis.
> 
>> The main issue here would be missing a dependency between
>> acpi_iommu_init and the rest of acpi_boot_init, apart from the
>> existing dependencies between acpi_iommu_init and generic_apic_probe.
> 
> I have been thinking about this.  I'm still not sure.
> 
>>>       Nevertheless it will then be a backporting candidate, so
>>>       considering to take it right away can't simply be put off.
> 
> This part confused me.  Under what circumstances would we backport
> this ?  AIUI it would be backporting a potentially-fragile and
> not-readily-testable bugfix, for a theoretical scenario with a
> straightforward workaround.

Well, I've said "candidate" for this very reason: To me, every bug
fix is a candidate. Whether risks outweigh the potential benefits is
then influencing whether to _actually_ take the change. A reason to
take it despite the available workaround might be that
"straightforward" doesn't also mean "obvious" here. IOW once you
know what to do, doing so is easy. But one first needs to arrive
there.

Jan