[Barrelfish-users] Fwd: Interrupt Handlers
Piyus Kedia
piyuskedia at gmail.com
Fri Aug 2 10:22:37 CEST 2013
Thanks, that helped a lot.
On Fri, Aug 2, 2013 at 6:34 AM, Timothy Roscoe <troscoe at inf.ethz.ch> wrote:
> Piyus,
>
> It sounds like you're working within a Unix model of per-process kernel
> stacks, call-and-return patterns for exceptions, and kernel preemption.
>
> The Barrelfish kernel is different: it is more of a set of short event
> handlers which run with interrupts disabled, do not generate exceptions, do
> not return (the stack is discarded, not necessarily unwound) and instead
> jump at a continuation when they're done. They execute serially. The
> kernel cannot take a page fault, as it never accesses virtual memory that
> might be paged out, and cannot be handed a user reference to non-existent
> memory.
>
> When the kernel is entered from user mode (whether due to an interrupt or
> a user trap), the userspace execution context (including the PC) is saved
> in the dispatcher (think: process) control block. This PC value *is* (in
> some versions of Barrelfish, I think) inspected by the kernel to determine
> the dispatcher's state - within a particular range of addresses.
>
> In the common case, this PC address is not returned to when the process is
> rescheduled; instead the kernel initiates an upcall to a different
> continuation in the dispatcher, and the thread can then be resumed in user
> space. Consequently, it's pretty important that this value isn't changed
> by the kernel, but it is always the address of a userspace instruction.
>
> It might help us to answer your question if we understood the assumptions
> (independent of OS design choices) that you want to verify hold in
> Barrelfish.
>
> Of course, the source (and documentation) is always available from the web
> site...
>
> Best regards,
>
> -- Mothy
>
>
> On 13-08-01 01:46 PM, Piyus Kedia wrote:
>
>> Hi,
>>
>> I am working on Kernel Binary Translator which pushes the translated PC
>> instead of the original PC on the stack when an interrupt or exception
>> occurs while executing in kernel mode. There could be some problem if
>> the interrupt or exception handler uses the PC value pushed on the
>> stack. Since interrupts are disabled in kernel mode this problem won't
>> exist. But still some exceptions like page fault can occur in kernel
>> mode. I just want to make sure that these handlers don't use the PC
>> value from the stack or don't overwrite the return address on the stack.
>>
>> Thanks,
>> Piyus
>>
>>
>> On Fri, Aug 2, 2013 at 4:20 AM, Timothy Roscoe <troscoe at inf.ethz.ch
>> <mailto:troscoe at inf.ethz.ch>> wrote:
>>
>>
>> As Andrew says, the Barrelfish CPU driver processes all exceptions
>> (whether hardware interrupts or traps) serially with interrupts
>> disabled, unless it's idling.
>>
>> Note that (like K42 and Psyche) Barrelfish uses upcall dispatch most
>> of the time (think Scheduler Activations), so exit from an exception
>> handler is typically a jump to a completely different IP/PC value
>> from when that (or any other) exception occurred.
>>
>> Note also that Barrelfish doesn't have any kernel threads - each CPU
>> driver has a single, static, dedicated kernel stack.
>>
>> Could you say a little more about what you mean?
>>
>> -- Mothy
>>
>>
>> On 13-08-01 05:32 AM, Piyus Kedia wrote:
>>
>> Hi All,
>>
>> I am working on dynamic binary translator. Please tell me if
>> anybody
>> know if in Barrelfish interrupted kernel PC is ever used in
>> interrupt
>> handlers?
>>
>> Thanks and regards,
>> Piyus
>>
>>
>>
>>
>> ______________________________**___________________
>> Barrelfish-users mailing list
>> Barrelfish-users at lists.inf.__e**thz.ch <http://ethz.ch>
>> <mailto:Barrelfish-users@**lists.inf.ethz.ch<Barrelfish-users at lists.inf.ethz.ch>
>> >
>> https://lists.inf.ethz.ch/__**mailman/listinfo/barrelfish-__**
>> users <https://lists.inf.ethz.ch/__mailman/listinfo/barrelfish-__users>
>> <https://lists.inf.ethz.ch/**mailman/listinfo/barrelfish-**users<https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users>
>> >
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20130802/b843b46b/attachment.html
More information about the Barrelfish-users
mailing list