[Barrelfish-users] Registering a Specific IRQ on x86

Wed Aug 6 14:56:14 CEST 2014

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