Re: [gem5-dev] Protocol Specific Profiling
Hi guys, Slightly off topic, but it sounds like you want some form of inheritance structure between the protocols. Andreas On 03/12/2014 01:16, Beckmann, Brad via gem5-dev gem5-dev@gem5.org wrote: I have more questions/issues on this topic of protocol specific profiling. I do not believe this issues should be fixed by having SLICC understand more STL types. I should have pointed out before that many times it is not one specific protocol that needs special profiling, but rather a set of protocols that need special profiling. In the past, this has been handled by adding special profiling to either the profiler or sequencer, often by using the GenericMachineType. Unfortunately, you've removed GenericMachineType so if one where to compile a protocol that did not create those specific machine types, any special profiling functions that relied on them will fail to build. Why did you remove that enum definition from RubySlicc_Types.sm? Is there any reason we cannot add it back? Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Monday, November 24, 2014 6:50 PM To: Beckmann, Brad Cc: gem5 Developer List (gem5-dev@gem5.org) Subject: RE: Protocol Specific Profiling On Tue, 25 Nov 2014, Beckmann, Brad wrote: Thanks Nilay for the prompt reply. An example of a protocol specific statistic would be if say in a region coherence protocol [Power et al.], I was profiling the latencies of downgrade request-acks and I wanted to do that for the cross-product of requestor and request type. That is just one example, there are a million different possible statistics one could imagine wanting to collect. The specific example isn't important, the important part is we need any easy way to add protocol specific statistic processing. In other words, I want to collect data that doesn't neatly match a current gem5 statistic type and instead requires some sort of C++ customization before being added to a static data type. I think you are using a map or vector of some type. I would probably make SLICC understand what those types are. If you don't want to go that way, then you will have to do something similar to the earlier setup. Prototype a function in one of the .sm files, then define it say in RubySlicc_Util.hh and add the corresponding variable in the Profiler class. I'm not advocating for the prior solution. I completely agree going through the RubySlicc_Profile files was not great, but it is better than going through the AbstractController. At least the RubySlicc_Profile files were only collecting profile features. The AbstractController is growing into a beast. Perhaps what I'm looking for is an AbstractProfiler class that we can offload the current profiling work done by the AbstractController. Going through the abstract controller can be another way. I am actually not worried about the size of the class, unless you think that some function or data member is unecessary. We can define a class with in the AbstractController if you are worried about the profiling variables. If I am counting correctly, there are just three of them right now. I like the work you've done to collate statistics from independent object instantiations to a common set of data structures. We need to work on how those data structures are printed out, but your overall approach seems great. It seems the real problem we have now is that the generated collateStats functions directly cast to the AbstractController, thus all the stat interface functions need to be in the AbstractController. Instead, we to generate a protocol specific controller profiler that perhaps inherits from a to-be-determined AbstractProfiler class. The Profiler class still exists. You can still define a globally visible function that calls on the profiler to store some statistic. This is what use to happen before. The only other way I can think of is to make SLICC understand the different data structures we want to work with and use them in .sm files. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: dev: Support translating left and right ALT k...
changeset 9a4a926f7fe1 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=9a4a926f7fe1 description: dev: Support translating left and right ALT keys. This is used primarily for VNC. diffstat: src/dev/ps2.cc | 7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diffs (17 lines): diff -r 1c9d5d9417b3 -r 9a4a926f7fe1 src/dev/ps2.cc --- a/src/dev/ps2.ccTue Dec 02 06:08:25 2014 -0500 +++ b/src/dev/ps2.ccWed Dec 03 03:06:03 2014 -0800 @@ -174,6 +174,13 @@ extended = true; keys.push_back(0x14); break; + case XK_Alt_L: +keys.push_back(0x11); +break; + case XK_Alt_R: +extended = true; +keys.push_back(0x11); +break; default: warn(Unknown extended key %#x\n, key); return; ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: ide: Accept the IDLE (0xe3) ATA command.
changeset 24abf21b548d in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=24abf21b548d description: ide: Accept the IDLE (0xe3) ATA command. This command is supposed to set up a timer which will put the drive into a standby mode if it isn't sent a command within a given time out. Since most of the timeouts are generally significantly longer than a simulation would run anyway, and we don't have an implementation for standby mode to begin with, we can accept the command, do nothing, and report success. diffstat: src/dev/ide_disk.cc | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (11 lines): diff -r 9a4a926f7fe1 -r 24abf21b548d src/dev/ide_disk.cc --- a/src/dev/ide_disk.cc Wed Dec 03 03:06:03 2014 -0800 +++ b/src/dev/ide_disk.cc Wed Dec 03 03:07:35 2014 -0800 @@ -645,6 +645,7 @@ case WDSF_SEEK: case SET_FEATURES: case WDCC_SETMULTI: + case WDCC_IDLE: devState = Command_Execution; action = ACT_CMD_COMPLETE; break; ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] changeset in gem5: ide: Accept the IDLE (0xe3) ATA command.
Ah, darn it. I meant to update the tag before I pushed this. Sorry about that. Gabe On Wed, Dec 3, 2014 at 2:59 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: changeset 24abf21b548d in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=24abf21b548d description: ide: Accept the IDLE (0xe3) ATA command. This command is supposed to set up a timer which will put the drive into a standby mode if it isn't sent a command within a given time out. Since most of the timeouts are generally significantly longer than a simulation would run anyway, and we don't have an implementation for standby mode to begin with, we can accept the command, do nothing, and report success. diffstat: src/dev/ide_disk.cc | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (11 lines): diff -r 9a4a926f7fe1 -r 24abf21b548d src/dev/ide_disk.cc --- a/src/dev/ide_disk.cc Wed Dec 03 03:06:03 2014 -0800 +++ b/src/dev/ide_disk.cc Wed Dec 03 03:07:35 2014 -0800 @@ -645,6 +645,7 @@ case WDSF_SEEK: case SET_FEATURES: case WDCC_SETMULTI: + case WDCC_IDLE: devState = Command_Execution; action = ACT_CMD_COMPLETE; break; ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: config: Get rid of some extra spaces around d...
changeset 145c436a3854 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=145c436a3854 description: config: Get rid of some extra spaces around default arguments. diffstat: configs/common/FSConfig.py | 16 +++- 1 files changed, 7 insertions(+), 9 deletions(-) diffs (61 lines): diff -r 24abf21b548d -r 145c436a3854 configs/common/FSConfig.py --- a/configs/common/FSConfig.pyWed Dec 03 03:07:35 2014 -0800 +++ b/configs/common/FSConfig.pyWed Dec 03 03:11:00 2014 -0800 @@ -55,7 +55,7 @@ default = Self.badaddr_responder.pio -def makeLinuxAlphaSystem(mem_mode, mdesc = None, ruby = False): +def makeLinuxAlphaSystem(mem_mode, mdesc=None, ruby=False): class BaseTsunami(Tsunami): ethernet = NSGigE(pci_bus=0, pci_dev=1, pci_func=0) @@ -117,7 +117,7 @@ return self -def makeSparcSystem(mem_mode, mdesc = None): +def makeSparcSystem(mem_mode, mdesc=None): # Constants from iob.cc and uart8250.cc iob_man_addr = 0x98 uart_pio_size = 8 @@ -182,8 +182,8 @@ return self -def makeArmSystem(mem_mode, machine_type, num_cpus = 1, mdesc = None, - dtb_filename = None, bare_metal=False): +def makeArmSystem(mem_mode, machine_type, num_cpus=1, mdesc=None, + dtb_filename=None, bare_metal=False): assert machine_type if bare_metal: @@ -290,7 +290,7 @@ return self -def makeLinuxMipsSystem(mem_mode, mdesc = None): +def makeLinuxMipsSystem(mem_mode, mdesc=None): class BaseMalta(Malta): ethernet = NSGigE(pci_bus=0, pci_dev=1, pci_func=0) ide = IdeController(disks=[Parent.disk0, Parent.disk2], @@ -390,8 +390,7 @@ x86_sys.pc.attachIO(x86_sys.iobus, x86_sys._dma_ports) -def makeX86System(mem_mode, numCPUs = 1, mdesc = None, self = None, - Ruby = False): +def makeX86System(mem_mode, numCPUs=1, mdesc=None, self=None, Ruby=False): if self == None: self = X86System() @@ -502,8 +501,7 @@ self.intel_mp_table.base_entries = base_entries self.intel_mp_table.ext_entries = ext_entries -def makeLinuxX86System(mem_mode, numCPUs = 1, mdesc = None, - Ruby = False): +def makeLinuxX86System(mem_mode, numCPUs=1, mdesc=None, Ruby=False): self = LinuxX86System() # Build up the x86 system and then specialize it for Linux ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2524: config: Add two options for setting the kernel command line.
On Nov. 30, 2014, 6:38 p.m., Nilay Vaish wrote: I do not see much value though, but I am fine with patch. Gabe Black wrote: The ChromeOS kernel needs lots of command line arguments, both to configure the kernel and to leave information for the system at large. This is so we don't have to have a custom hack on top of the config scripts to jam those in there. I would really, really like to see the config stuff modularized way more than it is now, so that it's realistic to create a different config script which reuses the checked in code instead of having to modify it in place. Should this go in then? - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2524/#review5591 --- On Nov. 23, 2014, 7:26 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2524/ --- (Updated Nov. 23, 2014, 7:26 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10561:b2a85a0c0571 --- config: Add two options for setting the kernel command line. Both options accept template which will, through python string formatting, have mem, disk, and script values substituted in from the mdesc. Additional values can be used on a case by case basis by passing them as keyword arguments to the fillInCmdLine function. That makes it possible to have specialized parameters for a particular ISA, for instance. The first option lets you specify the template directly, and the other lets you specify a file which has the template in it. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c configs/common/Options.py 6317351a288c0349c5855c7431bc1eeade61605c configs/example/fs.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2524/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 2538: misc: Make the GDB register cache accessible in various sized chunks.
On Dec. 2, 2014, 5:47 p.m., Nilay Vaish wrote: src/base/remote_gdb.hh, line 143 http://reviews.gem5.org/r/2538/diff/1/?file=42808#file42808line143 Should this not be divCeil() * sizeof(uint64_t)? No. The size member reflects the size you asked for, not the size you got which is greater than or equal to that. I'm allocating the cache as an array of uint64_ts so that if you use that member of the union the alignment will still be right, but conceptually I want it to be more like a blob of memory than an array of ints of a particular size. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2538/#review5604 --- On Nov. 25, 2014, 11:47 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2538/ --- (Updated Nov. 25, 2014, 11:47 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10566:b350c8558d2f --- misc: Make the GDB register cache accessible in various sized chunks. Not all ISAs have 64 bit sized registers, so it's not always very convenient to access the GDB register cache in 64 bit sized chunks. This change makes it accessible in 8, 16, 32, or 64 bit chunks. The MIPS and ARM implementations were working around that limitation by bundling and unbundling 32 bit values into 64 bit values. That code has been removed. Diffs - src/arch/alpha/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/arch/arm/remote_gdb.hh f9fb64a72259a2514080151b5250a04c575d443a src/arch/arm/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/arch/mips/remote_gdb.hh f9fb64a72259a2514080151b5250a04c575d443a src/arch/mips/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/arch/sparc/remote_gdb.cc f9fb64a72259a2514080151b5250a04c575d443a src/base/remote_gdb.hh f9fb64a72259a2514080151b5250a04c575d443a Diff: http://reviews.gem5.org/r/2538/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[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-timing-ruby 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-timing-mp passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/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/tru64/simple-atomic passed.* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing 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-timing-dual passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-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/00.hello/alpha/linux/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/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level 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_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory 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_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token 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/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/inorder-timing passed. = Statistics differences =* 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-ruby passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing 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/simple-atomic passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/inorder-timing passed. * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/inorder-timing passed. *
[gem5-dev] changeset in gem5: sim: Make it possible to override the breakpo...
changeset 5962812f80fe in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5962812f80fe
description:
sim: Make it possible to override the breakpoint length check.
The check which makes sure the length of the breakpoint being written
is the
same as a MachInst is only correct on fixed instruction width ISAs.
Instead of
incorrectly applying that check to all ISAs, this change makes that the
default check and lets ISA specific GDB classes override it.
diffstat:
src/base/remote_gdb.cc | 14 ++
src/base/remote_gdb.hh | 2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diffs (64 lines):
diff -r 145c436a3854 -r 5962812f80fe src/base/remote_gdb.cc
--- a/src/base/remote_gdb.ccWed Dec 03 03:11:00 2014 -0800
+++ b/src/base/remote_gdb.ccWed Dec 03 03:27:19 2014 -0800
@@ -520,6 +520,12 @@
return system-pcEventQueue;
}
+bool
+BaseRemoteGDB::checkBpLen(size_t len)
+{
+return len == sizeof(MachInst);
+}
+
BaseRemoteGDB::HardBreakpoint::HardBreakpoint(BaseRemoteGDB *_gdb, Addr pc)
: PCEvent(_gdb-getPcEventQueue(), HardBreakpoint Event, pc),
gdb(_gdb), refcount(0)
@@ -539,7 +545,7 @@
bool
BaseRemoteGDB::insertSoftBreak(Addr addr, size_t len)
{
-if (len != sizeof(TheISA::MachInst))
+if (!checkBpLen(len))
panic(invalid length\n);
return insertHardBreak(addr, len);
@@ -548,7 +554,7 @@
bool
BaseRemoteGDB::removeSoftBreak(Addr addr, size_t len)
{
-if (len != sizeof(MachInst))
+if (!checkBpLen(len))
panic(invalid length\n);
return removeHardBreak(addr, len);
@@ -557,7 +563,7 @@
bool
BaseRemoteGDB::insertHardBreak(Addr addr, size_t len)
{
-if (len != sizeof(MachInst))
+if (!checkBpLen(len))
panic(invalid length\n);
DPRINTF(GDBMisc, inserting hardware breakpoint at %#x\n, addr);
@@ -574,7 +580,7 @@
bool
BaseRemoteGDB::removeHardBreak(Addr addr, size_t len)
{
-if (len != sizeof(MachInst))
+if (!checkBpLen(len))
panic(invalid length\n);
DPRINTF(GDBMisc, removing hardware breakpoint at %#x\n, addr);
diff -r 145c436a3854 -r 5962812f80fe src/base/remote_gdb.hh
--- a/src/base/remote_gdb.hhWed Dec 03 03:11:00 2014 -0800
+++ b/src/base/remote_gdb.hhWed Dec 03 03:27:19 2014 -0800
@@ -192,6 +192,8 @@
PCEventQueue *getPcEventQueue();
protected:
+virtual bool checkBpLen(size_t len);
+
class HardBreakpoint : public PCEvent
{
private:
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2510: Let other objects set up memory like regions in a KVM VM.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2510/#review5611 --- Ping - Gabe Black On Nov. 23, 2014, 2:51 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2510/ --- (Updated Nov. 23, 2014, 2:51 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10551:7767dc21318d --- Let other objects set up memory like regions in a KVM VM. Diffs - src/cpu/kvm/vm.hh f9fb64a72259a2514080151b5250a04c575d443a src/cpu/kvm/vm.cc f9fb64a72259a2514080151b5250a04c575d443a Diff: http://reviews.gem5.org/r/2510/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 2510: Let other objects set up memory like regions in a KVM VM.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2510/#review5613 --- As this is quite invasive, how broadly would this be used? Also, is there any chance of rather using devices that do not have memory of their own (and rely on the normal system memory that is already mapped)? - Andreas Hansson On Nov. 23, 2014, 2:51 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2510/ --- (Updated Nov. 23, 2014, 2:51 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10551:7767dc21318d --- Let other objects set up memory like regions in a KVM VM. Diffs - src/cpu/kvm/vm.hh f9fb64a72259a2514080151b5250a04c575d443a src/cpu/kvm/vm.cc f9fb64a72259a2514080151b5250a04c575d443a Diff: http://reviews.gem5.org/r/2510/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 2510: Let other objects set up memory like regions in a KVM VM.
On Dec. 3, 2014, 11:42 a.m., Andreas Hansson wrote: As this is quite invasive, how broadly would this be used? Also, is there any chance of rather using devices that do not have memory of their own (and rely on the normal system memory that is already mapped)? The one example I'm aware of is the cirrus graphics device on x86, and unfortunately the existing driver assumes there's memory on the card. Our team is reluctant to spend a significant amount of effort either writing a new driver or specializing the image to switch to a different video device. QEMU uses cirrus already, and since we use that for VM based testing we already have support for it in place. It's all a matter of opinion of course, but this doesn't seem that invasive to me. It's making the memory slot management a little bit more robust, and exposing it to external consumers. KVM is already a generalized/standardized interface to hardware virtualization, so it's not reaching behind the curtain all that much. There is some impact, but it seems like a reasonable trade off to me. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2510/#review5613 --- On Nov. 23, 2014, 2:51 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2510/ --- (Updated Nov. 23, 2014, 2:51 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10551:7767dc21318d --- Let other objects set up memory like regions in a KVM VM. Diffs - src/cpu/kvm/vm.hh f9fb64a72259a2514080151b5250a04c575d443a src/cpu/kvm/vm.cc f9fb64a72259a2514080151b5250a04c575d443a Diff: http://reviews.gem5.org/r/2510/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 2505: arch: Allow named constants as decode case values.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2505/ --- (Updated Dec. 3, 2014, 11:56 a.m.) Review request for Default. Repository: gem5 Description (updated) --- Changeset 10590:1c185336bb80 --- arch: Allow named constants as decode case values. The values in a bitfield or in an ExtMachInst structure member may not be a literal value, it might select from an arbitrary collection of options. Instead of using the raw value of those constants in the decoder, it's easier to tell what's going on if they can be referred to as a symbolic constant/enum. To support that, the ISA description language is extended slightly so that in addition to integer literals, the case value for decode blobs can also be a string literal. It's up to the ISA author to ensure that the string evaluates to a legal constant value when interpretted as C++. Diffs (updated) - src/arch/isa_parser.py 5962812f80fef83240fcb023806e523aa257c2fd Diff: http://reviews.gem5.org/r/2505/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 2505: arch: Allow named constants as decode case values.
On Dec. 2, 2014, 5:44 a.m., Steve Reinhardt wrote:
src/arch/isa_parser.py, line 1991
http://reviews.gem5.org/r/2505/diff/2/?file=42744#file42744line1991
update comment
I assume you mean just making it plural? The values do still have to be
constant or C++ will get angry.
On Dec. 2, 2014, 5:44 a.m., Steve Reinhardt wrote:
src/arch/isa_parser.py, line 1994
http://reviews.gem5.org/r/2505/diff/2/?file=42744#file42744line1994
it would be nice to update this variable name too ('case_list'?)
How about decode_vals? I'm open to suggestions.
On Dec. 2, 2014, 5:44 a.m., Steve Reinhardt wrote:
src/arch/isa_parser.py, line 2025
http://reviews.gem5.org/r/2505/diff/2/?file=42744#file42744line2025
do you really mean C++ symbols not C++ strings?
Steve Reinhardt wrote:
OK, I see from the other patch that it really is strings. If you put in
a string that doesn't evaluate to a constant, is that caught by the C++
compiler? If so, it might be more accurate to say strings (which must
evaluate to constants to avoid a compilation error) rather than just
strings which evaluate to constants
I changed it to strings which evaluate to constants when compiled as C++
- Gabe
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2505/#review5598
---
On Dec. 3, 2014, 11:56 a.m., Gabe Black wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2505/
---
(Updated Dec. 3, 2014, 11:56 a.m.)
Review request for Default.
Repository: gem5
Description
---
Changeset 10590:1c185336bb80
---
arch: Allow named constants as decode case values.
The values in a bitfield or in an ExtMachInst structure member may not be a
literal value, it might select from an arbitrary collection of options.
Instead
of using the raw value of those constants in the decoder, it's easier to tell
what's going on if they can be referred to as a symbolic constant/enum.
To support that, the ISA description language is extended slightly so that in
addition to integer literals, the case value for decode blobs can also be a
string literal. It's up to the ISA author to ensure that the string evaluates
to a legal constant value when interpretted as C++.
Diffs
-
src/arch/isa_parser.py 5962812f80fef83240fcb023806e523aa257c2fd
Diff: http://reviews.gem5.org/r/2505/diff/
Testing
---
Thanks,
Gabe Black
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: x86: Clean up style in process.cc.
changeset ad9146bb5598 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=ad9146bb5598
description:
x86: Clean up style in process.cc.
diffstat:
src/arch/x86/process.cc | 98
1 files changed, 49 insertions(+), 49 deletions(-)
diffs (207 lines):
diff -r 5962812f80fe -r ad9146bb5598 src/arch/x86/process.cc
--- a/src/arch/x86/process.cc Wed Dec 03 03:27:19 2014 -0800
+++ b/src/arch/x86/process.cc Tue Dec 02 22:01:51 2014 -0800
@@ -285,11 +285,11 @@
TSSDescLow.g = 1; // Page granularity
TSSDescLow.limitHigh = 0xF;
TSSDescLow.limitLow = 0x;
-TSSDescLow.baseLow = (((uint32_t)TSSVirtAddr) 8) 8;
-TSSDescLow.baseHigh = (uint8_t)(((uint32_t)TSSVirtAddr) 24);
+TSSDescLow.baseLow = bits(TSSVirtAddr, 23, 0);
+TSSDescLow.baseHigh = bits(TSSVirtAddr, 31, 24);
TSShigh TSSDescHigh = 0;
-TSSDescHigh.base = (uint32_t)(TSSVirtAddr 32);
+TSSDescHigh.base = bits(TSSVirtAddr, 63, 32);
struct TSSDesc {
uint64_t low;
@@ -304,7 +304,9 @@
SegSelector tssSel = 0;
tssSel.si = numGDTEntries - 1;
-uint64_t tss_base_addr = (TSSDescHigh.base 32) |
((TSSDescLow.baseHigh 24) | TSSDescLow.baseLow);
+uint64_t tss_base_addr = (TSSDescHigh.base 32) |
+ (TSSDescLow.baseHigh 24) |
+ TSSDescLow.baseLow;
uint64_t tss_limit = TSSDescLow.limitLow | (TSSDescLow.limitHigh
16);
SegAttr tss_attr = 0;
@@ -318,12 +320,12 @@
for (int i = 0; i contextIds.size(); i++) {
ThreadContext * tc = system-getThreadContext(contextIds[i]);
-tc-setMiscReg(MISCREG_CS, (MiscReg)cs);
-tc-setMiscReg(MISCREG_DS, (MiscReg)ds);
-tc-setMiscReg(MISCREG_ES, (MiscReg)ds);
-tc-setMiscReg(MISCREG_FS, (MiscReg)ds);
-tc-setMiscReg(MISCREG_GS, (MiscReg)ds);
-tc-setMiscReg(MISCREG_SS, (MiscReg)ds);
+tc-setMiscReg(MISCREG_CS, cs);
+tc-setMiscReg(MISCREG_DS, ds);
+tc-setMiscReg(MISCREG_ES, ds);
+tc-setMiscReg(MISCREG_FS, ds);
+tc-setMiscReg(MISCREG_GS, ds);
+tc-setMiscReg(MISCREG_SS, ds);
// LDT
tc-setMiscReg(MISCREG_TSL, 0);
@@ -335,11 +337,11 @@
tc-setMiscReg(MISCREG_TSG_BASE, GDTVirtAddr);
tc-setMiscReg(MISCREG_TSG_LIMIT, 8 * numGDTEntries - 1);
-tc-setMiscReg(MISCREG_TR, (MiscReg)tssSel);
-tc-setMiscReg(MISCREG_SEG_BASE(SYS_SEGMENT_REG_TR),
tss_base_addr);
-tc-setMiscReg(MISCREG_SEG_EFF_BASE(SYS_SEGMENT_REG_TR), 0);
-tc-setMiscReg(MISCREG_SEG_LIMIT(SYS_SEGMENT_REG_TR), tss_limit);
-tc-setMiscReg(MISCREG_SEG_ATTR(SYS_SEGMENT_REG_TR),
(MiscReg)tss_attr);
+tc-setMiscReg(MISCREG_TR, tssSel);
+tc-setMiscReg(MISCREG_TR_BASE, tss_base_addr);
+tc-setMiscReg(MISCREG_TR_EFF_BASE, 0);
+tc-setMiscReg(MISCREG_TR_LIMIT, tss_limit);
+tc-setMiscReg(MISCREG_TR_ATTR, tss_attr);
//Start using longmode segments.
installSegDesc(tc, SEGMENT_REG_CS, csDesc, true);
@@ -409,25 +411,22 @@
tc-setMiscReg(MISCREG_APIC_BASE, 0xfee00900);
-tc-setMiscReg(MISCREG_SEG_BASE(MISCREG_TSG -
MISCREG_SEG_SEL_BASE), GDTVirtAddr);
-tc-setMiscReg(MISCREG_SEG_LIMIT(MISCREG_TSG -
MISCREG_SEG_SEL_BASE), 0x);
+tc-setMiscReg(MISCREG_TSG_BASE, GDTVirtAddr);
+tc-setMiscReg(MISCREG_TSG_LIMIT, 0x);
-tc-setMiscReg(MISCREG_SEG_BASE(MISCREG_IDTR -
MISCREG_SEG_SEL_BASE), IDTVirtAddr);
-tc-setMiscReg(MISCREG_SEG_LIMIT(MISCREG_IDTR -
MISCREG_SEG_SEL_BASE), 0x);
+tc-setMiscReg(MISCREG_IDTR_BASE, IDTVirtAddr);
+tc-setMiscReg(MISCREG_IDTR_LIMIT, 0x);
/* enabling syscall and sysret */
MiscReg star = ((MiscReg)sret 48) | ((MiscReg)scall 32);
tc-setMiscReg(MISCREG_STAR, star);
-MiscReg lstar = (MiscReg) syscallCodeVirtAddr;
+MiscReg lstar = (MiscReg)syscallCodeVirtAddr;
tc-setMiscReg(MISCREG_LSTAR, lstar);
-MiscReg sfmask = (18) | (110); // TF | DF
+MiscReg sfmask = (1 8) | (1 10); // TF | DF
tc-setMiscReg(MISCREG_SF_MASK, sfmask);
}
-/*
- * Setting up the content of the TSS
- * and writting it to physical memory
- */
+/* Set up the content of the TSS and write it to physical memory. */
struct {
uint32_t reserved0;// +00h
@@ -461,8 +460,8 @@
/** setting Interrupt Stack Table */
uint64_t IST_start = ISTVirtAddr + PageBytes;
-tss.IST1_low = (uint32_t)IST_start;
-tss.IST1_high =
Re: [gem5-dev] Review Request 2547: x86: Clean up style in process.cc.
On Dec. 2, 2014, 6:26 a.m., Steve Reinhardt wrote: It would be nice to actually test this code just to be sure nothing slipped through, but style-wise it does look like an improvement. I might spend some personal time (vs. work time) at some point seeing if I can figure out what the problem is. This leads to what I'd like to eventually do to unify FS and SE more which I sent an email about. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2547/#review5602 --- On Dec. 1, 2014, 10:28 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2547/ --- (Updated Dec. 1, 2014, 10:28 a.m.) Review request for Default. Repository: gem5 Description --- changesets: 10561:965db4ba332b x86: Clean up style in process.cc. Diffs - src/arch/x86/process.cc dd04eb06ad42 Diff: http://reviews.gem5.org/r/2547/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] changeset in gem5: ruby: slicc: change the way configurable memb...
In SLICC we also use commas to separate parameters passed into a function or class...like most other languages I'm aware of. Using semi-colons seems awkward. I understand your point about message buffers, but that is only a problem because we are trying to pass these objects as parameters. Actually the fact that we declare and essentially pass the message buffers out of machine rather than pass them in is very awkward altogether. Many years ago we actually had a separate file the declared all the virtual channels needed in the protocol. Perhaps we should go back to that...maybe even using python to declare virtual channels. That would be a far less confusing notation than what is currently supported. I'm not sure where all this confusing SLICC notation is going and I would prefer if we just kept it as is. I think we all rather be doing interesting research rather than conforming our protocol files to some new notation for the sake of change. Brad -Original Message- From: Nilay Vaish [mailto:ni...@cs.wisc.edu] Sent: Tuesday, December 02, 2014 12:48 PM To: Beckmann, Brad Cc: gem5 Developer List Subject: RE: [gem5-dev] changeset in gem5: ruby: slicc: change the way configurable memb... On Tue, 2 Dec 2014, Beckmann, Brad wrote: Hi Nilay, Could you explain the motivation behind this change? What was wrong with the previous notation that data member declarations are separated by commas rather than semi-colons? I think in most places in SLICC we use comma to separate the attributes of a variable. So, having a different meaning for comma when used while declaring parameters does not seem right to me. Second, message buffers typically have several attributes with them. If we were to retain the comma as separator, then it would not be possible to specify message buffers as parameters. -- Nilay ___ 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. 3, 2014, 5:16 p.m.) Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi. Summary (updated) - dev: Prevent MC146818 timer RTC events firing before startup 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 UNKNOWN src/dev/mc146818.cc UNKNOWN src/dev/x86/cmos.hh UNKNOWN src/dev/x86/cmos.cc UNKNOWN src/python/m5/simulate.py UNKNOWN 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
[gem5-dev] Review Request 2548: arm: Add unlinkat syscall implementation
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2548/ --- Review request for Default. Repository: gem5 Description --- arm: Add unlinkat syscall implementation added ARM aarch64 unlinkat syscall support, modeled on other xxxat syscalls. This gets all of the cpu2006 int workloads passing in SE mode on aarch64. hmmer, omnetpp Diffs - src/arch/arm/linux/process.cc ad9146bb5598 src/sim/syscall_emul.hh ad9146bb5598 src/sim/syscall_emul.cc ad9146bb5598 Diff: http://reviews.gem5.org/r/2548/diff/ Testing --- build/ARM/tests/opt/quick/se SPEC CPU2006 integer apps, test and train input sizes Thanks, mike upton ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Protocol Specific Profiling
On Wed, 3 Dec 2014, Beckmann, Brad wrote: I have more questions/issues on this topic of protocol specific profiling. I do not believe this issues should be fixed by having SLICC understand more STL types. I should have pointed out before that many times it is not one specific protocol that needs special profiling, but rather a set of protocols that need special profiling. In the past, this has been handled by adding special profiling to either the profiler or sequencer, often by using the GenericMachineType. Unfortunately, you've removed GenericMachineType so if one where to compile a protocol that did not create those specific machine types, any special profiling functions that relied on them will fail to build. Why did you remove that enum definition from RubySlicc_Types.sm? Is there any reason we cannot add it back? I am ok with adding GenericMachineType back. In addition, I would prefer that we stop defining MachineType dynamically and instead make each MachineType used in a .sm file be one of those generic types. I think this will also allow us to compile all the protocols simultaneously. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Syscall emulation/fake Linux/KVM/SE FS integration
Hi Gabe, I can see how the KVM SE-mode support does look like a piece of what you're proposing. In this case there's a clear need for that functionality though. I'm curious what you see as the benefits of taking this model farther than strictly necessary for KVM SE mode. Not that I'm necessarily opposed, just looking for more information. Steve On Tue, Dec 2, 2014 at 1:59 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: X86LinuxSESystem is a better name. Gabe On Mon, Dec 1, 2014 at 3:05 AM, Gabe Black gabebl...@google.com wrote: One of the last things I did the last time I was working on gem5 was to merge the SE and FS builds of the simulator into one. I didn't really finish it before I left, though, and in a lot of ways it's still more like SE and FS glued together than one simulator that happens to do both. The work being done to support KVM in SE mode reminds me a lot of one of the things I had wanted to do to blend away one of those seams. What I'd wanted was to generalize the idea of a System object so that it would load a payload in whatever way it needed to, be that a Linux kernel or some processes, or whatever. What the system object would accept as a payload would depend on what type it was. For instance, there could be an X86LinuxSystem which would load an x86 Linux kernel as happens in FS mode. Then there would be an X86FakeLinuxSystem (name up for debate) which would load stubs for all the OS entry points (syscalls, exceptions). Those would call into the simulator which would then emulate Linux a la SE mode. From the simulators perspective they'd just be System objects which do something to get the system up and running. That's very similar to what you're doing to support KVM, except that we'd want to capture all of the OS entry points, and also have psuedoinsts (or your memory mapped thing) for all of them. Thoughts? Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Syscall emulation/fake Linux/KVM/SE FS integration
Basically, I'd like the distinction between SE and FS to be in how the user chooses to use the simulator. Right now, there are two parallel systems inherited from two separate builds, and having two ways to do certain things (write to memory, execute a syscall instruction, etc.) leads to some redundancy and extra complexity. Fundementally, SE and FS aren't that different since it's just code executing on fake hardware. I'd like to reduce or eliminate the ways things are unnecessarily specialized. Gabe On Wed, Dec 3, 2014 at 8:00 PM, Steve Reinhardt via gem5-dev gem5-dev@gem5.org wrote: Hi Gabe, I can see how the KVM SE-mode support does look like a piece of what you're proposing. In this case there's a clear need for that functionality though. I'm curious what you see as the benefits of taking this model farther than strictly necessary for KVM SE mode. Not that I'm necessarily opposed, just looking for more information. Steve On Tue, Dec 2, 2014 at 1:59 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: X86LinuxSESystem is a better name. Gabe On Mon, Dec 1, 2014 at 3:05 AM, Gabe Black gabebl...@google.com wrote: One of the last things I did the last time I was working on gem5 was to merge the SE and FS builds of the simulator into one. I didn't really finish it before I left, though, and in a lot of ways it's still more like SE and FS glued together than one simulator that happens to do both. The work being done to support KVM in SE mode reminds me a lot of one of the things I had wanted to do to blend away one of those seams. What I'd wanted was to generalize the idea of a System object so that it would load a payload in whatever way it needed to, be that a Linux kernel or some processes, or whatever. What the system object would accept as a payload would depend on what type it was. For instance, there could be an X86LinuxSystem which would load an x86 Linux kernel as happens in FS mode. Then there would be an X86FakeLinuxSystem (name up for debate) which would load stubs for all the OS entry points (syscalls, exceptions). Those would call into the simulator which would then emulate Linux a la SE mode. From the simulators perspective they'd just be System objects which do something to get the system up and running. That's very similar to what you're doing to support KVM, except that we'd want to capture all of the OS entry points, and also have psuedoinsts (or your memory mapped thing) for all of them. Thoughts? Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] testing
Hi Gabe, There's a long history here; I think everyone agrees the status quo wrt testing is inadequate, but there are a lot of different needs as well. I won't go into a lot of detail, but there is a wiki page left over from our last attempt: http://gem5.org/NewRegressionFramework. Actually I see now that you contributed to an early version of that. I'm not opposed to us having more unit tests and a framework to run them. Having the ability to integrate unit tests into the regressions would be a good goal for a new regression system. Having better unit tests might provide a nice middle ground between, on the one hand, running a few tests targeting whatever you're doing (the bug you're fixing or feature you're adding), plus a few quick hello world tests (which gives you a feeling that your change is probably good, for some definition of probably); and on the other hand, running the full regression suite. I'm not sure it would replace either one of those though. Thus, to be honest, I think the testing situation has bigger problems at this point; there's a lot on that wiki page, and unit testing isn't even mentioned. As far as your points 2 3: The regression tests do print out 'FAILED' vs. 'CHANGED' or something like that, so you can tell the difference between functional failures and stats changes pretty easily. You can look at the stats differences in the test output directory to see exactly what the changes are. The job of figuring out whether a particular set of stats changes is reasonable given some actual modeling change seems inherently impossible to automate, so I'm not sure what you're looking for there. Ali said he's been working on a new test framework; at this point I expect that's our best bet for moving forward. I'll let him decide whether he's ready to say more about it. Steve On Sun, Nov 23, 2014 at 6:51 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: Hi everybody. I'd like to start a conversation about testing strategies and gem5. Please let me know if my understanding is out of date, but I think the primary mechanism we use for testing is running benchmarks, booting, etc., and making sure the stats haven't changed. There are a few things that make that not so great. 1. Benchmarks can take a LONG time to run. I'd like to know whether my change is probably good in a couple seconds, not a couple hours. 2. There isn't much of an indication of *what* went wrong, just that something somewhere changed. 3. There isn't much of an indication *if* something went wrong. For a certain class of changes, it's reasonable to expect the stats to stay the same. For instance, a simulator performance optimization shouldn't change the stats. If you add a new device, change how execution works, fix some microcode, etc., you just have to guestimate if the amount of change looks reasonable and update the stats. Which, per 1, can take hours. 4. Merge conflicts. If two people make changes that affect the stats, one will go in first, and the other person will have to rebase on top of those changes and rerun the stats. Which, per 1, can take hours. I know writing new tests isn't what most people want to be doing with their time (including me), but as far as I can see this is a big shortcoming of the simulator as it stands. I think we would get a lot of benefit from more unit tests of both base functionality (we have a little of that), and of device models, execution bits, etc. (we have none?). We could either expand on the unit test code we have, or bring in an existing framework like this one: https://code.google.com/p/googletest/ I've never used that or know much of anything about it. It *should* be easy for us to use our modularity and object oriented design to pull pieces of the simulator into test harnesses and make sure they do reasonable things in isolation. If it isn't maybe that's something we should fix too. We should also think about how to make it easy/automatic to run unit tests, and how to get them to run automatically alongside the nightly regression runs. Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] testing
What I'd like is for us not to use stats as a pass/fail criteria. I'm not sure how that would work, but using the stats is pretty fragile and hard to maintain. It's tricky because you want to make sure the stats themselves are still correct, but there are lots of correct stats which are different. I agree that automatically deciding how much stats should change is not feasible. I haven't had a chance to read that wiki page, but one thing I remember, perhaps from the last time this came up, is that the regressions we run are benchmarks that do the same thing many times to get steady state behavior. To verify something is correct, we don't need to loop over the same block of code thousands or millions of times. We could probably make things a lot faster without losing coverage that way, although changing the regression binaries wouldn't necessarily be very straightforward. While I think there are significant drawbacks from long running tests as detailed in my earlier email, there are benefits for really quick tests too. They could, for instance, be run automatically on every CL as part of a continuous integration system. It would also be practical to run all of them before sending a CL out. Right now I just take a best guess what regressions are worth running since running the long ones is a major time commitment, especially across all the ISAs. Gabe On Wed, Dec 3, 2014 at 9:58 PM, Steve Reinhardt via gem5-dev gem5-dev@gem5.org wrote: Hi Gabe, There's a long history here; I think everyone agrees the status quo wrt testing is inadequate, but there are a lot of different needs as well. I won't go into a lot of detail, but there is a wiki page left over from our last attempt: http://gem5.org/NewRegressionFramework. Actually I see now that you contributed to an early version of that. I'm not opposed to us having more unit tests and a framework to run them. Having the ability to integrate unit tests into the regressions would be a good goal for a new regression system. Having better unit tests might provide a nice middle ground between, on the one hand, running a few tests targeting whatever you're doing (the bug you're fixing or feature you're adding), plus a few quick hello world tests (which gives you a feeling that your change is probably good, for some definition of probably); and on the other hand, running the full regression suite. I'm not sure it would replace either one of those though. Thus, to be honest, I think the testing situation has bigger problems at this point; there's a lot on that wiki page, and unit testing isn't even mentioned. As far as your points 2 3: The regression tests do print out 'FAILED' vs. 'CHANGED' or something like that, so you can tell the difference between functional failures and stats changes pretty easily. You can look at the stats differences in the test output directory to see exactly what the changes are. The job of figuring out whether a particular set of stats changes is reasonable given some actual modeling change seems inherently impossible to automate, so I'm not sure what you're looking for there. Ali said he's been working on a new test framework; at this point I expect that's our best bet for moving forward. I'll let him decide whether he's ready to say more about it. Steve On Sun, Nov 23, 2014 at 6:51 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: Hi everybody. I'd like to start a conversation about testing strategies and gem5. Please let me know if my understanding is out of date, but I think the primary mechanism we use for testing is running benchmarks, booting, etc., and making sure the stats haven't changed. There are a few things that make that not so great. 1. Benchmarks can take a LONG time to run. I'd like to know whether my change is probably good in a couple seconds, not a couple hours. 2. There isn't much of an indication of *what* went wrong, just that something somewhere changed. 3. There isn't much of an indication *if* something went wrong. For a certain class of changes, it's reasonable to expect the stats to stay the same. For instance, a simulator performance optimization shouldn't change the stats. If you add a new device, change how execution works, fix some microcode, etc., you just have to guestimate if the amount of change looks reasonable and update the stats. Which, per 1, can take hours. 4. Merge conflicts. If two people make changes that affect the stats, one will go in first, and the other person will have to rebase on top of those changes and rerun the stats. Which, per 1, can take hours. I know writing new tests isn't what most people want to be doing with their time (including me), but as far as I can see this is a big shortcoming of the simulator as it stands. I think we would get a lot of benefit from more unit tests of both base functionality (we have a little of that), and of device models, execution bits, etc. (we
