Re: [gem5-dev] Review Request 2553: dev: Prevent intel 8254 timer events firing before startup
> On Dec. 5, 2014, 11:45 a.m., Andreas Hansson wrote: > > Look good to me. Do the regressions still pass? > > Cagdas Dirik wrote: > I ran the same tests as I mentioned in r/2545. Please let me know if I > need to test more. > > Cagdas Dirik wrote: > This very likely needs updates similar to r/2545 to carry the changes for > alpha and mips. I am working on an update. I have changes ready for alpha and mips, but they are on top of r/2545, and I don't know how to reflect that diff dependency here. So may be better to have r/2545 to be finished and submitted first. And then I will update this one. Also I could not convince myself yet if src/dev/x86/speaker.* needs editing as well. It uses I8254 but it does not serialize/unserialize it, so I am not sure if it needs a timer->startup() call. This should also give me time to take a better look. - Cagdas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2553/#review5642 --- On Dec. 4, 2014, 7:14 p.m., Cagdas Dirik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2553/ > --- > > (Updated Dec. 4, 2014, 7:14 p.m.) > > > Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. > > > Repository: gem5 > > > Description > --- > > This change includes edits to Intel8254Timer to prevent counter events firing > before startup to comply with SimObject initialization call sequence. > > > Diffs > - > > src/dev/intel_8254_timer.hh fea29fc045ee > src/dev/intel_8254_timer.cc fea29fc045ee > src/dev/x86/i8254.hh fea29fc045ee > src/dev/x86/i8254.cc fea29fc045ee > > Diff: http://reviews.gem5.org/r/2553/diff/ > > > Testing > --- > > > Thanks, > > Cagdas Dirik > > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2545: dev: Prevent MC146818 timer RTC events firing before startup
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2545/ --- (Updated Dec. 12, 2014, 5:50 a.m.) Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. Changes --- Added changes for MIPS. Repository: gem5 Description --- This change includes edits to MC146818 timer to prevent RTC events firing before startup to comply with SimObject initialization call sequence. Diffs (updated) - src/dev/alpha/tsunami_io.hh fea29fc045ee src/dev/alpha/tsunami_io.cc fea29fc045ee src/dev/arm/rtc_pl031.cc fea29fc045ee src/dev/mc146818.hh fea29fc045ee src/dev/mc146818.cc fea29fc045ee src/dev/mips/malta_io.hh fea29fc045ee src/dev/mips/malta_io.cc fea29fc045ee src/dev/x86/cmos.hh fea29fc045ee src/dev/x86/cmos.cc fea29fc045ee Diff: http://reviews.gem5.org/r/2545/diff/ Testing --- Thanks, Cagdas Dirik ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2545: dev: Prevent MC146818 timer RTC events firing before startup
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2545/ --- (Updated Dec. 12, 2014, 5:37 a.m.) Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. Changes --- This update is to fix regression failures for alpha and mips. Repository: gem5 Description --- This change includes edits to MC146818 timer to prevent RTC events firing before startup to comply with SimObject initialization call sequence. Diffs (updated) - src/dev/alpha/tsunami_io.hh fea29fc045ee src/dev/alpha/tsunami_io.cc fea29fc045ee src/dev/arm/rtc_pl031.cc fea29fc045ee src/dev/mc146818.hh fea29fc045ee src/dev/mc146818.cc fea29fc045ee src/dev/x86/cmos.hh fea29fc045ee src/dev/x86/cmos.cc fea29fc045ee Diff: http://reviews.gem5.org/r/2545/diff/ Testing --- Thanks, Cagdas Dirik ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2553: dev: Prevent intel 8254 timer events firing before startup
> On Dec. 5, 2014, 11:45 a.m., Andreas Hansson wrote: > > Look good to me. Do the regressions still pass? > > Cagdas Dirik wrote: > I ran the same tests as I mentioned in r/2545. Please let me know if I > need to test more. This very likely needs updates similar to r/2545 to carry the changes for alpha and mips. I am working on an update. - Cagdas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2553/#review5642 --- On Dec. 4, 2014, 7:14 p.m., Cagdas Dirik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2553/ > --- > > (Updated Dec. 4, 2014, 7:14 p.m.) > > > Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. > > > Repository: gem5 > > > Description > --- > > This change includes edits to Intel8254Timer to prevent counter events firing > before startup to comply with SimObject initialization call sequence. > > > Diffs > - > > src/dev/intel_8254_timer.hh fea29fc045ee > src/dev/intel_8254_timer.cc fea29fc045ee > src/dev/x86/i8254.hh fea29fc045ee > src/dev/x86/i8254.cc fea29fc045ee > > Diff: http://reviews.gem5.org/r/2553/diff/ > > > Testing > --- > > > Thanks, > > Cagdas Dirik > > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
libquantum runs fine. I will do a sweep of all the apps and post the results. On Thu, Dec 11, 2014 at 11:58 AM, mike upton wrote: > with --mem-type=SimpleMemory it panics and dies. > > this is using bzip2, I am going to try another benchmark as well. > > > without SimpleMemory, > bzip2 hangs sometime between the 20M and 30M instruction. Time is > advancing, but instructions are not retiring. > > > > > On Thu, Dec 11, 2014 at 11:42 AM, mike upton > wrote: > >> I was using SE, with just se.py --cpu-type=kvm >> >> >> >> On Thu, Dec 11, 2014 at 7:52 AM, Andreas Hansson via gem5-dev < >> gem5-dev@gem5.org> wrote: >> >>> Hi Alex, Mike, >>> >>> I¹ll try and fix this whole issue of the refresh event once and for all. >>> SimpleMemory should only really be used for fast-forwarding and >>> high-level >>> sweeps, and I would like to ensure there are really no reasons to move >>> away from the DRAM controller. >>> >>> It seems the sensible thing to do is to use startup and drainResume as >>> the >>> points where we check the mode of the memory system and either >>> disable/enable the refresh event of the DRAM controller. >>> >>> Hopefully I will have something working before the weekend. >>> >>> Andreas >>> >>> On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" >>> wrote: >>> >>> >Hi Mike, >>> > >>> >Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE, >>> >I get very similar execution times with old implementation, for >>> >SimpleMemory and classic memory with detailed memory controller. Also >>> >what linux kernel are you using? >>> > >>> >Thanks, >>> >Alex >>> > >>> >-Original Message- >>> >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike >>> upton >>> >via gem5-dev >>> >Sent: Wednesday, December 10, 2014 3:59 PM >>> >To: gem5 Developer List >>> >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) >>> > >>> >I was testing this on both Intel and AMD platforms. >>> > >>> >The new code does seem to work for Intel platforms. >>> > >>> >The new code also seems to clean up a bunch of runtime warnings I was >>> >getting on AMD platforms. >>> > >>> >However the new code on AMD is either much slower, or it is stuck in a >>> >loop. >>> >A test that runs for 30 sec with the old code is running for more than >>> 10 >>> >mins, and still has a long way to go. >>> > >>> > >>> > >>> >On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev >>> >>> >> wrote: >>> > >>> >> That's not actually extending the TSS limit, that's what it works out >>> >> to be with the granularity bit set. The AM and WP bits were set to the >>> >> wrong thing according to the comments next to them I'm pretty sure. If >>> >> we wanted the other behavior, we might be able to change them back and >>> >>have it work. >>> >> The _BASE registers hold the base of segments as they're specified by >>> >> the ISA. The _EFF_BASE registers hold the base that will actually be >>> >> used in address calculations based on the mode of the CPU. For >>> >> instance, if you're in 64 bit mode, the _BASE of DS might still be >>> >> 0xFFF from when you were in another mode. The _EFF_BASE would be 0 >>> >> though, since the DS base is ignored in that case. _EFF_BASE may not >>> >> be used by the KVM CPU, but it should be set up anyway in case we >>> >>switch back to a regular CPU. >>> >> >>> >> Gabe >>> >> >>> >> On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev < >>> >> gem5-dev@gem5.org> wrote: >>> >> >>> >> > Thank you for all the clarifications. I see that for SE to work on >>> >> > vmx >>> >> the >>> >> > TSS limit had to be extended, am and wp bits in CR0 had to be reset >>> >> > and *_EFF_BASE registers had be set in addition to *_BASE registers >>> >> > for TR >>> >> TSG >>> >> > IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR >>> >> > register (which gets passed to kvm) are the same if with or without >>> >> > *_EFF_BASE registers set. >>> >> > >>> >> > Thank you, >>> >> > Alex >>> >> > >>> >> > -Original Message- >>> >> > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe >>> >> Black >>> >> > via gem5-dev >>> >> > Sent: Wednesday, December 10, 2014 1:21 AM >>> >> > To: gem5 Developer List >>> >> > Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) >>> >> > >>> >> > Ok, I got SE working too. I'll clean up my patch and send that out >>> >> > in a bit. >>> >> > >>> >> > Gabe >>> >> > >>> >> > On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black >>> >>wrote: >>> >> > >>> >> > > I figured out what the other problem was, so here's the review. >>> >> > > >>> >> > > http://reviews.gem5.org/r/2557/ >>> >> > > >>> >> > > Gabe >>> >> > > >>> >> > > On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black >>> >> wrote: >>> >> > > >>> >> > >> It was attached in my sent mail. Maybe it's being blocked by >>> >> something? >>> >> > >> I'm hunting down another problem so I don't want to move my tree >>> >> > >> around too much, but once that's done I'll post it as a
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
with --mem-type=SimpleMemory it panics and dies. this is using bzip2, I am going to try another benchmark as well. without SimpleMemory, bzip2 hangs sometime between the 20M and 30M instruction. Time is advancing, but instructions are not retiring. On Thu, Dec 11, 2014 at 11:42 AM, mike upton wrote: > I was using SE, with just se.py --cpu-type=kvm > > > > On Thu, Dec 11, 2014 at 7:52 AM, Andreas Hansson via gem5-dev < > gem5-dev@gem5.org> wrote: > >> Hi Alex, Mike, >> >> I¹ll try and fix this whole issue of the refresh event once and for all. >> SimpleMemory should only really be used for fast-forwarding and high-level >> sweeps, and I would like to ensure there are really no reasons to move >> away from the DRAM controller. >> >> It seems the sensible thing to do is to use startup and drainResume as the >> points where we check the mode of the memory system and either >> disable/enable the refresh event of the DRAM controller. >> >> Hopefully I will have something working before the weekend. >> >> Andreas >> >> On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" >> wrote: >> >> >Hi Mike, >> > >> >Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE, >> >I get very similar execution times with old implementation, for >> >SimpleMemory and classic memory with detailed memory controller. Also >> >what linux kernel are you using? >> > >> >Thanks, >> >Alex >> > >> >-Original Message- >> >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike >> upton >> >via gem5-dev >> >Sent: Wednesday, December 10, 2014 3:59 PM >> >To: gem5 Developer List >> >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) >> > >> >I was testing this on both Intel and AMD platforms. >> > >> >The new code does seem to work for Intel platforms. >> > >> >The new code also seems to clean up a bunch of runtime warnings I was >> >getting on AMD platforms. >> > >> >However the new code on AMD is either much slower, or it is stuck in a >> >loop. >> >A test that runs for 30 sec with the old code is running for more than 10 >> >mins, and still has a long way to go. >> > >> > >> > >> >On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev >> >> >> wrote: >> > >> >> That's not actually extending the TSS limit, that's what it works out >> >> to be with the granularity bit set. The AM and WP bits were set to the >> >> wrong thing according to the comments next to them I'm pretty sure. If >> >> we wanted the other behavior, we might be able to change them back and >> >>have it work. >> >> The _BASE registers hold the base of segments as they're specified by >> >> the ISA. The _EFF_BASE registers hold the base that will actually be >> >> used in address calculations based on the mode of the CPU. For >> >> instance, if you're in 64 bit mode, the _BASE of DS might still be >> >> 0xFFF from when you were in another mode. The _EFF_BASE would be 0 >> >> though, since the DS base is ignored in that case. _EFF_BASE may not >> >> be used by the KVM CPU, but it should be set up anyway in case we >> >>switch back to a regular CPU. >> >> >> >> Gabe >> >> >> >> On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev < >> >> gem5-dev@gem5.org> wrote: >> >> >> >> > Thank you for all the clarifications. I see that for SE to work on >> >> > vmx >> >> the >> >> > TSS limit had to be extended, am and wp bits in CR0 had to be reset >> >> > and *_EFF_BASE registers had be set in addition to *_BASE registers >> >> > for TR >> >> TSG >> >> > IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR >> >> > register (which gets passed to kvm) are the same if with or without >> >> > *_EFF_BASE registers set. >> >> > >> >> > Thank you, >> >> > Alex >> >> > >> >> > -Original Message- >> >> > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe >> >> Black >> >> > via gem5-dev >> >> > Sent: Wednesday, December 10, 2014 1:21 AM >> >> > To: gem5 Developer List >> >> > Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) >> >> > >> >> > Ok, I got SE working too. I'll clean up my patch and send that out >> >> > in a bit. >> >> > >> >> > Gabe >> >> > >> >> > On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black >> >>wrote: >> >> > >> >> > > I figured out what the other problem was, so here's the review. >> >> > > >> >> > > http://reviews.gem5.org/r/2557/ >> >> > > >> >> > > Gabe >> >> > > >> >> > > On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black >> >> wrote: >> >> > > >> >> > >> It was attached in my sent mail. Maybe it's being blocked by >> >> something? >> >> > >> I'm hunting down another problem so I don't want to move my tree >> >> > >> around too much, but once that's done I'll post it as a review. >> >> > >> >> >> > >> Gabe >> >> > >> >> >> > >> On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev < >> >> > >> gem5-dev@gem5.org> wrote: >> >> > >> >> >> > >>> I haven't received any attachment to your email. So I don't have >> >> > >>> your patch. >> >> > >>> >> >> > >>>
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
I was using SE, with just se.py --cpu-type=kvm On Thu, Dec 11, 2014 at 7:52 AM, Andreas Hansson via gem5-dev < gem5-dev@gem5.org> wrote: > Hi Alex, Mike, > > I¹ll try and fix this whole issue of the refresh event once and for all. > SimpleMemory should only really be used for fast-forwarding and high-level > sweeps, and I would like to ensure there are really no reasons to move > away from the DRAM controller. > > It seems the sensible thing to do is to use startup and drainResume as the > points where we check the mode of the memory system and either > disable/enable the refresh event of the DRAM controller. > > Hopefully I will have something working before the weekend. > > Andreas > > On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" > wrote: > > >Hi Mike, > > > >Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE, > >I get very similar execution times with old implementation, for > >SimpleMemory and classic memory with detailed memory controller. Also > >what linux kernel are you using? > > > >Thanks, > >Alex > > > >-Original Message- > >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike upton > >via gem5-dev > >Sent: Wednesday, December 10, 2014 3:59 PM > >To: gem5 Developer List > >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > > > >I was testing this on both Intel and AMD platforms. > > > >The new code does seem to work for Intel platforms. > > > >The new code also seems to clean up a bunch of runtime warnings I was > >getting on AMD platforms. > > > >However the new code on AMD is either much slower, or it is stuck in a > >loop. > >A test that runs for 30 sec with the old code is running for more than 10 > >mins, and still has a long way to go. > > > > > > > >On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev > > >> wrote: > > > >> That's not actually extending the TSS limit, that's what it works out > >> to be with the granularity bit set. The AM and WP bits were set to the > >> wrong thing according to the comments next to them I'm pretty sure. If > >> we wanted the other behavior, we might be able to change them back and > >>have it work. > >> The _BASE registers hold the base of segments as they're specified by > >> the ISA. The _EFF_BASE registers hold the base that will actually be > >> used in address calculations based on the mode of the CPU. For > >> instance, if you're in 64 bit mode, the _BASE of DS might still be > >> 0xFFF from when you were in another mode. The _EFF_BASE would be 0 > >> though, since the DS base is ignored in that case. _EFF_BASE may not > >> be used by the KVM CPU, but it should be set up anyway in case we > >>switch back to a regular CPU. > >> > >> Gabe > >> > >> On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev < > >> gem5-dev@gem5.org> wrote: > >> > >> > Thank you for all the clarifications. I see that for SE to work on > >> > vmx > >> the > >> > TSS limit had to be extended, am and wp bits in CR0 had to be reset > >> > and *_EFF_BASE registers had be set in addition to *_BASE registers > >> > for TR > >> TSG > >> > IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR > >> > register (which gets passed to kvm) are the same if with or without > >> > *_EFF_BASE registers set. > >> > > >> > Thank you, > >> > Alex > >> > > >> > -Original Message- > >> > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > >> Black > >> > via gem5-dev > >> > Sent: Wednesday, December 10, 2014 1:21 AM > >> > To: gem5 Developer List > >> > Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > >> > > >> > Ok, I got SE working too. I'll clean up my patch and send that out > >> > in a bit. > >> > > >> > Gabe > >> > > >> > On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black > >>wrote: > >> > > >> > > I figured out what the other problem was, so here's the review. > >> > > > >> > > http://reviews.gem5.org/r/2557/ > >> > > > >> > > Gabe > >> > > > >> > > On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black > >> wrote: > >> > > > >> > >> It was attached in my sent mail. Maybe it's being blocked by > >> something? > >> > >> I'm hunting down another problem so I don't want to move my tree > >> > >> around too much, but once that's done I'll post it as a review. > >> > >> > >> > >> Gabe > >> > >> > >> > >> On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev < > >> > >> gem5-dev@gem5.org> wrote: > >> > >> > >> > >>> I haven't received any attachment to your email. So I don't have > >> > >>> your patch. > >> > >>> > >> > >>> Alex > >> > >>> > >> > >>> -Original Message- > >> > >>> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of > >> > >>> Gabe Black via gem5-dev > >> > >>> Sent: Tuesday, December 09, 2014 6:42 PM > >> > >>> To: gem5 Developer List > >> > >>> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > >> > >>> > >> > >>> And... it turns out the KVM change wasn't necessary. If you're > >> > >>> working from my patch, get
Re: [gem5-dev] Review Request 2545: dev: Prevent MC146818 timer RTC events firing before startup
> On Dec. 5, 2014, 11:47 a.m., Andreas Hansson wrote: > > Looks good. What about the regressions? > > Cagdas Dirik wrote: > I have run hello world in se mode for both X86 and ARM. I also have a > small program that does int array manipulation, and I run it in se mode for > both X86 and ARM. I typically run timing and detailed cpu with simple memory. > I have also run this same small program in FS mode on X86. > > If there are more regression tests, could you please let me know? Since I > am new here, I am figuring out as I go. > > Andreas Hansson wrote: > It seems this changeset causes the ALPHA tsunami-minor/o3 regressions to > fail (for example > build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor). I > have not yet narrowed down the root cause, so perhaps you could have a look > Cagdas? > > Andreas Hansson wrote: > dev/alpha/tsunami_io needs to override startup and call rtc.startup() > > it's probably worth also removing the inclusion of mc146818.hh in > dev/arm/rtc_pl031.cc > Sure, I will take a look what other changes are missing. I should have dug deeper to see who else has an MC146818 timer or at least including the header file. Thank you for catching the issue. - Cagdas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2545/#review5643 --- On Dec. 4, 2014, 6:21 p.m., Cagdas Dirik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2545/ > --- > > (Updated Dec. 4, 2014, 6:21 p.m.) > > > Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. > > > Repository: gem5 > > > Description > --- > > This change includes edits to MC146818 timer to prevent RTC events firing > before startup to comply with SimObject initialization call sequence. > > > Diffs > - > > src/dev/mc146818.hh fea29fc045ee > src/dev/mc146818.cc fea29fc045ee > src/dev/x86/cmos.hh fea29fc045ee > src/dev/x86/cmos.cc fea29fc045ee > > Diff: http://reviews.gem5.org/r/2545/diff/ > > > Testing > --- > > > Thanks, > > Cagdas Dirik > > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] ELF image loader in x86 multiboot
HIstorically we started out with Alpha Tru64, so I think our first loader
was the ecoff one. When we added ELF support we probably tried too hard to
keep the same structure as the ecoff loader. A simplified, generalized ELF
loader would be a fine thing in my opinion.
Steve
On Thu, Dec 11, 2014 at 12:19 AM, Gabe Black via gem5-dev wrote:
> 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 <
> gem5-dev@gem5.org> 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.
> > >>
> > >> Unfortun
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Hi Alex, Mike, I¹ll try and fix this whole issue of the refresh event once and for all. SimpleMemory should only really be used for fast-forwarding and high-level sweeps, and I would like to ensure there are really no reasons to move away from the DRAM controller. It seems the sensible thing to do is to use startup and drainResume as the points where we check the mode of the memory system and either disable/enable the refresh event of the DRAM controller. Hopefully I will have something working before the weekend. Andreas On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" wrote: >Hi Mike, > >Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE, >I get very similar execution times with old implementation, for >SimpleMemory and classic memory with detailed memory controller. Also >what linux kernel are you using? > >Thanks, >Alex > >-Original Message- >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike upton >via gem5-dev >Sent: Wednesday, December 10, 2014 3:59 PM >To: gem5 Developer List >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > >I was testing this on both Intel and AMD platforms. > >The new code does seem to work for Intel platforms. > >The new code also seems to clean up a bunch of runtime warnings I was >getting on AMD platforms. > >However the new code on AMD is either much slower, or it is stuck in a >loop. >A test that runs for 30 sec with the old code is running for more than 10 >mins, and still has a long way to go. > > > >On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev >> wrote: > >> That's not actually extending the TSS limit, that's what it works out >> to be with the granularity bit set. The AM and WP bits were set to the >> wrong thing according to the comments next to them I'm pretty sure. If >> we wanted the other behavior, we might be able to change them back and >>have it work. >> The _BASE registers hold the base of segments as they're specified by >> the ISA. The _EFF_BASE registers hold the base that will actually be >> used in address calculations based on the mode of the CPU. For >> instance, if you're in 64 bit mode, the _BASE of DS might still be >> 0xFFF from when you were in another mode. The _EFF_BASE would be 0 >> though, since the DS base is ignored in that case. _EFF_BASE may not >> be used by the KVM CPU, but it should be set up anyway in case we >>switch back to a regular CPU. >> >> Gabe >> >> On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev < >> gem5-dev@gem5.org> wrote: >> >> > Thank you for all the clarifications. I see that for SE to work on >> > vmx >> the >> > TSS limit had to be extended, am and wp bits in CR0 had to be reset >> > and *_EFF_BASE registers had be set in addition to *_BASE registers >> > for TR >> TSG >> > IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR >> > register (which gets passed to kvm) are the same if with or without >> > *_EFF_BASE registers set. >> > >> > Thank you, >> > Alex >> > >> > -Original Message- >> > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe >> Black >> > via gem5-dev >> > Sent: Wednesday, December 10, 2014 1:21 AM >> > To: gem5 Developer List >> > Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) >> > >> > Ok, I got SE working too. I'll clean up my patch and send that out >> > in a bit. >> > >> > Gabe >> > >> > On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black >>wrote: >> > >> > > I figured out what the other problem was, so here's the review. >> > > >> > > http://reviews.gem5.org/r/2557/ >> > > >> > > Gabe >> > > >> > > On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black >> wrote: >> > > >> > >> It was attached in my sent mail. Maybe it's being blocked by >> something? >> > >> I'm hunting down another problem so I don't want to move my tree >> > >> around too much, but once that's done I'll post it as a review. >> > >> >> > >> Gabe >> > >> >> > >> On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev < >> > >> gem5-dev@gem5.org> wrote: >> > >> >> > >>> I haven't received any attachment to your email. So I don't have >> > >>> your patch. >> > >>> >> > >>> Alex >> > >>> >> > >>> -Original Message- >> > >>> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of >> > >>> Gabe Black via gem5-dev >> > >>> Sent: Tuesday, December 09, 2014 6:42 PM >> > >>> To: gem5 Developer List >> > >>> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) >> > >>> >> > >>> And... it turns out the KVM change wasn't necessary. If you're >> > >>> working from my patch, get rid of where the segment limit is >> > >>> divided >> > by PageBytes. >> > >>> That was only necessary because I wasn't adding 0xFFF to the >> > >>> limit when the granularity bit was set. >> > >>> >> > >>> Gabe >> > >>> >> > >>> On Tue, Dec 9, 2014 at 4:31 PM, Gabe Black >> > >>> >> > wrote: >> > >>> >> > >>> > Oh, also segment limits weren't being computed correctly in >> > >>> > the installSegDesc f
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Hi Mike, Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE, I get very similar execution times with old implementation, for SimpleMemory and classic memory with detailed memory controller. Also what linux kernel are you using? Thanks, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike upton via gem5-dev Sent: Wednesday, December 10, 2014 3:59 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) I was testing this on both Intel and AMD platforms. The new code does seem to work for Intel platforms. The new code also seems to clean up a bunch of runtime warnings I was getting on AMD platforms. However the new code on AMD is either much slower, or it is stuck in a loop. A test that runs for 30 sec with the old code is running for more than 10 mins, and still has a long way to go. On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev wrote: > That's not actually extending the TSS limit, that's what it works out > to be with the granularity bit set. The AM and WP bits were set to the > wrong thing according to the comments next to them I'm pretty sure. If > we wanted the other behavior, we might be able to change them back and have > it work. > The _BASE registers hold the base of segments as they're specified by > the ISA. The _EFF_BASE registers hold the base that will actually be > used in address calculations based on the mode of the CPU. For > instance, if you're in 64 bit mode, the _BASE of DS might still be > 0xFFF from when you were in another mode. The _EFF_BASE would be 0 > though, since the DS base is ignored in that case. _EFF_BASE may not > be used by the KVM CPU, but it should be set up anyway in case we switch back > to a regular CPU. > > Gabe > > On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev < > gem5-dev@gem5.org> wrote: > > > Thank you for all the clarifications. I see that for SE to work on > > vmx > the > > TSS limit had to be extended, am and wp bits in CR0 had to be reset > > and *_EFF_BASE registers had be set in addition to *_BASE registers > > for TR > TSG > > IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR > > register (which gets passed to kvm) are the same if with or without > > *_EFF_BASE registers set. > > > > Thank you, > > Alex > > > > -Original Message- > > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > Black > > via gem5-dev > > Sent: Wednesday, December 10, 2014 1:21 AM > > To: gem5 Developer List > > Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > > > > Ok, I got SE working too. I'll clean up my patch and send that out > > in a bit. > > > > Gabe > > > > On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black wrote: > > > > > I figured out what the other problem was, so here's the review. > > > > > > http://reviews.gem5.org/r/2557/ > > > > > > Gabe > > > > > > On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black > wrote: > > > > > >> It was attached in my sent mail. Maybe it's being blocked by > something? > > >> I'm hunting down another problem so I don't want to move my tree > > >> around too much, but once that's done I'll post it as a review. > > >> > > >> Gabe > > >> > > >> On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev < > > >> gem5-dev@gem5.org> wrote: > > >> > > >>> I haven't received any attachment to your email. So I don't have > > >>> your patch. > > >>> > > >>> Alex > > >>> > > >>> -Original Message- > > >>> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of > > >>> Gabe Black via gem5-dev > > >>> Sent: Tuesday, December 09, 2014 6:42 PM > > >>> To: gem5 Developer List > > >>> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > > >>> > > >>> And... it turns out the KVM change wasn't necessary. If you're > > >>> working from my patch, get rid of where the segment limit is > > >>> divided > > by PageBytes. > > >>> That was only necessary because I wasn't adding 0xFFF to the > > >>> limit when the granularity bit was set. > > >>> > > >>> Gabe > > >>> > > >>> On Tue, Dec 9, 2014 at 4:31 PM, Gabe Black > > >>> > > wrote: > > >>> > > >>> > Oh, also segment limits weren't being computed correctly in > > >>> > the installSegDesc function, although I don't think that was > > >>> > from the KVM stuff. Once it was fixed it required adjusting > > >>> > the KVM stuff a little, though. > > >>> > > > >>> > Gabe > > >>> > > > >>> > On Tue, Dec 9, 2014 at 4:29 PM, Gabe Black > > >>> > > > >>> wrote: > > >>> > > > >>> >> Here is my patch so far. There were a few things wrong, > > >>> >> although I didn't really keep notes. The limits were mixed > > >>> >> up, the long mode bit was set on all descriptors when it's > > >>> >> only valid for the code segment, privilege level > > >>> >> 0 is the OS and 3 is for applications and not the other way > > >>> >> around, and I think the type was being set wrong for one
Re: [gem5-dev] Review Request 2545: dev: Prevent MC146818 timer RTC events firing before startup
> On Dec. 5, 2014, 11:47 a.m., Andreas Hansson wrote: > > Looks good. What about the regressions? > > Cagdas Dirik wrote: > I have run hello world in se mode for both X86 and ARM. I also have a > small program that does int array manipulation, and I run it in se mode for > both X86 and ARM. I typically run timing and detailed cpu with simple memory. > I have also run this same small program in FS mode on X86. > > If there are more regression tests, could you please let me know? Since I > am new here, I am figuring out as I go. > > Andreas Hansson wrote: > It seems this changeset causes the ALPHA tsunami-minor/o3 regressions to > fail (for example > build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor). I > have not yet narrowed down the root cause, so perhaps you could have a look > Cagdas? dev/alpha/tsunami_io needs to override startup and call rtc.startup() it's probably worth also removing the inclusion of mc146818.hh in dev/arm/rtc_pl031.cc - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2545/#review5643 --- On Dec. 4, 2014, 6:21 p.m., Cagdas Dirik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2545/ > --- > > (Updated Dec. 4, 2014, 6:21 p.m.) > > > Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. > > > Repository: gem5 > > > Description > --- > > This change includes edits to MC146818 timer to prevent RTC events firing > before startup to comply with SimObject initialization call sequence. > > > Diffs > - > > src/dev/mc146818.hh fea29fc045ee > src/dev/mc146818.cc fea29fc045ee > src/dev/x86/cmos.hh fea29fc045ee > src/dev/x86/cmos.cc fea29fc045ee > > Diff: http://reviews.gem5.org/r/2545/diff/ > > > Testing > --- > > > Thanks, > > Cagdas Dirik > > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2545: dev: Prevent MC146818 timer RTC events firing before startup
> On Dec. 5, 2014, 11:47 a.m., Andreas Hansson wrote: > > Looks good. What about the regressions? > > Cagdas Dirik wrote: > I have run hello world in se mode for both X86 and ARM. I also have a > small program that does int array manipulation, and I run it in se mode for > both X86 and ARM. I typically run timing and detailed cpu with simple memory. > I have also run this same small program in FS mode on X86. > > If there are more regression tests, could you please let me know? Since I > am new here, I am figuring out as I go. It seems this changeset causes the ALPHA tsunami-minor/o3 regressions to fail (for example build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor). I have not yet narrowed down the root cause, so perhaps you could have a look Cagdas? - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2545/#review5643 --- On Dec. 4, 2014, 6:21 p.m., Cagdas Dirik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2545/ > --- > > (Updated Dec. 4, 2014, 6:21 p.m.) > > > Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. > > > Repository: gem5 > > > Description > --- > > This change includes edits to MC146818 timer to prevent RTC events firing > before startup to comply with SimObject initialization call sequence. > > > Diffs > - > > src/dev/mc146818.hh fea29fc045ee > src/dev/mc146818.cc fea29fc045ee > src/dev/x86/cmos.hh fea29fc045ee > src/dev/x86/cmos.cc fea29fc045ee > > Diff: http://reviews.gem5.org/r/2545/diff/ > > > Testing > --- > > > Thanks, > > Cagdas Dirik > > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> On Dec. 10, 2014, 10:30 p.m., mike upton wrote: > > There is some issue with AMD platforms. A test that used to run in 30 sec > > is not finishing. > > > > > > mike upton wrote: > hello world passes. SPEC apps hang. > > > Gabe Black wrote: > Can you identify where it's getting stuck? It could be there's something > wrong with how exception handling is set up, and it gets stuck faulting over > and over when a page fault happens, for instance. You could have the KVM CPU > print what the IP is each time it regains control and see if they cluster > somewhere interesting. Any luck? Unfortunately the time I have to work on gem5 is pretty limited, so I probably won't be able to dig into this for a while. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2557/#review5673 --- On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2557/ > --- > > (Updated Dec. 10, 2014, 10:11 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > --- > > Changeset 10606:aa3eb7453246 > --- > x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs. > > There were a number of problems with how things were initialized which prevent > VMX from running the simulation as a guest. > > > Diffs > - > > src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 > src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 > src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 > src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > Diff: http://reviews.gem5.org/r/2557/diff/ > > > Testing > --- > > > Thanks, > > Gabe Black > > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] ELF image loader in x86 multiboot
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 <
gem5-dev@gem5.org> 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 i
[gem5-dev] Cron /z/m5/regression/do-regression quick
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/inorder-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/inorder-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/l
Re: [gem5-dev] ELF image loader in x86 multiboot
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 0x0012:
>> EXEC_P, HAS_SYMS
>> start address 0x00200058
>>
>> Program Header:
>> LOAD off0x0078 vaddr 0x0020 paddr 0x0020 align 2**3
>> filesz 0x03ed memsz 0x00206000 flags rwx
>> LOAD off0x0480 vaddr 0x8100 paddr 0x0080 align 2**6
>> filesz 0xda90 memsz 0x00401000 flags rwx
>>
>> Sections:
>> Idx Name Size VMA LMA File off Algn
>> 0 .init 03ed 0020 0020 0078 2**3
>> CONTENTS, ALLOC, LOAD, READONLY, CODE
>> 1 .initbss 00205000 0020100
