[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/simple-atomic 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-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/simple-atomic 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-timing passed. * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 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 passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual 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/50.memtest/alpha/linux/memtest-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/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-atomic 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-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/
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Hi Alex, You are absolutely right (and mercurial is not that great in tracking change sets :-). You need the patch before it: http://reviews.gem5.org/r/2572/ I am hoping to get all these pushed before Christmas. Andreas On 17/12/2014 16:38, "Dutu, Alexandru via gem5-dev" wrote: >Hi Andreas, > >I've tried applying this patch on top of revision 8fc6e7a835d1 and I get >bunch of rejects. It seems dram_ctrl.cc is a bit different in this patch >it has all sorts of extra code to deal with ranks. So I wondering this >patch requires another one to apply properly. > >Thanks, >Alex > >-Original Message- >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas >Hansson via gem5-dev >Sent: Saturday, December 13, 2014 2:12 AM >To: gem5 Developer List >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > >This patch should hopefully solve the issue with the refresh event: >http://reviews.gem5.org/r/2573/ > >Andreas > >On 11/12/2014 15:52, "Andreas Hansson via gem5-dev" >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
Re: [gem5-dev] Review Request 2588: tests: Remove deprecated InOrderCPU tests
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2588/ --- (Updated Dec. 19, 2014, 1:18 p.m.) Review request for Default. Repository: gem5 Description (updated) --- Changeset 10632:8879662a7b70 --- tests: Remove deprecated InOrderCPU tests This patch removes the three MIPS and SPARC regressions that use the deprecated InOrderCPU. This is the first step in completely removing the code from the tree, avoiding confusion, and focusing all development efforts on the MinorCPU. Brave new world. Diffs (updated) - tests/SConscript a0cb57e1c072 tests/configs/inorder-timing.py a0cb57e1c072 tests/quick/se/00.hello/ref/mips/linux/inorder-timing/config.ini a0cb57e1c072 tests/quick/se/00.hello/ref/mips/linux/inorder-timing/simerr a0cb57e1c072 tests/quick/se/00.hello/ref/mips/linux/inorder-timing/simout a0cb57e1c072 tests/quick/se/00.hello/ref/mips/linux/inorder-timing/stats.txt a0cb57e1c072 tests/quick/se/00.hello/ref/sparc/linux/inorder-timing/config.ini a0cb57e1c072 tests/quick/se/00.hello/ref/sparc/linux/inorder-timing/simerr a0cb57e1c072 tests/quick/se/00.hello/ref/sparc/linux/inorder-timing/simout a0cb57e1c072 tests/quick/se/00.hello/ref/sparc/linux/inorder-timing/stats.txt a0cb57e1c072 tests/quick/se/02.insttest/ref/sparc/linux/inorder-timing/config.ini a0cb57e1c072 tests/quick/se/02.insttest/ref/sparc/linux/inorder-timing/simerr a0cb57e1c072 tests/quick/se/02.insttest/ref/sparc/linux/inorder-timing/simout a0cb57e1c072 tests/quick/se/02.insttest/ref/sparc/linux/inorder-timing/stats.txt a0cb57e1c072 Diff: http://reviews.gem5.org/r/2588/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2589: scons: Do not build the InOrderCPU
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2589/ --- Review request for Default. Repository: gem5 Description --- Changeset 10633:5e0cf38b6419 --- scons: Do not build the InOrderCPU One step closer to shifting focus to the MinorCPU. Diffs - build_opts/MIPS a0cb57e1c072 build_opts/SPARC a0cb57e1c072 configs/common/CpuConfig.py a0cb57e1c072 configs/example/se.py a0cb57e1c072 Diff: http://reviews.gem5.org/r/2589/diff/ Testing --- Thanks, Andreas Hansson ___ 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)
Hi Andreas, Your patches solve the issue, I don't see spurious kvm exits anymore. Thanks, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson via gem5-dev Sent: Friday, December 19, 2014 2:43 AM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) Hi Alex, You are absolutely right (and mercurial is not that great in tracking change sets :-). You need the patch before it: http://reviews.gem5.org/r/2572/ I am hoping to get all these pushed before Christmas. Andreas On 17/12/2014 16:38, "Dutu, Alexandru via gem5-dev" wrote: >Hi Andreas, > >I've tried applying this patch on top of revision 8fc6e7a835d1 and I >get bunch of rejects. It seems dram_ctrl.cc is a bit different in this >patch it has all sorts of extra code to deal with ranks. So I wondering >this patch requires another one to apply properly. > >Thanks, >Alex > >-Original Message- >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas >Hansson via gem5-dev >Sent: Saturday, December 13, 2014 2:12 AM >To: gem5 Developer List >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > >This patch should hopefully solve the issue with the refresh event: >http://reviews.gem5.org/r/2573/ > >Andreas > >On 11/12/2014 15:52, "Andreas Hansson via gem5-dev" >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. >>>
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
Hi Alex, That is great news. Thanks for checking. Now we just have to work out a sensible API for the memory mode changes to avoid putting all this code in the controller. :-) Andreas On 19/12/2014 15:48, "Dutu, Alexandru via gem5-dev" wrote: >Hi Andreas, > >Your patches solve the issue, I don't see spurious kvm exits anymore. > >Thanks, >Alex > >-Original Message- >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas >Hansson via gem5-dev >Sent: Friday, December 19, 2014 2:43 AM >To: gem5 Developer List >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) > >Hi Alex, > >You are absolutely right (and mercurial is not that great in tracking >change sets :-). > >You need the patch before it: http://reviews.gem5.org/r/2572/ > >I am hoping to get all these pushed before Christmas. > >Andreas > > >On 17/12/2014 16:38, "Dutu, Alexandru via gem5-dev" >wrote: > >>Hi Andreas, >> >>I've tried applying this patch on top of revision 8fc6e7a835d1 and I >>get bunch of rejects. It seems dram_ctrl.cc is a bit different in this >>patch it has all sorts of extra code to deal with ranks. So I wondering >>this patch requires another one to apply properly. >> >>Thanks, >>Alex >> >>-Original Message- >>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas >>Hansson via gem5-dev >>Sent: Saturday, December 13, 2014 2:12 AM >>To: gem5 Developer List >>Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) >> >>This patch should hopefully solve the issue with the refresh event: >>http://reviews.gem5.org/r/2573/ >> >>Andreas >> >>On 11/12/2014 15:52, "Andreas Hansson via gem5-dev" >>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
