Yes, CPUID returns particular vendor and processor name strings, "M5 Simulator" and "Fake M5 x86_64 CPU" respectively. You can find the responsible code in arch/x86/cpuid.cc. Checking just one of those should be sufficient, and I'd guess the first is less likely to change, although it's unlikely either would change any time soon.
Gabe Tim Harris (RESEARCH) wrote: > Hi Gabe, > > I've got Barrelfish booting on multiple cores now. > > I slimmed down the amount of real-mode code used during booting, and fixed a > problem with the transition to protected mode, but everything else worked > really nicely. > > We change to protected mode with the sequence: > > lgdt ... > mov %cr0, %eax > or $PROT_MODE_ENABLE, %al > mov %eax, %cr0 > jmp 0x18:start_ap_pm > > To get the far jump to work I needed to (1) disable the "Check for a NULL > segment selector" in tlb.cc, since I think this was triggering a GPF on > fetching the jmp instruction (and the base/limit for the segment initialized > in real-mode should still be in use until passing the far jump), (2) in > JMP_FAR_I use srl to extract the selector, (3) switch the use of t1 and t2 in > jmpFarWork (JMP_FAR_I sets up t1=selector, t2=offset, but I think jmpFarWork > was expecting them the other way around). > > The additional device registers the Barrelfish writes to are: > > - The IERN bit in the AMD extended APIC feature register (Section 16.6.6 ref > http://support.amd.com/us/Processor_TechDocs/24593.pdf) > > - The PIC edge/level trigger selection bits (0x4d0, 0x4d1), clearing all bits > (=> edge triggered). > > I need to check whether these writes are significant -- for the moment I've > commented them out without any problems on m5 or QEMU. > > I'm on vacation for the next week, but when back I'll sort out tidier > versions of my fixes to Barrelfish and to m5... my current trees are full of > debugging printfs etc :-) > > One final quick question -- is there a clean way for code to detect whether > or not it is running on the simulator? If need to leave some sections of > initialization code disabled then I'd prefer to do that under a dynamic test, > so that the same kernel can be booted on real hardware. > > Thanks, > > Tim > > > > > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Gabe Black > Sent: 11 January 2011 18:37 > To: M5 users mailing list > Subject: Re: [m5-users] Barrelfish on m5 > > 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 > > _______________________________________________ > 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
