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

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

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.

Ian.