Hi Nate, Gabe, thanks for the pointers! I've got a simple Barrelfish system now running. It gets as far as booting 1 core, starting various system processes on them, and running a user-mode test app. My current changes are a mess -- both the changes to m5 and to Barrelfish -- so I'll need to go back and do it properly, but I've got far enough to confirm that there aren't any major problems.
The Barrelfish kernel itself expects to be entered in long mode, so the very early start-of-day is straightforward. I modified sim/system.cc to create the multiboot information for the other modules that are needed, to load these into the simulated system's memory, and also to retain the relocation information for the kernel (it needs this so that, once booted, it can relocate itself multiple times to produce a separate kernel to run on each core). There are a few places that Barrelfish writes to APIC registers that are not yet supported in the simulator -- it boots OK with these commented out, but I need to go and check whether this is safe, or whether I need to add support for them. I ran into a couple of differences between the simulated machine on M5 and QEMU: - I think there's a problem with syscall_entry truncating the address, so I changed SYSCALL_64 to use 8-byte operations when setting up RIP. - Barrelfish sets CR0.WP=0 (i.e., disable write-protect, and therefore allow kernel code to write to pages that are mapped read-only). I modified the x86 tlb.cc code to not generate page faults when !inUser and !cr0.wp. - I was getting page faults during IRETQ instructions, and think the problem was that the LDT and GDT accesses were being seen as user-mode reads. I added "atCPL0=True" to the loads from the descriptor tables in interrupts_and_exceptions.py. I'm not yet sure I understand enough about the design of simulator to be very confident about the fixes (and I've not gone back to the architecture docs to check that Barrelfish is using the features correctly. Next step is trying to get up a second core, and then doing things properly :-). Tim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of nathan binkert Sent: 10 January 2011 21:29 To: M5 users mailing list Subject: Re: [m5-users] Barrelfish on m5 > I'm looking at how easy it would be to boot the x86-64 version of the > Barrelfish OS on m5 (http://www.barrelfish.org/ says more about the project, > although the most recent source release is now getting a bit out of date). I'll first say that this would be really cool! > My initial plan is to extend system.cc to support a simple boot loader for > modules, parsing the Barrelfish menu.lst file, loading the modules, and > creating the multiboot structures to describe what's been loaded. Does that > sound plausible? Gabe has given detail in his e-mails, but I should say that M5 itself already supports directly loading multiple modules into memory. Several platforms already do this. My guess is that we could make this a little bit more generic and then all of the menu.lst parsing and loading could simply be done from a python script. Nate _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
