<div dir="ltr"><pre><code>Thanks, that helped a lot.
</code></pre></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 6:34 AM, Timothy Roscoe <span dir="ltr"><<a href="mailto:troscoe@inf.ethz.ch" target="_blank">troscoe@inf.ethz.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Piyus,<br>
<br>
It sounds like you're working within a Unix model of per-process kernel stacks, call-and-return patterns for exceptions, and kernel preemption.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Of course, the source (and documentation) is always available from the web site...<br>
<br>
Best regards,<br>
<br>
-- Mothy<div class="im"><br>
<br>
On 13-08-01 01:46 PM, Piyus Kedia wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hi,<br>
<br>
I am working on Kernel Binary Translator which pushes the translated PC<br>
instead of the original PC on the stack when an interrupt or exception<br>
occurs while executing in kernel mode. There could be some problem if<br>
the interrupt or exception handler uses the PC value pushed on the<br>
stack. Since interrupts are disabled in kernel mode this problem won't<br>
exist. But still some exceptions like page fault can occur in kernel<br>
mode. I just want to make sure that these handlers don't use the PC<br>
value from the stack or don't overwrite the return address on the stack.<br>
<br>
Thanks,<br>
Piyus<br>
<br>
<br>
On Fri, Aug 2, 2013 at 4:20 AM, Timothy Roscoe <<a href="mailto:troscoe@inf.ethz.ch" target="_blank">troscoe@inf.ethz.ch</a><br></div><div class="im">
<mailto:<a href="mailto:troscoe@inf.ethz.ch" target="_blank">troscoe@inf.ethz.ch</a>>> wrote:<br>
<br>
<br>
As Andrew says, the Barrelfish CPU driver processes all exceptions<br>
(whether hardware interrupts or traps) serially with interrupts<br>
disabled, unless it's idling.<br>
<br>
Note that (like K42 and Psyche) Barrelfish uses upcall dispatch most<br>
of the time (think Scheduler Activations), so exit from an exception<br>
handler is typically a jump to a completely different IP/PC value<br>
from when that (or any other) exception occurred.<br>
<br>
Note also that Barrelfish doesn't have any kernel threads - each CPU<br>
driver has a single, static, dedicated kernel stack.<br>
<br>
Could you say a little more about what you mean?<br>
<br>
-- Mothy<br>
<br>
<br>
On 13-08-01 05:32 AM, Piyus Kedia wrote:<br>
<br>
Hi All,<br>
<br>
I am working on dynamic binary translator. Please tell me if anybody<br>
know if in Barrelfish interrupted kernel PC is ever used in<br>
interrupt<br>
handlers?<br>
<br>
Thanks and regards,<br>
Piyus<br>
<br>
<br>
<br>
<br></div>
______________________________<u></u>___________________<br>
Barrelfish-users mailing list<br>
Barrelfish-users@lists.inf.__<a href="http://ethz.ch" target="_blank">e<u></u>thz.ch</a><br>
<mailto:<a href="mailto:Barrelfish-users@lists.inf.ethz.ch" target="_blank">Barrelfish-users@<u></u>lists.inf.ethz.ch</a>><br>
<a href="https://lists.inf.ethz.ch/__mailman/listinfo/barrelfish-__users" target="_blank">https://lists.inf.ethz.ch/__<u></u>mailman/listinfo/barrelfish-__<u></u>users</a><br>
<<a href="https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users" target="_blank">https://lists.inf.ethz.ch/<u></u>mailman/listinfo/barrelfish-<u></u>users</a>><br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>