Believe it or not, I'm converging, but I'm trying to do it respectfully, which means asking an unreasonable number of stupid questions at high speed. :-)
Now that I understand the shape of GPTs, I would like to understand the *mechanism* of the map operation. In particular, I would like to understand how the book-keeping mechanism works.
It may be that this has been written up, and that I just haven't found it -- appearances notwithstanding, you guys collectively write faster than I do alone :-)
Bootstrap conditions:
1. When a new, virgin, never-before-used task is created, can it have a completely empty address space, or is an initial flexpage required as an argument to the task-create operation? I'm trying to learn whether a null address space pointer is ever a conceptually valid thing for a task to have.
Map operation:
2. Suppose a sender maps a single page to a recipient task, and the corresponding recipient address was previously undefined. What data structures get constructed in the recipient's GPT?
I am *guessing* that the answer is: the recipient GPT tree is expanded by inserting GPT nodes until a slot can be contrived into which *something* can be placed that reflects the existence of the new mapping. I would like to know what the *something* is. In particular, is it a GPT whose type is 'alias'?
3. In order to support the unmap operation, some book-keeping data structure is needed in which all of the derived mappings can be discovered. Can someone describe for the x86 what book-keeping structures are created at the time of the "map", and how they are used at the time of the "unmap"? I think this may be the MapDB that someone mentioned earlier. I've had a hard time getting a clear understanding of that.
I ask about x86 only because it is the machine that is most current in my mind. Also, please note that I am *not* trying to ask how the hardware addressing structure gets built -- I can think of several ways to handle that.
Thank you!
shap
On 05 Dec 2003 13:49:02 -0500, "Jonathan S. Shapiro" shap@eros-os.org said:
JSS> Believe it or not, I'm converging, but I'm trying to do it respectfully, JSS> which means asking an unreasonable number of stupid questions at high JSS> speed. :-)
JSS> Now that I understand the shape of GPTs, I would like to understand the JSS> *mechanism* of the map operation. In particular, I would like to JSS> understand how the book-keeping mechanism works.
Hi Jon,
It seems that you're under a bit of a misconception here. GPTs are a pure implementation issue as far as L4 is concerned. In fact, most existing L4 implementation _don't_ use GPTs. AFAIK the only released versions of L4 that implemented GPTs were the (discontinued) V2 MIPS and Alpha kernels. And both of these used only a single, fixed node size.
On architectures with hardware-loaded TLBs L4 uses the HW page table format only.
Chris here at UNSW has designed and implemented a more general version of the GPT which we call the variable radix page table (VRPT). The implementation is (AFAIK) the first with really adaptive nodes, combined with some strategies for splitting and merging (plus support for superpages). He also handles the guard checking differently, doing an optimistic traversal and only check for correctness of translation at the end.
It's been originally implemented in an experimental kernel and is presently being ported to Pistachio.
I'll leave answering your specific questions to those who actually know the implementation ;-)
Gernot
On Fri, 2003-12-05 at 16:49, Gernot Heiser wrote:
On 05 Dec 2003 13:49:02 -0500, "Jonathan S. Shapiro" shap@eros-os.org said:
JSS> Believe it or not, I'm converging, but I'm trying to do it respectfully, JSS> which means asking an unreasonable number of stupid questions at high JSS> speed. :-)
JSS> Now that I understand the shape of GPTs, I would like to understand the JSS> *mechanism* of the map operation. In particular, I would like to JSS> understand how the book-keeping mechanism works.
Hi Jon,
It seems that you're under a bit of a misconception here. GPTs are a pure implementation issue as far as L4 is concerned....
Thanks, Gernot. Shortly after posting the question, I had a brief phone discussion with Volkmar, which cleared this up for me.
shap
l4-hackers@os.inf.tu-dresden.de