Yes, I agree with that. Gabe
On Thu, Jan 29, 2015 at 4:45 AM, Steve Reinhardt via gem5-dev < gem5-dev@gem5.org> 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 < > gem5-dev@gem5.org> > 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 < > > gem5-dev@gem5.org > > > 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 < > > > gem5-dev@gem5.org> 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 < > > > > gem5-dev@gem5.org> > > > > 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 > > > > > gem5-dev@gem5.org > > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > > > > _______________________________________________ > > > > gem5-dev mailing list > > > > gem5-dev@gem5.org > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > > _______________________________________________ > > > gem5-dev mailing list > > > gem5-dev@gem5.org > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > _______________________________________________ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
