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
