Adam Lackorzynski a écrit :

Hi,

On Wed Nov 17, 2010 at 11:50:29 +0100, BERTRAND Joel wrote:

...

It's my first post on this mailing list. A long time ago, I have started to write a VMS-clone (http://www.freevms.net). This opensourced project was sleeping for a long time because monolithic kernel isn't good enough to write a clone of this system.

Thus, I have restarted this project with a L4 microkernel (exactly pistachio L4/X2). Now, I have written a roottask that tries to launch VMS$INIT, first thread required to boot all system. I have reuse some works done for iguana project (and fixed some bugs).

When VMS$INIT is started, this thread sends two IPC to its pager :

vms$pagefault(addr:1001730, s:8000) [priv=4] -> default addresse is $1001730 (start address of VMS$INIT thread) ... vms$pagefault(addr:47fe8, s:2000) [priv=4]

I'm not sure that I have understand how should work a pager. I have uploaded my pager here :

http://www.freevms.net/trac/browser/sources/freevms/vm/vm_pagefault.c

All sources are available with :

git clone git://rayleigh.systella.fr/FreeVMS.git

and I have uploaded a disk image that runs with qemu (with a x86/64) :

http://www.systella.fr/~bertrand/freevms.img.bz2

My pager tries to find a physical free page to map virtual memory. I think that memory is correctly mapped and I don't understand why pager receives other request with same virtual address. I suppose I have done a mistake.

Given that the first mapping on the code is ok I'd guess the mapping s0->roottask doesn't work and thus no map to the app (check by touching the memory in roottask). I'm not an expert on x2 but maybe you could check whether the mapitem after the sigma0 map call makes sense.

Adam

I have check in http://hg.l4ka.org/l4ka-pistachio-ref/l4-x2.pdf, and I think that mapitem makes sense. When a pagefault occurs, I obtain : vms$pagefault(addr:47fe8, s:2000) [priv=4] memsection 46000 47fff 1 0 V=46000 P=9c000 s0: got msg from 0x0000003a00000001, (0xffffffffc170, 0x0000000000000001, 0x0000000000989680) s0: got msg from 0x0000003a00000001, (0xffffffffffa0, 0x000000000009c0d7, 0x0000000000000000) s0: allocate_page (tid: 0x3a00000001, addr: 9c000, log2size: 13) %MEM-I-ACCMAP, accepting mapping %MEM-I-ACCMAP, virtual $0000000000046000 - $0000000000047FFF %MEM-I-ACCMAP, physical $000000000009C000 - $000000000009DFFF After vms$sigma0_map Thus, virtual region 46000-47FFF is mapped in 9C000-9DFFF memory (and mapping is accepted). Mapitem seems to be required. I'm working on a new web site (because trac takes too CPU time) and new git interface is http://www.freevms.net/gitweb. Trac interface will be removed soon. Regards, JKB

Adam Lackorzynski a écrit :

On Thu Nov 18, 2010 at 19:04:15 +0100, BERTRAND Joel wrote:

...

I have check in http://hg.l4ka.org/l4ka-pistachio-ref/l4-x2.pdf, and I think that mapitem makes sense.

When a pagefault occurs, I obtain :

vms$pagefault(addr:47fe8, s:2000) [priv=4] memsection 46000 47fff 1 0 V=46000 P=9c000 s0: got msg from 0x0000003a00000001, (0xffffffffc170, 0x0000000000000001, 0x0000000000989680) s0: got msg from 0x0000003a00000001, (0xffffffffffa0, 0x000000000009c0d7, 0x0000000000000000) s0: allocate_page (tid: 0x3a00000001, addr: 9c000, log2size: 13) %MEM-I-ACCMAP, accepting mapping %MEM-I-ACCMAP, virtual $0000000000046000 - $0000000000047FFF %MEM-I-ACCMAP, physical $000000000009C000 - $000000000009DFFF After vms$sigma0_map

Thus, virtual region 46000-47FFF is mapped in 9C000-9DFFF memory (and mapping is accepted). Mapitem seems to be required.

3 parties are involved. The faulting program, roottask, and sigma0. As far as I (quickly) read the code: roottask is requesting sigma0 to map memory to 46000 within its own virtual address space. Is this memory accessible by roottask, i.e. can roottask read/write from/to 46000? This is required so that roottask can map it further to other tasks. Also 'virt' seems to be the fpage for the faulting task but is also used for the sigma0 call, i.e. the memory is mapped there in roottask. Might this clash with the roottask virtual memory?

Thanks for your answer. I think I have found one of my problem, but I don't have a running pager. My mistake should be between physical and virtual addresses. I suppose that faulty address in pagefault protocol is a virtual address. A thread tries to access to a unmapped memory. In this pagefault function, I have to find a free memory page. Thus, my function looks for small aligned page that contains requested address. It looks for a free physical page, and sends a mapitem message to faulty thread. My new code is available at: http://www.freevms.net/gitweb/?p=FreeVMS.git;a=blob;f=sources/freevms/vm/vm_... I understand why faulty task sends a pagefault signal. I think my mapitem answer is correct. But I don't understand how assign physical page to virtual one. Regards, JKB

