[Barrelfish-users] Registering a Specific IRQ on x86

Andrew Baumann Andrew.Baumann at microsoft.com
Tue Aug 5 18:15:50 CEST 2014

Hi all,

I just noticed this thread... I have two quick comments.

The x86 interrupts interface was designed with the assumption that only the legacy PIC/ISA interrupts (IRQ <= 15) would need to be registered explicitly; everything else should be routable via IOAPICs etc. and ACPI configuration, and discovered via PCI enumeration. So, as Kornilios suggests, if you have a real use-case for handling a specific CPU interrupt vector, that will need changes to the monitor interface.

However, what you want to do won't work (I think). The kernel uses the local APIC timer for its own purposes (scheduling and timeouts), so you won't be able to handle that from user-space, even if you hack the monitor to register a handler for it. I suggest you rethink what you're trying to do... if you just need a source of time, look at the deferred events mechanism which is the architecture-independent way of getting at a local timer.


-----Original Message-----
From: Kornilios Kourtis [mailto:kornilios.kourtis at inf.ethz.ch] 
Sent: Tuesday, 5 August 2014 07:51
To: Dominic Hung
Cc: barrelfish-users at lists.inf.ethz.ch
Subject: Re: [Barrelfish-users] Registering a Specific IRQ on x86

Hi Dominic,

On Wed, Jul 23, 2014 at 09:03:54PM +0800, Dominic Hung wrote:
> Dear Sir/Madam,
> I am writing to make a query in how to register a interrupt to a specific IRQ#.
> I notice that for registering an IRQ in x86 setting, the function errval_t
> inthandler_setup(interrupt_handler_fn handler, void *handler_arg, uint32_t
> *ret_vector) merely allows one to register a function without control which IRQ
> # the request will finally associated with.
> For some specific needs, I need to register an interrupt to a LAPIC IRQ, i.e.,
> IRQ# >= 249. How can I do that? With an extra sys_syscall to
> handle_irq_table_set? If so, can you shed me some light as to how I can get the
> endpoint created when I ran the inthandler_setup earlier on?

Many apologies for the delayed reply. I'm not sure if you have resolve
this at this point, but from what I can tell this is what the code does:

 - inthandler_sertup() calls allocirq()
 - allocirq() makes an irq_handle request to the monitor

 - irq_handle_call() calls invoke_irqtable_setup() so that the kernel can
   setup a particular irq vector.

In our current tree, the monitor manages interrupts with a single
integer, which is bumped when a new request is made.  This is obviously
not the best way to do things ;) and we have a version where we actually
split the process into two parts: allocating a vector and setting up the
channel for that particular vector. I'm hoping that we will be able make
a release with this version of the code soon.

If you want to allocate a particular vector, though, the simplest way
from our current tree is probably to augment the monitor interface to
accept some preference from the requesting domain about the IRQ number.
Depending on how much general you want your solution to be, you might
want to modify the way monitor keeps track of the assigned interrupts
(e.g., use a bitmask instead of a single integer).

Hope this helps,

> Thanks!
> Cheers,
> Dominic Hung
> --------------------------------------------------
> C H Dominic Hung, B.Eng. (CE) HK
> M. Phil. Student, Dept. of CS., Faculty of Engg.
> Mobile: +852-9819-9360
> Email: domchdh at hku.hk

> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users

Kornilios Kourtis

Barrelfish-users mailing list
Barrelfish-users at lists.inf.ethz.ch

More information about the Barrelfish-users mailing list