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
