Hi Randolf. I'm not familiar with the multiboot patches, but yes, secondary
(AP) CPUs make a brief trip through real mode and 32 bit mode on their way
to 64 bit mode, and we simulate that.
The ELF loader in SE mode predates me, but I've always thought it tried too
hard to identify what was what instead of just doing what the file says. My
thought would be to rework the ELF loader so it just follows the
instructions in the headers and make everything work that way. It should be
fairly straightforward, but I can't guarantee there won't be nasty spots
where things break down.
As far as how to set up your System class, yes, you should inherit from
System somehow. There are a lot of things which try to access the System
object, and if they can't it would be bad. I think gem5 will at least
complain if you don't have a kernel, but you could probably make it stop
pretty easily. I think right now the assumption about what kind of thing
the System is going to load is too baked in, but fixing that would be a big
change.
Gabe
On Thu, Dec 11, 2014 at 12:07 AM, Randolf Rotta via gem5-dev <
[email protected]> wrote:
Hello Nilay,
many thanks for your answer. I hope I can clarify a little bit what we
had
in mind.
As far as I know, the legacy interrupt mechanisms are not working on x86
32-bit full system and we are not going to use them. Our kernels just
use a
32-bit entry point and then switch to 64-bit mode. This worked well with
bochs, qemu, grub, XeonPhi and other platforms. I assume that limited
16-bit and 32-bit support is in gem5 already. Usually, it is needed in
order to activate the other hardware threads ("application processors")
after the kernel booted on the first.
The naming "multiboot" is misleading. It is not about selecting kernels
interactively during the boot process. Indeed, this would be of little
use
within a simulator. The multiboot specification defines an interface
between bootloader/system and the OS kernel [1]. For example, a memory
map
table that enumerates the reserved and usable memory ranges is passed to
the kernel. This simplifies the boot process a lot usually.
With the patches from [2] everything needed for a limited multiboot
support is in place. The only problem is, that the current ELF loader of
gem5 ignores the PT_LOAD segments (aka program headers) in the ELF image
and, instead, misinterprets the sections information. In the context of
the
ELF format, sections are used by the linker and the segments should be
used
by the the loader...
Unfortunately, usage of the current gem5 ELF loader is triggered by the
constructor of class System and System* pointers are used in other places
of the gem5 code.
Is there anything to be aware of when doing a full system simulation
without setting a kernel image in the System class, i.e. FullSystem=true
and params()->kernel == "" ??? Then, I could load the kernel image with
an
own loader in MultibootX86System...
Best regards,
Randolf Rotta
(Brandenburgische Technische Universität Cottbus)
[1] http://en.wikipedia.org/wiki/Multiboot_Specification
[2] https://bitbucket.org/chrism333/gem5-patches/src/
Am 28.11.2014 um 15:55 schrieb Nilay Vaish via gem5-dev:
A couple of things that might help. First, I think x86 32-bit support
is only available in system call emulation mode. For 32-bit x86 full
system, you probably will have to make significant changes to gem5.
Second, since you are not able to boot a single kernel, I don't see the
point of going for multiboot. In fact, I am unable to think of any
benefits that multiboot would provide. On an actual system, it takes
time to install a kernel and if things go wrong, you would want to
switch back to some working version. With a simulator, you can
maintain
different kernel versions somewhere, and supply the right path to the
simulator.
--
Nilay
On Thu, 27 Nov 2014, Randolf Rotta via gem5-dev wrote:
Hello,
my research group is working on lightweight operating systems for
many-core processors. We are looking for a full system simulator that
supports debugging of x86-64 code and processor state. Qemu does not
tell much about the cpu state and the Bochs debugger has problems with
addresses in the high 64bit kernel-space. Hence, gem5 is very
interesting for us.
Unfortunately, we are not able to boot our kernel ELF images at the
moment. I applied the x86 32bit multiboot patches from
https://bitbucket.org/chrism333/gem5-patches/src/ and adapted the
gem5
configuration successfully. Now gem5 tries to load the ELF image via
sim/system.cc, which ends up in ElfObject::loadSections and does fancy
things with virtual addresses and hard-coded section names.
The ELF loader is surely doing the correct thing to load 64bit
user-space applications. But during the multiboot startup it should
really just load all LOAD segments to the requested physical addresses
and leave everything else alone -- especially virtual addresses.
Assuming that I am able to implement such a simplified ELF loader for
kernel images, what is a good way to integrate it into the existing
infrastructure? Is it mandatory to derive the class MultibootX86System
(in arch/x86/multiboot/system.hh) from the class System (in
sim/system.hh)?
Best regards,
Randolf Rotta
For reference, our kernel ELF image looks like this:
objdump -fph boot32.elf
boot32.elf: file format elf32-i386
architecture: i386, flags 0x00000012:
EXEC_P, HAS_SYMS
start address 0x00200058
Program Header:
LOAD off 0x00000078 vaddr 0x00200000 paddr 0x00200000 align
2**3
filesz 0x000003ed memsz 0x00206000 flags rwx
LOAD off 0x00000480 vaddr 0x81000000 paddr 0x00800000 align
2**6
filesz 0x0000da90 memsz 0x00401000 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .init 000003ed 00200000 00200000 00000078 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .initbss 00205000 00201000 00201000 00000465 2**0
ALLOC
2 .text 00009256 81000000 00800000 00000480 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .rodata 00000c4d 81009280 00809280 00009700 2**6
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .eh_frame 00003bb8 81009ed0 00809ed0 0000a350 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .init_array 00000008 8100da88 0080da88 0000df08 2**3
CONTENTS, ALLOC, LOAD, DATA
6 .bss 003f3540 8100dac0 0080dac0 0000df10 2**6
ALLOC
_______________________________________________
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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
