[gem5-dev] Cron m5test@zizzer /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/o3-timing 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/00.hello/alpha/tru64/simple-atomic 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. *
Re: [gem5-dev] Review Request 2511: dev: cirrus: Add a simplified device model for the cirrus graphics device.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2511/#review5696 --- src/dev/Cirrus.py http://reviews.gem5.org/r/2511/#comment5087 Remove, I think. src/dev/cirrus.hh http://reviews.gem5.org/r/2511/#comment5086 They probably shouldn't be. I'll fix that. src/dev/cirrus.cc http://reviews.gem5.org/r/2511/#comment5088 Ok. src/dev/cirrus.cc http://reviews.gem5.org/r/2511/#comment5085 I don't know what's going on here. This device model was originally written by someone else, and I added a small fix patch on top of it recently. I'll need to look into what this is for. src/dev/cirrus.cc http://reviews.gem5.org/r/2511/#comment5084 Since USE_KVM is constant at compile time, this if will get compiled away if it's false. We could check kvmVM only, but it would be slightly less efficient. That's probably ok, though. src/dev/cirrus.cc http://reviews.gem5.org/r/2511/#comment5081 Unfortunately no. We can't have the kvmVM parameter in the SimObject if KVM isn't available because we won't have access to that type. In that case, p-kvmVM won't compile. src/dev/cirrus.cc http://reviews.gem5.org/r/2511/#comment5082 It's const everywhere else, we just need to un-constify it here so we can set it up initially. src/dev/cirrus.cc http://reviews.gem5.org/r/2511/#comment5083 Yeah, we should deschedule that. - Gabe Black On Dec. 17, 2014, 7:39 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2511/ --- (Updated Dec. 17, 2014, 7:39 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10609:07584c650657 --- dev: cirrus: Add a simplified device model for the cirrus graphics device. All control register accesses are dropped on the floor. If used with KVM, the frame buffer is set up as a memory like region to keep performance from tanking. If a VNC server is configured, the buffer is marked dirty once every simulated 100ms. Diffs - src/dev/Cirrus.py PRE-CREATION src/dev/SConscript a0cb57e1c072965dcdd51465beff37b264b41424 src/dev/cirrus.hh PRE-CREATION src/dev/cirrus.cc PRE-CREATION Diff: http://reviews.gem5.org/r/2511/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2518: x86: i8042: Add VNC mouse support, and flesh out the mouse model.
On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote: src/dev/x86/i8042.hh, line 118 http://reviews.gem5.org/r/2518/diff/2/?file=42731#file42731line118 I know it is not changed, but could you elaborate on the unit? I'll have to look at it again to figure out what the unit is, but yeah, that seems reasonable. On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote: src/dev/x86/i8042.cc, line 122 http://reviews.gem5.org/r/2518/diff/2/?file=42732#file42732line122 const? No, because writeData sets state. On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote: src/dev/x86/i8042.cc, line 135 http://reviews.gem5.org/r/2518/diff/2/?file=42732#file42732line135 const? Nope. statusReg is modified. On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote: src/dev/x86/i8042.cc, line 248 http://reviews.gem5.org/r/2518/diff/2/?file=42732#file42732line248 , _space_ Yep. I'll fix that. On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote: src/dev/x86/i8042.cc, line 250 http://reviews.gem5.org/r/2518/diff/2/?file=42732#file42732line250 For the body of this, could you elaborate on why it looks the way it does? At the moment it is very thin on comments Yes. On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote: src/dev/x86/i8042.cc, line 410 http://reviews.gem5.org/r/2518/diff/2/?file=42732#file42732line410 setMouseAt? I believe that's part of the VNC interface which is defined outside this device. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2518/#review5695 --- On Nov. 23, 2014, 1:50 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2518/ --- (Updated Nov. 23, 2014, 1:50 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10555:a13dc3596e45 --- x86: i8042: Add VNC mouse support, and flesh out the mouse model. This change fleshes out the mouse model so that it can send mouse data to the simulated system somewhat realistically, and hooks it into the VNC server as the mouse input device. Diffs - src/dev/x86/I8042.py f9fb64a72259a2514080151b5250a04c575d443a src/dev/x86/i8042.hh f9fb64a72259a2514080151b5250a04c575d443a src/dev/x86/i8042.cc f9fb64a72259a2514080151b5250a04c575d443a Diff: http://reviews.gem5.org/r/2518/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[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/ --- Review request for Default. Repository: gem5 Description --- Changeset 10632:fd76f4077adc --- 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, and focusing all development efforts on the MinorCPU. Brave new world. Diffs - build_opts/MIPS a0cb57e1c072 build_opts/SPARC 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
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
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 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 gem5-dev@gem5.org 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 gem5-dev@gem5.org 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 gabebl...@google.com 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 gabebl...@google.com 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
