Hi,
[Kevin: please have a look at the bochs panic below: What's wrong with
writing non-zero to CR4 when --enable-cpu-level=5 is mentioned? Is there
a quick workaround to this problem? Thanks.]
I'm trying to run l4ka under bochs but I'm still fighting with some
bochs panic()s. This is what I've found out so far:
1. 3 modules _must_ be attached to rmgr, so that the assertion in startup()
about the number of modules doesn't bite.
2. I used the following grub startup commands thru all following tests
(bochs simulates disk C: from a 112M bytes regular file):
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> kernel (hd0,0)/l4ka/rmgr.debug -sigma0
[Multiboot-elf, <0x111000:0x20734:0x0>, <0x132740:0x48c:0xfcc8>,
entry=0x111000]
grub> module (hd0,0)/l4ka/x86-kernel
[Multiboot-module @ 0x143000, 0x12769 bytes]
grub> module (hd0,0)/l4ka/sigma0
[Multiboot-module @ 0x156000, 0x287a bytes]
grub> module (hd0,0)/l4ka/glinux
[Multiboot-module @ 0x159000, 0x143dd4 bytes]
grub> boot
rmgr.debug is just original rmgr binary, with another name.
I tried to slightly modify rmgr in later steps...
rmgr[.debug], x86-kernel and sigma0 were compiled on FreeBSD
without problems. Note: compiled for 586, not 686!. They are not
stripped. I was not able to compile linux22 from Dresden on FreeBSD,
so I just used the binary 'glinux' from your distribution.
3. Without any modifications to the l4-ka sources, bochs panic()s right after
displaying the message: check_l4_version 0x00100000 to 0x0011041c
with the following error message:
MOV_RdCd: read of CR4
MOV_CdRd: ignoring write to CR4 of 0x00000010
bochs: panic, MOV_CdRd: (CR4) write of 0x00000010
protected mode
CS.d_b = 32 bit
SS.d_b = 32 bit
| EAX=00000010 EBX=ff000000 ECX=0010f40f EDX=0010a000
| ESP=0010f3f7 EBP=00109000 ESI=f0109000 EDI=00109000
| IOPL=0 NV UP DI PL NZ NA PO NC
| SEG selector base limit G D
| SEG sltr(index|ti|rpl) base limit G D
| DS:0010( 0002| 0| 0) 00000000 000fffff 1 1
| ES:0010( 0002| 0| 0) 00000000 000fffff 1 1
| FS:0010( 0002| 0| 0) 00000000 000fffff 1 1
| GS:0010( 0002| 0| 0) 00000000 000fffff 1 1
| SS:0010( 0002| 0| 0) 00000000 000fffff 1 1
| CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
| EIP=0010fa55 (0010fa52)
>> 77875018 0f77875018 2277875018 e077875018 : mov CR4, EAX
bochs was not able to grok the instruction: mov CR4, EAX
(that is EAX -> CR4).
I compiled bochs-2000_0325a with the following options:
./configure --enable-cpu-level=5 \
--enable-disasm --enable-vga --enable-fpu \
--enable-x86-debugger
Support for x86-debugger (DR? registers etc...) is therefore enabled.
Looking at the source code of bochs-2000_0325a, file cpu/proc_ctrl.cc
says in function void BX_CPU_C::MOV_CdRd(BxInstruction_t *i):
[...]
case 4: // CR4
#if BX_CPU_LEVEL == 3
bx_panic("MOV_CdRd: write to CR4 of 0x%08x on 386\n",
val_32);
UndefinedOpcode(i);
#else
// Protected mode: #GP(0) if attempt to write a 1 to
// any reserved bit of CR4
bx_printf("MOV_CdRd: ignoring write to CR4 of 0x%08x\n",
val_32);
if (val_32) {
bx_panic("MOV_CdRd: (CR4) write of 0x%08x\n",
val_32);
}
// Only allow writes of 0 to CR4 for now.
// Writes to bits in CR4 should not be 1s as CPUID
// returns not-supported for all of these features.
BX_CPU_THIS_PTR cr4 = 0;
#endif
break;
[...]
So bochs doesn't allow writing 0x00000010 (non-zero) to CR4
for now.
To Kevin: Why?
To Uwe: Can we avoid having to write to CR4 for now?
4. I tried to localize the exact position of that instruction in l4-ka
by adding the following MYDEBUG macro to halt execution before
bochs panic()s:
#ifndef MYDEBUG
#define MYDEBUG(str) { printf(str); for(;;) ; }
#endif
this helped to track down at least portions of the code that were
definitely executed by bochs, as well as to see the output. This is
what I've found out so far:
4.1. control definitely reaches the end of
l4-ka/apps/rmgr/src/startup.c:startup(),
at least just before the final:
asm volatile
("pushl $" SYMBOL_NAME_STR(exit)"\n"
"pushl %2\n"
"ret\n"
: /* no output */
: "a" (MULTIBOOT_VALID), "b" (&l4_mbi), "r" (exec_info.entry));
/*NORETURN*/
This is the output in bochs:
RMGR: loading (hd0,0)/l4ka/sigma0
check_l4_version 0x00100000 to 0x0011041c
RMGR: detected L4-Karlsruhe
find kernel info page...
found kernel info page at 0x00107000
configuring s0: (0x00200000, 0x00213000), start: 0x00200000
s0 config: 0x00200000,0x00000000,0x00200000,0x00213000
RMGR: reserve modules memory range: 156000 to 29cdd4
RMGR: starting (hd0,0)/l4ka/x86-kernel @ 0x0010f000
>>>> rmgr.debug:startup() just before asm volatile... at end of function.
4.2. control doesn't reach even the very beginning of
l4-ka/apps/rmgr/src/init.c:init() where I've put the next
MYDEBUG call. bochs panic()s with the same error message
as before (ignoring write to CR4 of 0x00000010: mov CR4, EAX).
Uwe, where does startup() exactly jumps to? I thought it was rmgr's init()???
Thanks,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
