Alternatively, there could be functions defined on the base X86System class which would bring it up to, say, 64 bit mode, and those could build off of each other as described. Then a given derived class like LinuxX86System could call switchTo64BitMode in its initState for instance. That would be better if we want to make a given class detect if the kernel it's loading is 32 vs. 64 bit dynamically.
Gabe On Tue, Jan 23, 2018 at 2:56 PM, Gabe Black <[email protected]> wrote: > That sounds better, although I'd suggest making the long mode vs. other > modes different subclasses rather than switched by a constructor argument. > The various modes of x86 are roughly: > > long mode: > 64 bit mode > compatibility mode > legacy mode: > 32 bit protected mode > 16 bit protected mode > real mode > > The legacy modes in particular are more complicated than that, but that's > a good rough picture. In long mode, the operating system structures (page > tables, descriptor tables, etc.) are all expanded and updated, but the > normal user space instructions/structures can either be expanded (64 bit > mode) or compatibility mode where things act like they did in 32 bit legacy > mode. > > The current x86 system class sets things up to be in 64 bit mode which is > a sub mode of long mode. To get there, you actually enter compatibility > mode first, and then switch up to 64 bit mode by setting a bit in the code > segment descriptor which is switched in by a long jump on actual hardware. > > What I think would be a nice way to organize things would be to have a > base X86System which just got the system to a consistent state and got > things going in pure real mode at the CPU reset vector. Then there could be > an I386System (borrowing naming from the Process classes) which would set > up the system in 32 bit protected mode. It would inherit from X86System, > and call the base initState function before doing its own initialization. > Then the X86_64System (again borrowing naming) would inherit from that, and > transition up to 64 bit mode (I less specifically called it long mode in > the existing code). Then the existing LinuxX86System would inherit from > X86_64System, and if you only want 32 bit legacy mode for multiboot, you'd > inherit from I386System. > > That isn't super great because if you wanted to have multiboot for both 32 > bit and 64 bit systems (for instance) you'd have two classes which had > X86System as a common ancestor, but not anything multiboot related. I don't > think solving that problem is urgent at the moment. > > Also, I'd like to move away from the idea of setting up the system itself > in the name of what it's going to run to instead having a workload which > knows how to set things up for itself, more like how a gem5 process > instance sets up for itself on initialization. That would bring things more > in line between FS and SE, and would let you have more complex systems > without having to have a different system type for each flavor. That's also > something that doesn't need to be done right now though. > > Gabe > > > On Tue, Jan 23, 2018 at 2:09 AM, Christian Menard < > [email protected]> wrote: > >> Hi Gabe, >> >> I see your point and I agree: that's not how it should be done. I wasn't >> aware anymore that the code in X86System switches to long mode (despite >> the source code comment). So I propose to extend X86System by a >> constructor argument that specifies whether the system should boot up in >> long mode or compatibility mode. This way LinuxX86System could build on >> the long mode setup, and MultibootX86System on the compatibility >> mode. Would that be a better approach? >> >> Cheers, >> >> Christian >> >> Gabe Black <[email protected]> writes: >> >> > I reviewed a part of this earlier which splits out part of the x86 >> system >> > class into a helper class, and I've explained why that's not what I >> think >> > should be done. The page table initialization is not specific to Linux, >> and >> > is replaced by the Linux kernel when it starts up. I'm not opposed to >> > adding multiboot support, but this (or at least that aspect of it) isn't >> > how it should be done. >> > >> > Gabe >> > >> > On Mon, Jan 22, 2018 at 9:46 AM, Christian Menard < >> > [email protected]> wrote: >> > >> >> Hi everybody, >> >> >> >> I have some old patches lying around that extend the x86 system by >> >> support for the Multiboot boot sequence standard [1]. Maximilian (CC) >> >> currently uses these patches for his work and recently rebased them to >> >> the current gem5. He uploaded them to gerrit as a single patch for >> >> review [2]. Probably it makes sense to split the patch up in smaller >> >> hunks before merging. >> >> >> >> Is there a general interest in supporting Multiboot in gem5? If so, >> >> could you please look at the patch and give some feedback what needs to >> >> be done before merging? >> >> >> >> The patch not only adds support for Multiboot, but also moves some code >> >> around. The X86System class does some work that is actually Linux >> >> specific. Therefore, the patch moves parts of the X86System code to >> >> Linux86System and also creates a MultibootX86System class. Does this >> >> sound reasonable to you? >> >> >> >> [1] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html >> >> [2] https://gem5-review.googlesource.com/c/public/gem5/+/7501 >> >> _______________________________________________ >> >> 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
