RE: Checking executables before running them in L4re/fiasco
Hey Adam,
Yes, I explicitly made sure that there are no extra characters by setting the
entire page of 4096 bytes to zero before copying over the new config. I am not
sure what you mean by changed the target - I simply replace the config file. So
I thought it picks up the size information from the MBI header.
I will try the MODE option as you mentioned it. I misunderstood it earlier.
Thanks,
Ramya
From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Adam
Lackorzynski [a...@os.inf.tu-dresden.de]
Sent: 08 September 2014 00:03
To: l4-hackers@os.inf.tu-dresden.de
Subject: Re: Checking executables before running them in L4re/fiasco
Hi,
On Fri Sep 05, 2014 at 12:29:15 +, Masti Ramya Jayaram wrote:
Thanks for the information. I have two issues/questions:
a. I looked at the move_modules (which does not do much in my case) and I
tried to replace the linux.cfg from
Compiled in version:
--
--vim:set ft=lua:
L4.default_loader:start({ caps = {
log = L4.Env.log:m(rws),
},
l4re_dbg = L4.Dbg.Warn,
log = { l4linux, yellow },
}, rom/vmlinuz mem=128M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1);
Replaced version: (just the memory changes but this results in a difference
in the length!)
---
--vim:set ft=lua:
L4.default_loader:start({ caps = {
log = L4.Env.log:m(rws),
},
l4re_dbg = L4.Dbg.Warn,
log = { l4linux, yellow },
}, rom/vmlinuz mem=64M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1);
I achieve this with the following code that runs immediately after
construct_mbi:
a. Copy the placed version into the start address of the linux_cfg
module (this happens correctly as I can see the memory dump).
b. Change the compressed and uncompressed lengths in mod_info to
reflect the smaller size.
The process runs until ned which fails to parse the config file
(unexpected symbol error) and the problem seems to be the difference
in length of the two configs. For example, if the 2nd config is
mem=064M instead of mem=64M, then it works. I change the length
appropriately in mod_info of the mbi. What am I missing?
When you already changed the target, changing the size variables
probably won't make a difference. Did you clear out the old contents? I
think you have remaining characters in the file that are interpreted and
causing the error.
a. The MODE = sigma0 suggestion: I tried this by changing
bootstrap/server/src/Make.rules but I get an error saying: ld: cannot
find -ll4util. The relevant part in the linker line that differs from
the default working build (with MODE = lib) is:
Wait. I meant the MODE=sigma0 for newly created programs. If you want to
make bootstrap smaller, you need to remove code/features from it.
Adam
--
Adam a...@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
RE: Aborted L4linux due to CLI/STI
Hey Adam, That's ok as long it's also ok for native Linux. I am not sure what they did with native Linux but I know from the SCC forums that these instructions do not exist. So I guess that is ok. I'm wondering how did you end up with the code containing the cli? In L4Linux this part is replaced. Well, I am not sure about that. I did force a couple of options though as I already mentioned. The reason was that when I tried to compile L4linux for pentium/i586, I saw that it would complain about CONFIG_X86_CMPXCHG64 not being enabled (this corresponds to the PAE option). So I disabled this explicitly since the processors on the SCC do not contain PAE. I also disabled the CONFIG_X86_CMPXCHG and CONFIG_CMPXCHG_LOCAL options. Attached is my l4linux config. Just as a note, I am using quite an old build of L4linux. Do you know of any related bugs? Thanks, Ramya From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Adam Lackorzynski [a...@os.inf.tu-dresden.de] Sent: 08 September 2014 00:29 To: l4-hackers@os.inf.tu-dresden.de Subject: Re: Aborted L4linux due to CLI/STI On Fri Sep 05, 2014 at 16:21:34 +, Masti Ramya Jayaram wrote: I forgot to mention that it also does not support the traditional cmpxchg instructions using the lock line. That is why I disabled it. That's ok as long it's also ok for native Linux. On 05 Sep 2014, at 18:16, Masti Ramya Jayaram rma...@inf.ethz.ch wrote: Dear all, I get an error during L4linux boot when I enter the debugger (using ESC) and resume: Aborted L4linux due to CLI/STI at 0x534911. When I disassemble this using gdb: (gdb) disassemble 0x534911 Dump of assembler code for function cmpxchg8b_emu: 0x00534910 +0:pushf 0x00534911 +1:cli 0x00534912 +2:cmp(%esi),%eax 0x00534914 +4:jne0x534922 cmpxchg8b_emu+18 0x00534916 +6:cmp0x4(%esi),%edx 0x00534919 +9:jne0x534924 half_same 0x0053491b +11:mov%ebx,(%esi) 0x0053491d +13:mov%ecx,0x4(%esi) 0x00534920 +16:popf 0x00534921 +17:ret 0x00534922 +18:mov(%esi),%eax 0x00534924 +0:mov0x4(%esi),%edx 0x00534927 +3:popf 0x00534928 +4:ret When I built l4linux, I had to disable CONFIG_X86_CMPXCHG, CONFIG_CMPXCHG_LOCAL and CONFIG_X86_CMPXCHG64 despite building for the Pentium because my processor does not support PAE (which is the option that enables this). I am guessing This is the reason it tries to emulate the CMPXCHG instructions. What is the correct l4linux configuration to use for a machine that does not support any of the atomic instructions like CMPXCHG8, ATOMIC, etc.? Which processor type did you select? In L4Linux, there's an adapted version of the cmpxchg8b_emu code that is enabled if CONFIG_X86_CMPXCHG64 is not set. I'm wondering how did you end up with the code containing the cli? In L4Linux this part is replaced. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers# # Automatically generated make config: don't edit # Linux/l4 2.6.38-l4 Kernel Configuration # Fri Sep 5 02:47:55 2014 # # # L4Linux configuration # CONFIG_L4=y CONFIG_L4_LINUX=y CONFIG_L4_OBJ_TREE=/home/rmasti/fiasco/r33-new/src/l4/build CONFIG_L4_ARCH_X86=y # CONFIG_L4_ARCH_ARM is not set CONFIG_L4_VMLINUZ_SUFFIX= CONFIG_HZ=100 CONFIG_PHYSICAL_START=0x0 # # Features # # CONFIG_L4_SERVER is not set # # IRQ Handling # # CONFIG_L4_IRQ_SINGLE is not set CONFIG_L4_IRQ_MULTI=y # # Stub drivers # CONFIG_L4_EXTERNAL_RTC=y CONFIG_L4_BLK_DS_DRV=y CONFIG_L4_CHR_DS_DRV=y # CONFIG_L4_FB_DRIVER is not set # CONFIG_L4_NET_ANKH_DRV is not set # CONFIG_L4_NET_L4SHM is not set CONFIG_L4_SERIAL=y CONFIG_L4_SERIAL_CONSOLE=y # CONFIG_L4_SERIAL_SHM is not set # # Debugging options # # CONFIG_L4_DEBUG is not set # # Advanced options # CONFIG_L4_MEMSIZE=32 CONFIG_L4_TAMED=y # CONFIG_L4_VCPU is not set # # Priority configuration # CONFIG_L4_PRIO_SERVER_PROC=1 CONFIG_L4_PRIO_IDLER=2 CONFIG_L4_PRIO_IRQ_BASE=3 CONFIG_L4_PRIO_TAMER=22 CONFIG_L4_PRIO_L4FB_INPUT=7 CONFIG_L4_PRIO_L4FB_REFRESH=7 CONFIG_L4_PRIO_L4ANKH=7 CONFIG_L4_CONFIG_CHECKS=y # CONFIG_L4_SAMPLE_MODULE is not set # # # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_NEED_DMA_MAP_STATE is not set CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y
Re: Question about dec_lock_cnt method in Context class
Unfortunately this modification does not help.
I have a question about the switch_lock code.
PRIVATE inline
bool NO_INSTRUMENT
Switch_lock::set_lock_owner(Context *o)
{
bool have_no_locks = o-_lock_cnt 1;
if (have_no_locks)
{
assert_kdb (current_cpu() == o-home_cpu());
for (;;)
{
if (EXPECT_FALSE(access_once(o-_running_under_lock)))
continue;
if (EXPECT_TRUE(mp_cas(o-_running_under_lock, Mword(false),
Mword(true
break;
}
}
...
}
In which case, the variable _running_under_lock is set to true but the
lock_cnt is 0?
Now in my test, the kernel goes into this dead loop.
I cannot figure out how to solve this problem.
Thank you very much.
Yuixn
On Sun, Aug 31, 2014 at 5:58 PM, Adam Lackorzynski
a...@os.inf.tu-dresden.de wrote:
On Fri Aug 29, 2014 at 13:46:38 -0400, Yuxin Ren wrote:
I have some further understanding about the code.
If thread A can go back to its home cpu(core 1), this means it is not
running on the core 2.
And when A release its lock, it will switch to its helper.
During the context switch from thread A to its helper on core 2, the
_running_under_lock
of thread A should be set to false. Thus thread A is able to continue to
run on its home cpu.
I think this logic has no problem. But I observed a thread going into
the infinite loop in Switch_lock::set_lock_owner method.
in my test program.
Because of inappropriate memory barrier, or anything else?
On Wed, Aug 27, 2014 at 2:28 PM, Yuxin Ren r...@gwmail.gwu.edu wrote:
I have a question about the dec_lock_cnt method in Context class under
multiple processor.
In its implementation, it checks if thread's home cpu is equal to
current
cpu.
If not, it does not unset _running_under_lock variable, even if the
_lock_cnt is 0.
Why does it check if home cpu is equal to current cpu?
This one should work better:
Context::dec_lock_cnt()
{
int n = _lock_cnt - 1;
write_now(_lock_cnt, n);
if (EXPECT_TRUE(!n home_cpu() == current_cpu()))
{
Mem::mp_wmb();
write_now(_running_under_lock, Mword(false));
}
}
Adam
--
Adam a...@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
