Thanks. I didn't have a chance to look at this today, but I'll get to it soon.
Gabe On Wed, Jan 24, 2018 at 8:54 AM, Christian Menard < [email protected]> wrote: > 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
