Re: [patch] x86/efi: use GFP_ATOMIC under spin_lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> 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 linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux