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
