On 10/1/2015 10:26 PM, Richard Henderson wrote:
On 10/02/2015 11:31 AM, Chris Metcalf wrote:
It disables interrupts from being delivered. This means asynchronous
interrupts get deferred until ICS is set back to zero, and synchronous
interrupts (page fault, etc) cause a double-fault instead. ICS is automatically
set on entry to interrupt handlers, so the handler has time to acquire any
information about the interrupt from SPRs, and it is expected that ICS is
cleared as soon as possible. ICS can also be used before returning from
interrupts if you need to do something like adjust the interrupt mask prior to
returning.
Which is all very well and good for supervisor mode... but what's it good for
in user mode?
In user-space it is primarily useful for userspace drivers that are receiving
device interrupts. You can also configure to receive performance counter
interrupts in userspace. The bottom line is that is indeed a rarely-used
feature.
I was about to quote you from 2012 (https://lkml.org/lkml/2012/3/30/994):
In general we want to avoid ever touching memory while within an
interrupt critical section, since the page fault path goes through
a different path from the hypervisor when in an interrupt critical
section, and we carefully decided with tilegx that we didn't need
to support this path in the kernel.
Which implies that tilegx userland does nothing at all with ICS, and is in fact
unsupported?
This refers to the kernel's own use of the interrupt critical section, i.e.
having that SPR set while running at PL2. Each protection level (PL) has its
own ICS. So the text you quoted is orthogonal to userspace use of ICS.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