Thanks for your answer, Adam. Adam Lackorzynski a écrit :

...

I suppose that faulty address in pagefault protocol is a virtual address. A thread tries to access to a unmapped memory.

Yes, the fault address is virtual.

OK.

...

In this pagefault function, I have to find a free memory page. Thus, my function looks for small aligned page that contains requested address. It looks for a free physical page, and sends a mapitem message to faulty thread. My new code is available at:

http://www.freevms.net/gitweb/?p=FreeVMS.git;a=blob;f=sources/freevms/vm/vm_...

I understand why faulty task sends a pagefault signal. I think my mapitem answer is correct. But I don't understand how assign physical page to virtual one.

Actually, there aren't any physical addresses really. What's special is that sigma0 has identity mappings (only) and thus for sigma0 a virtual address is same as the corresponding physical address. The same is usually true for the roottask. Now if the app page-faults, the roottask gets this page-fault and needs to send some reasonable mapping back so that the app can continue. For that to work, roottask needs to have that memory available in its task. This mapping basically says map the memory at virtual address soandso in my task to that app at virtual address soandso there. Consequently you need a representation of all the client memory in your roottask, i.e. when you get a page-fault from a client you look up this address in some data structure to find the virtual address in roottask and map it to the app. Initially roottask is getting this memory from sigma0.

I understand what you say but I think that I misunderstand some L4 concepts. Now, I have written a roottask that starts (or tries to start, it depends ;-) ) a new task (init.exe) in new address space. This task is loaded by bootloader and _physically_ mapped as it's mapped by roottask and sigma0. Problem : start init.exe address is outside physical memory and requires virtual memory mapping. Thus, I have written a very simple pagefault handler in roottask. When this thread starts, it sends a pagefault IPC to roottask. Pagefault handler knows required memory, but it needs to associate roottask's memory and I don't see how pagefault can return this memory. For example : physical memory : 0 - 128 M roottask starts at 16 M init.exe starts at 512 M When init.exe starts, it sends a pagefault error to its pager (roottask): -> vms$pagefault(addr:200000b0) [priv=4] and pager must reply with a mapitem message with the _same_ address. I understand that pager has to associate a memory region to virtual address required by init.exe. I know how find an available page to satisfy this request, but I don't know how associate this page to returned memory. Is there anywhere an example ? All pagers I have found only maps physical memory (iguana, darbat...). Regards, JKB

Adam Lackorzynski a écrit :

I guess the fpage for L4_MapItem in vm_pagefault.c should better use the virtual address of the memory to map to the client. As far as I see 'fpage' is constructed by using the pagefault address but should rather use the address that is looked up in roottask. Could that be the 'memsection'? I also think that the 'caller' should play a role when doing the lookup so that the same virtual addresses of different clients result in different memsections to be returned.

I'm writing a new pager that shall map virtual memory. This work is in progress but I have another question. I have to write a protocole to handle virtual memory and this protocol uses StringItem. I cannot send any StringItem and I don't understand why this IPC hangs. Minimal example : rtl$sprint(&str, fmt, arg); si = L4_StringItem(str.length_trim, (void *) str.c); L4_Clear(&msg); L4_Append(&msg, si); L4_Set_Label(&msg, 1); L4_Load(&msg); L4_KDB_Enter("pager"); L4_Call(L4_Pager()); L4_KDB_Enter("pager"); (file is downloadable at http://www.freevms.net/gitweb/?p=FreeVMS.git;a=blob;f=sources/freevms/librtl...) When I start kernel in virtualbox, I obtain: sys$pagefault(addr=200110 caller=3c00000001) sys$pagefault(ref=2a31) sys$pagefault(addr=10dff8 caller=3c00000001) sys$pagefault(ref=29d1) sys$pagefault(addr=201490 caller=3c00000001) sys$pagefault(ref=2a31) --- "pager" --- --------------------------------- (eip=00000000002002d1, esp=000000000010d8b8) -

showtcbext

... mr(00): 0000000000010080 0000000000006400 000000000010d8b8 ... Message Tag: 0 untyped, 2 typed, label = 1, flags = ---- string item: len=19, num=1, cont=0, cache=0 StringItem seems to be good (I have checked that buffer contains correct values).

go

sys$pagefault(addr=0 caller=3c00000001) %MEM-F-MEMSEC, no memory section Halting a thread with ongoing kernel operations is not supported--- "KD# UNIMPL- --------------------------------- (eip=ffffffffc080c92d, esp=ffffffffc0a8edd0) - Thus, L4_Call(L4_Pager()) raises a pagefault. And faulty address is 0x0 ! Why ? Regards, JKB