Hi Gabe, I posted a new patch [1] that is more in line to what you wrote in your last mail. Could you give it a look and let me know if this would work for you?
[1] https://gem5-review.googlesource.com/c/public/gem5/+/7541 Cheers Christian Gabe Black <[email protected]> writes: > 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
