Hi Tim, no problem. It's great that you've got it working so quickly! If you're modifying the system startup, you probably don't want to modify sim/system.cc. There's an x86 specific version in arch/x86, and an x86 and Linux specific version in arch/x86/linux. You could make a barrelfish version in arch/x86/barrelfish to keep the generic bits of code generic. You mentioned that this was a rough draft basically, so you may already be planning on doing that.
Which APIC registers did you need that weren't implemented? APIC behavior is pretty complex, so I shied away from features I wasn't forced to implement and/or wasn't able to exercise with the workload I was trying to get running. If you're really familiar with how it's supposed to work, it may be easy to add what you need. At first glance your fixes all seem reasonable, but I'd have to check the manuals again myself. If you want to send us some patches that would be great, or I could probably recreate them from your descriptions if you don't want to for some reason. Thanks again for letting us know about the bugs, and best of luck moving forward. Gabe On 01/11/11 05:22, Tim Harris (RESEARCH) wrote: > 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 _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
