>>> On 10.03.14 at 08:53, Ingo Molnar <mingo@xxxxxxxxxx> wrote: >> [...] Remember the far from insignificant number of issues with the >> ACPI interrupt source overrides for particularly the timer interrupt >> years ago? Which wasn't a reason to stop trying to use ACPI wherever >> possible, even on affected systems (by introducing command line >> overrides). > > That's an apples to oranges comparison IMO, the motivation for that > was real on real systems: to get high(er) resolution time and > interrupt sources. What has that got to do with getting higher resolution? IRQ0 is IRQ0, irrespective whether driven by an 8254 or a HPET. The workaround was needed to get IRQ0 to work properly _at all_. > What's the upside here, for existing systems? Please don't mistake me: > if an upside exists I'm not against it, at all. The upside isn't so much on existing systems that work with the intended model, but on those that don't: Increasing awareness and pressure on the firmware vendors' side to get their bugs fixed. Just like - afaict - the ratio of systems with broken ACPI tables has gone down over time. Just to give an example from the Xen side: Xen uses the time interface in UEFI, as you would expect not without problems. Apart from issues with memory areas needed by those runtime calls not being properly marked for runtime use (which the respective vendors accepted they need to fix), we are also facing problems with runtime calls using XMM registers. Rather than blindly saying "the specification isn't precise on this, and e.g. Linux has a half baked mechanism to deal with this, so let's just do so too" we're pushing for the specification to get updated, such that it becomes clear whether the firmware may do so and we need to change Xen, or whether it's the firmware people needing to fix their implementation. Doing it that way is cumbersome, yes, but I think it is in the best interest of everybody involved (and better than papering over bugs by avoiding certain functionality). And yes, should such a machine reach customer hands, and should we get reports that there's no way for them to boot it with Xen, we can always add a command line override telling the hypervisor to avoid the broken runtime service and use direct CMOS accesses instead. The approach you lobby - avoid the runtime service by default - will just result in further delaying the fixing of the firmware bugs. (The one real upside - getting time zone information - was already mentioned by someone else on this thread.) Jan -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
