The easiest way to boot windows might be to use the X86 Xen stuff (which is working, right?) and use it to run coreboot and the windows bootloader. Then at least, you don't have to worry about missing instructions/modes during the boot process.
Nate On Thu, Jan 29, 2015 at 4:45 AM, Steve Reinhardt via gem5-dev < [email protected]> wrote: > Thanks for all the detailed info, Gabe. > > Mike, you're right that the current SE mode code is pretty specific to > Linux. It would be a small to moderate amount of effort to support other > Unix-like OSes like one of the BSDs (in fact our originally support for DEC > Tru64 on Alpha is still in there). Doing an SE-mode for Windows apps would > be basically starting over with the system call emulation code, though, and > would entail writing emulated versions of all the syscalls your apps use. > As many caveats as Gabe mentioned about getting Windows up in FS mode, I > would guess that doing SE mode would be even more work and require even > deeper access to proprietary Microsoft information (and thus end up being > something that you'd be far less likely to be able to contribute back to > the public code base). > > Steve > > On Thu, Jan 29, 2015 at 1:38 AM, Gabe Black via gem5-dev < > [email protected]> > wrote: > > > 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 > > > _______________________________________________ > 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
