[Barrelfish-users] Registering a Specific IRQ on x86

Dominic Hung domchdh at hku.hk
Wed Aug 20 19:54:08 CEST 2014

Dear Andrew and Kornilios,


I have successfully used the mentioned method to register a timer for
user-mode interrupt. Just to share the method is okay for the record. A
reminder to other user, the interrupt number throw into the
inthandler_setup_arm is the interrupt vector - NEXCEPTIONS.

Thank you for helping!

Dominic Hung

On 6 August 2014 20:56, Dominic Hung <domchdh at hku.hk> wrote:

> Dear Andrew and Kornilios,
> Thanks for your comments.
> For registering specific interrupt,
> I resolved to use the inthandler_setup_arm() instead of the
> inthandler_setup() as I traced down, the codes differs only with, on the
> inthandler_setup_arm() function, the interrupt vector is assigned by the
> user and the general function, i.e., inthandler_setup() is assigned by the
> system.
> {barrelfish_source_root}/lib/barrelfish/inthandler.c:
> inthandler_setup_arm()
> --> calls arm_allocirq()
> --> --> calls arm_irq_handle()
> and arm_irq_handle() actually triggers
> {barrelfish_source_root}/usr/monitor/monitor_rpc_server.c:
> arm_irq_handle_call()
> --> calls invoke_irqtable_set()
> The difference between irq_handle_call() and arm_irq_handle_call() is
> nothing but just irq_handle_call() having next_vector for assigning
> interrupt vector by the system. They will call invoke_irqtable_set() all
> the same.
> I am sorry that I have to use this hack to workaround. My apologies if you
> two are fundamentalist and accepts no abuse when the function is named
> "arm_".
> -----
> For hacking the timer interrupt mechanism,
> The reason to use the timer interrupt is that I am working with a system
> level research work. And I require a periodic timer interrupt probably
> shorter than the normal timeslice. And all the best I perceive, the
> deferred event is only fired when dispatch() runs, and with no accuracy, it
> only fires at least after a certain period of time. For instance, if I
> register a deferred event of 400ms, the mechanism promises firing the event
> after 400ms, and it may be in reality 500ms, 550ms with no guarantee. My
> apologies in advance, please correct me if I understand the deferred event
> wrongly.
> I have resolved to work on a "a little bit" nusty hack, by adding
> conditions to the timer module which essentially "multiplex" the timer.
> Say, if I want a 50ms periodic timer interrupt, and the kernel timeslice
> remains 200ms, I will register the APIC timer interrupt duration to be 50ms
> and calls send_user_interrupt() at every firing of the APIC interrupt, with
> the 4th interrupt calls the scheduler. I hope this hack will have the
> requirement fulfilled in a minimalist manner.
> I do understand from the literature of barrelfish that the design of the
> deferred event and an operating system without timer interrupt is to make
> sure the programmer hands off those asynchronous event and handle them in a
> more orderly manner. But we need the timer interrupt for the project, and
> so the trick.
> -----
> I haven't finish the whole thing and I will get back to you if the whole
> thing runs as I desire. Thank you very much!
> Cheers,
> Dominic Hung
> On 6 August 2014 00:15, Andrew Baumann <Andrew.Baumann at microsoft.com>
> wrote:
>> 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.
>> Cheers,
>> Andrew
>> -----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:
>> lib/barrelfish/inthandler.c:
>>  - inthandler_sertup() calls allocirq()
>>  - allocirq() makes an irq_handle request to the monitor
>> user/monitor/monitor_rpc_server.c
>>  - 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,
>> Kornilios.
>> >
>> > 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
>> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
> --
> 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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20140821/d4b7b8cd/attachment.html 

More information about the Barrelfish-users mailing list