l4-hackers February 1999

l4-hackers@os.inf.tu-dresden.de

10 participants
14 discussions

RE: L4 Mapping question
by vuhlig＠us.ibm.com 22 Feb '99

22 Feb '99

Hi Robert, there is one mapping entry per associated page per address space. that means, if you map a page to 2 address spaces you need 2 mappings. The current L4 version allocates the mappings statically (currently 5 entries per frame, but this is configurable at startup time). The idea is, that the kernel can revoke pages from sigma 0, what is not implemented yet. I don't see the case, where you want to map a lot of pages into all address spaces. Furthermore is your calculation not right. You can map a page to multiple address spaces multiple times (at different virtual addresses) - so there is no limit of needed mapping-entries per page. Volkmar

1 0

RE: L4 Mapping question
by Robert Kaiser 22 Feb '99

22 Feb '99

Volkmar, Thanks very much for your response ! On Mon, 22 Feb 1999, Volkmar Uhlig wrote: > The bookkeeping is done by the kernel. this is necessary, because the > sender (e.g. pager) does not know, if the receiver of the page maps it to > other address spaces. Therefore the flush operation must be asynchronus. > Example: A is pager and maps a page to B. B maps it to C, D, E, and F. if A > flushes the page, it is removed from B, C, D, E and F. So, multiple mappings are in fact possible (that's what I wanted to know). I was aware that the bookkeeping would have to be in the kernel, otherwise flush couldn't work as described in the manual. Only, how does it work ? Theoretically, each task could map each of it's pages to up to 2047 other tasks. So, the kernel would need to maintain ~2K entries per mapped page and task. This can't be! The only explanation I can think of right now is that the kernel allocates room for entries dynamically, assuming that the actual number of required entries will always be far less than the theoretical limit. But that would mean you can break the system simply by doing a big enough number of mappings. > In the current L4-implementation of Jochen Liedtke, one mapping entry is 16 > Bytes.The Alpha implementation (done by me) needs 32 Bytes per entry (64 > bit address space - and a lot of trix). The Fiasco kernel does not use > lists. They need about 4 Bytes per entry + an some overhead per frame (I > left bevore it was finished) > I am getting the distinct feeling that I am missing something very simple :-(. So, at the risk of looking like a complete fool: How do you keep track of up to 2K tasks in a 16 Byte entry ? Thanks for your response Rob ---------------------------------------------------------------- Robert Kaiser email: rkaiser(a)sysgo.de SYSGO RTS GmbH Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80 D-55129 Mainz / Germany fax: (49) 6131 9138-10

1 0

Re: Deceiving IPC question: Bug or Feature?
by Michael Hohmuth 03 Feb '99

03 Feb '99

gernot(a)cse.unsw.edu.au writes: > We have noticed the following re deceiving IPC in L4/MIPS. > > Assume task A is the chief of task B, which is the chief of task C. aa > is a thread in A, bb a thread in B, cc a thread in C. > > aa does a closed receive from bb. bb sends a deceiving message to aa > with cc as the virtual sender. aa receives the message (although the > virtual sender is different from the source specified in the > receive). The kernel returns to aa the virtual sender specified by bb > (i.e., cc), but the C bindings discard this information, so aa cannot > see it using the C interface. > > If in the otherwise identical situation aa does a closed receive from cc > it does NOT receive the message. > - is this the correct behaviour? I think this should be reversed: aa should receive the message in the second scenario, but not in the first. > - do all L4 versions show this behaviour? We never really used deceiving IPC with L4/x86 version 2 because it was broken, and I don't know about Jochen's version 3 or L4/Alpha. In Fiasco, deceiving IPC hasn't been implemented yet; it's not a priority for us right now. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Deceiving IPC question: Bug or Feature?
by gernot＠cse.unsw.edu.au 02 Feb '99

02 Feb '99

We have noticed the following re deceiving IPC in L4/MIPS. Assume task A is the chief of task B, which is the chief of task C. aa is a thread in A, bb a thread in B, cc a thread in C. aa does a closed receive from bb. bb sends a deceiving message to aa with cc as the virtual sender. aa receives the message (although the virtual sender is different from the source specified in the receive). The kernel returns to aa the virtual sender specified by bb (i.e., cc), but the C bindings discard this information, so aa cannot see it using the C interface. If in the otherwise identical situation aa does a closed receive from cc it does NOT receive the message. My questions: - do all L4 versions show this behaviour? - is this the correct behaviour? Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser(a)unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint = 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers February 1999