[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 1/6][4.16?] x86/x2APIC: defer probe until after IOMMU ACPI table parsing
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.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |