Hi Mike. When we boot Linux on gem5, the simulator acts as the bootloader. It unpacks the kernel, provides various tables in memory that would normally be provided by the BIOS/firmware, does some setup of machine state, and then jumps to the kernel. On a real system, the components that get you to that point look more like this:
1. The CPU starts running firmware at a well defined address. If MP is supported (and it has been for a long, long time) then there's a little dance that's supposed to happen so that the CPUs figure out where everybody is and who's the main CPU. 2. The other CPUs (the APs or application processors) go to sleep, waiting for the main CPU (the BP, or bootstrap processor) to wake them up and tell them to do something. The BP continues executing in the firmware which begins machine initialization. 3. The firmware goes through it's paces, creating various tables for consumption by later software. It can support several different standards for booting off of different types of media. Harddrives will boot using code in the first little bit of the drive, I forget exactly what floppy disks do but I think it's similar, etc. 4. When you're booting linux, at this point your favorite bootloader, frequently grub, will start running since it's what was actually in the magic location on the disk. That goes through it's own procedure to get itself loaded, including grabbing additional parts of itself off of the remainder of the disk. 5. Grub (as an example) will follow the instructions in its config to find a kernel. It will follow a well established boot protocol where it takes a data structure stored in what's called the zero page from the front of the kernel image and fills in parts of it that are missing. It then puts that and the kernel where it wants to be in memory (generally specified in that data structure) and starts executing it. 6. The start of the kernel is generally a stub which decompresses the rest of the image which is actually the kernel, and the stub then jumps to it. Again, in gem5, we short circuit all that and skip right to the end. We actually load a kernel image which has not been compressed so that we can use an ELF loader on it and don't have to have it decompress itself in simulation. If you wanted to boot windows, I think it generally will want to start running around where grub starts running. You can start windows from grub, but when you do you use a mechanism called chain loading where it basically gets windows ready and then jumps to it as if grub hadn't run at all. Windows is non the wiser and starts running like normal. If you wanted to boot windows like we boot Linux, you'd need to get at the part of windows that their boot strap process actually sets up, figure out what work it does, and then get gem5 to do it. My assumption is that that's basically impossible unless you work at Microsoft, and even then is probably quite difficult. Another option would be to make gem5 boot more like a real system. You'd need some firmware to act as the BIOS (or at least fake it within gem5 itself), and you'd probably want to load windows off of the actual disk (or let the firmware do it) and start it using the standard PC boot mechanism. Writing a real BIOS for a real computer is very, very, very, very complicated, but writing a BIOS for a fake computer is significantly easier. If you want a reference, you can look at the BIOS implementation QEMU uses. There are also differences between a traditional BIOS implementation like you'd have found in older PCs, and EFI which you'd find on newer systems. EFI is probably a lot harder to fake since it's a lot bigger and more complex, so if you can get away with looking like a regular BIOS you're life might be a lot easier. More recent versions of windows may require EFI, or they may just require it to put a sticker on the case that says windows. You're mileage may vary. All in all, I think it might be a significant challenge to get windows running under gem5. You could probably do it, but beyond the difficult of getting it started, realistically you're also likely to run into bugs in gem5 itself. If you do, it might be really hard to debug them since you don't know what windows is trying to do since you can't (I assume) look at its source. It would be really neat if you get it to work, but I wouldn't want you to jump into this without warning you what you were taking on. Good luck! Gabe On Wed, Jan 28, 2015 at 10:26 PM, mike upton via gem5-dev <[email protected] > wrote: > I was going down 2 parallel paths. > > SE (win on win), and FS (on whatever works). > I have pretty much given up on the SE windows mode. > For now at least. > > I may revisit once cygwin/mingw support C11. > Even then, there are a lot of linux-isms built into the simulator. > > > > On Wed, Jan 28, 2015 at 10:14 PM, nathan binkert via gem5-dev < > [email protected]> wrote: > > > I have a question. If you're trying to simulate a windows guest on a > linux > > host. What are you doing with cygwin? > > > > On Wed, Jan 28, 2015 at 8:05 PM, mike upton via gem5-dev < > > [email protected]> > > wrote: > > > > > I would like to get started on trying to simulate a windows x86 machine > > (on > > > top of a linux host). > > > I am not too picky about type at this point, XP, win7 or win8.1 would > all > > > be acceptable. > > > > > > I spent quite a while trying to get gem5 compiled under cygwin, but it > is > > > currently broken because of a lack of C11 support in the gcc stack on > > > windows. > > > > > > I don’t really know how to get started. > > > > > > My understanding is that windows requires a USB device to be present. > > > So it seem like the first step is to get that going. > > > > > > Any pointers on how to proceed? > > > Is there any kind of OS bringup documentation. I searched and did not > > find > > > anything. > > > > > > > > > I was able to bring up win8.1 on qemu+kvm without much difficulty, so I > > am > > > hopeful. > > > > > > Thanks, > > > > > > Mike > > > _______________________________________________ > > > gem5-dev mailing list > > > [email protected] > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
