[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed. * 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/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/simple-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/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 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-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/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 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-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/50.memtest/alpha/linux/memtest-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/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/50.memtest/alpha/linux/memtest-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/02.insttest/sparc/linux/inorder-timing passed. *
[gem5-dev] Review Request 2515: x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2515/ --- Review request for Default. Repository: gem5 Description --- Changeset 10550:9fcdf186d7ba --- x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays. There was already a stub device at 0x80, the port traditionally used for an IO delay. 0x80 is also the port used for POST codes sent by firmware, and that may have prompted adding this port as a second option. Diffs - src/dev/x86/Pc.py 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2515/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 2504: config: Fix to SystemC example's event handling
On Nov. 19, 2014, 12:22 a.m., Cagdas Dirik wrote: Please ignore my last review. I made a mistake with my patches. In FS, X86 mode I was able to boot with python variant, checkpoint, run a short program. Then I was able to restore from checkpoint and run the same program again. And in systemc variant then I was able to restore from checkpoint and run the same program. The exit was not clean though. It failed with fatal: Missed an event at time 123366500 gem5: 5699875688000, SystemC: 5699875688000 @ tick 5699875688000 [eventLoop:sc_module.cc, line 192] But that may be due to m5_exit in the test program. Hmm. The problem seems to be that sometimes asynchronous events schedule actions based on gem5 time in the asynchronous event handler. I'm adding code to catch up time in that handler and also a bit more 'in_simulate' checking and general event management to fix the problem. A patch will follow... - Andrew --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5482 --- On Nov. 17, 2014, 6:19 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/ --- (Updated Nov. 17, 2014, 6:19 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10555:d1e51dc6cf86 --- config: Fix to SystemC example's event handling This patch fixes checkpoint restore in the SystemC hosting example by handling early PollEvent events correctly before any EventQueue events are posted. The SystemC event queue handler (SCEventQueue) reports an error if the event loop is entered with no Events posted. It is possible for this to happen after instantiate due to PollEvent events. This patch separates out `external' events into a different handler in sc_module.cc to prevent the error from occurring. Diffs - util/systemc/Makefile 1a9e235cab09 util/systemc/main.cc 1a9e235cab09 util/systemc/sc_module.hh 1a9e235cab09 util/systemc/sc_module.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2504/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2504: config: Fix to SystemC example's event handling
On Nov. 19, 2014, 12:22 a.m., Cagdas Dirik wrote: Please ignore my last review. I made a mistake with my patches. In FS, X86 mode I was able to boot with python variant, checkpoint, run a short program. Then I was able to restore from checkpoint and run the same program again. And in systemc variant then I was able to restore from checkpoint and run the same program. The exit was not clean though. It failed with fatal: Missed an event at time 123366500 gem5: 5699875688000, SystemC: 5699875688000 @ tick 5699875688000 [eventLoop:sc_module.cc, line 192] But that may be due to m5_exit in the test program. Andrew Bardsley wrote: Hmm. The problem seems to be that sometimes asynchronous events schedule actions based on gem5 time in the asynchronous event handler. I'm adding code to catch up time in that handler and also a bit more 'in_simulate' checking and general event management to fix the problem. A patch will follow... Oh, in the meantime, can you put the line: getEventQueue(0)-setCurTick(systemc_time); Near the top of serviceAsyncEvent and see if that helps. - Andrew --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5482 --- On Nov. 17, 2014, 6:19 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/ --- (Updated Nov. 17, 2014, 6:19 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10555:d1e51dc6cf86 --- config: Fix to SystemC example's event handling This patch fixes checkpoint restore in the SystemC hosting example by handling early PollEvent events correctly before any EventQueue events are posted. The SystemC event queue handler (SCEventQueue) reports an error if the event loop is entered with no Events posted. It is possible for this to happen after instantiate due to PollEvent events. This patch separates out `external' events into a different handler in sc_module.cc to prevent the error from occurring. Diffs - util/systemc/Makefile 1a9e235cab09 util/systemc/main.cc 1a9e235cab09 util/systemc/sc_module.hh 1a9e235cab09 util/systemc/sc_module.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2504/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2313: kvm, x86: Adding support for SE mode execution
On Nov. 18, 2014, 10:43 p.m., Gabe Black wrote: util/m5/m5ops.h, line 57 http://reviews.gem5.org/r/2313/diff/4/?file=42082#file42082line57 Why do we need psuedo ops for syscalls when there are actual syscall instructions? The same goes for page faults. I'm not saying I know that we don't, I'm just surprised that that would be necessary. It seems unlikely that a program is going to realize it's about to cause a pagefault and obligingly call a special instruction first. The problem is that KVM doesn't normally intercept syscalls. This means that they need a small syscall handler and fault handler stub to support SE mode in KVM (see RB #2322). There are other ways of communicating with the host (e.g., IO ports, hypervisor calls). The beauty of this solution is that it is supported seamlessly by the simulated CPUs, which makes it possible to do CPU switching reliably (we need to handle situation where the switch takes place while the stub code is executing). It should be fairly straight forward to extend this to simulated CPUs, making mixed FS/SE mode simulation possible. On Nov. 18, 2014, 10:43 p.m., Gabe Black wrote: src/arch/x86/pseudo_inst.hh, line 37 http://reviews.gem5.org/r/2313/diff/4/?file=42075#file42075line37 These should be camel case, not all lower case. ie. m5Syscall and m5PageFault, depending on what you consider the boundary between words. These should also be called gem5*. I'd argue that we should stay with m5* in this case since the rest of the functions that are gem5-specific in the pseudo-inst interface is using that prefix. Having said that, we should probably rename them all at some point. - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/#review5480 --- On Sept. 30, 2014, 5:21 p.m., Alexandru Dutu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/ --- (Updated Sept. 30, 2014, 5:21 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10421:d4162e1b1c56 --- kvm, x86: Adding support for SE mode execution This patch adds methods in KvmCPU model to handle KVM exits caused by syscall instructions and page faults. These types of exits will be encountered if KvmCPU is run in SE mode. Diffs - src/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/alpha/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/arm/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/arm/pseudo_inst.hh PRE-CREATION src/arch/arm/pseudo_inst.cc PRE-CREATION src/arch/mips/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/power/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/sparc/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/pseudo_inst.hh PRE-CREATION src/arch/x86/pseudo_inst.cc PRE-CREATION src/arch/x86/tlb.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/utility.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/cpu/kvm/base.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/sim/pseudo_inst.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/sim/system.cc 28b31101d9e6e5e75d04448451986d6318383f3c util/m5/m5ops.h 28b31101d9e6e5e75d04448451986d6318383f3c Diff: http://reviews.gem5.org/r/2313/diff/ Testing --- Quick regressions passed. Thanks, Alexandru Dutu ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2313: kvm, x86: Adding support for SE mode execution
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/#review5487 --- src/arch/arm/pseudo_inst.cc http://reviews.gem5.org/r/2313/#comment4939 I'd suggest that you simplify this and get rid of all the arch-specific panic code and write it once in arch/generic/pseudo_inst.(cc|hh) and then import it in arch/XX/pseudo_inst.hh. See arch/mips/mmapped_ipr.hh and arch/generic/mmapped_ipr.hh for an example. Except for the issues pointed out by Gabe and Nilay, I think this looks good. - Andreas Sandberg On Sept. 30, 2014, 5:21 p.m., Alexandru Dutu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/ --- (Updated Sept. 30, 2014, 5:21 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10421:d4162e1b1c56 --- kvm, x86: Adding support for SE mode execution This patch adds methods in KvmCPU model to handle KVM exits caused by syscall instructions and page faults. These types of exits will be encountered if KvmCPU is run in SE mode. Diffs - src/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/alpha/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/arm/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/arm/pseudo_inst.hh PRE-CREATION src/arch/arm/pseudo_inst.cc PRE-CREATION src/arch/mips/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/power/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/sparc/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/pseudo_inst.hh PRE-CREATION src/arch/x86/pseudo_inst.cc PRE-CREATION src/arch/x86/tlb.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/utility.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/cpu/kvm/base.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/sim/pseudo_inst.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/sim/system.cc 28b31101d9e6e5e75d04448451986d6318383f3c util/m5/m5ops.h 28b31101d9e6e5e75d04448451986d6318383f3c Diff: http://reviews.gem5.org/r/2313/diff/ Testing --- Quick regressions passed. Thanks, Alexandru Dutu ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2513: KVM: Build in most of the KVM stuff even if we're not going to use it.
On 18/11/14 13:22, Steve Reinhardt via gem5-dev wrote: I haven't looked at the code in question, so I'm just going by what I've seen in this email thread. However, it seems like there ought to be some alternative solutions here. I like the general direction Andreas is going, though it would be nice to avoid more multiple inheritance :). The way I see it, the basic idea there is to create an API (either on an existing object like System or on a new object) that the device can call irrespective of whether KVM is configured or not, but which gives enough information to get the job done; then the other object can be responsible for either coordinating with KVM or (presumably) ignoring all those calls if KVM is not configured. As a simpler alternative, maybe we don't need to give the kvm pointer to the device via python; if the System object has an accessor that would return the vm pointer, then the device could call that during initialization, and it would of course just return NULL if kvm is not configured I would actually see it as a requirement of the new API that the underlying kvm vm is not exposed to device models. Exposing the VM would make the code base harder to maintain and extend (what if we want to add support for another virtualization interface?). The idea of adding a few more APIs to the System class seems good to me. We already use it to coordinate physical memories. As far as I can tell from the description a minimal API could look something like this: void System::mapDeviceMemory(DeviceMemory mem) void System::unmapDeviceMemory(DeviceMemory mem) void System::registerMemoryCallbacks(const MemoryCallbackInterface callbacks) This would make it possible to get rid of the dependency between devices and kvm. The kvm VM, or any other device that needs the information, would just register a set of callbacks with the system (probably just map/unmap notifications) and the device would just talk to the system and be virtualization agnostic. //Andreas -- 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
Re: [gem5-dev] Review Request 2514: scons: Make the USE_KVM variable available in C++.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2514/#review5488 --- The change itself makes sense, but I'd really prefer if we could avoid conditional compilation and use a kvm-agnostic interface to handle device memory. See my reply in the email thread for RB #2513. Consider this a ship it if it really turns out that using conditional compilation is the way to go. - Andreas Sandberg On Nov. 19, 2014, 6:44 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2514/ --- (Updated Nov. 19, 2014, 6:44 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10548:07c3cbac4cdd --- scons: Make the USE_KVM variable available in C++. We need it to determine whether we should expect KVM related parameters exist in the cirrus graphics device. Diffs - SConstruct 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2514/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/#review5489 --- src/cpu/kvm/vm.hh http://reviews.gem5.org/r/2510/#comment4940 The returned slot ID should be typedef:ed, or preferably a struct since that would make type checking more reliable. src/cpu/kvm/vm.hh http://reviews.gem5.org/r/2510/#comment4944 Would it make sense to rename this to mapMemSlot? In my opinion, that'd be more descriptive. src/cpu/kvm/vm.hh http://reviews.gem5.org/r/2510/#comment4942 Indentation is inconsistent with the rest of the file. src/cpu/kvm/vm.hh http://reviews.gem5.org/r/2510/#comment4941 What's this group comment doing here and where is it terminated? src/cpu/kvm/vm.hh http://reviews.gem5.org/r/2510/#comment4945 How about renaming this to unmapMemSlot? src/cpu/kvm/vm.cc http://reviews.gem5.org/r/2510/#comment4943 Inconsistent indentation. Overall, I'd prefer this to be an internal API and have some way of notifying the VM through the System instead of allowing objects to poke around directly. See my reply in the email thread for RB #2513. - Andreas Sandberg On Nov. 18, 2014, 1:29 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2510/ --- (Updated Nov. 18, 2014, 1:29 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10546:b4c9aa186307 --- Let other objects set up memory like regions in a KVM VM. Diffs - src/cpu/kvm/vm.hh f66948658a36b6874e84ee5da37e70d351287cb4 src/cpu/kvm/vm.cc f66948658a36b6874e84ee5da37e70d351287cb4 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 2515: x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2515/#review5490 --- src/dev/x86/Pc.py http://reviews.gem5.org/r/2515/#comment4946 I might be confused by the weird semantics of the gem5 configuration scripts, but isn't this killing the fake device for port 0x80? - Andreas Sandberg On Nov. 19, 2014, 9:26 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2515/ --- (Updated Nov. 19, 2014, 9:26 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10550:9fcdf186d7ba --- x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays. There was already a stub device at 0x80, the port traditionally used for an IO delay. 0x80 is also the port used for POST codes sent by firmware, and that may have prompted adding this port as a second option. Diffs - src/dev/x86/Pc.py 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2515/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 2504: config: Fix to SystemC example's event handling
On Nov. 19, 2014, 12:22 a.m., Cagdas Dirik wrote: Please ignore my last review. I made a mistake with my patches. In FS, X86 mode I was able to boot with python variant, checkpoint, run a short program. Then I was able to restore from checkpoint and run the same program again. And in systemc variant then I was able to restore from checkpoint and run the same program. The exit was not clean though. It failed with fatal: Missed an event at time 123366500 gem5: 5699875688000, SystemC: 5699875688000 @ tick 5699875688000 [eventLoop:sc_module.cc, line 192] But that may be due to m5_exit in the test program. Andrew Bardsley wrote: Hmm. The problem seems to be that sometimes asynchronous events schedule actions based on gem5 time in the asynchronous event handler. I'm adding code to catch up time in that handler and also a bit more 'in_simulate' checking and general event management to fix the problem. A patch will follow... Andrew Bardsley wrote: Oh, in the meantime, can you put the line: getEventQueue(0)-setCurTick(systemc_time); Near the top of serviceAsyncEvent and see if that helps. Unfortunately that did not resolve the issue. Debugging it a bit more, here is what I believe is going wrong: There is no sync point between gem5 curTick and sc_time_stamp(). Therefore, all events in the system are gem5 events based on curTick. Somewhere between SimControl::SimControl, SimControl::before_end_of_elaboration, and SimControl::run(), gem5 sub-system starts ticking before systemc starts SimControl::run(). And then we go into wait statement to advance systemc time, but gem5 keeps ticking. No gem5 module knows about systemc scheduler and the fact that they have to wait if we are restoring from a checkpoint. So gem5 events gets scheduled just like normal execution, and shortly after things fall apart because curTick, sc_time_stamp, checkpoint time and event times are totally out of whack. - Cagdas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5482 --- On Nov. 17, 2014, 6:19 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/ --- (Updated Nov. 17, 2014, 6:19 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10555:d1e51dc6cf86 --- config: Fix to SystemC example's event handling This patch fixes checkpoint restore in the SystemC hosting example by handling early PollEvent events correctly before any EventQueue events are posted. The SystemC event queue handler (SCEventQueue) reports an error if the event loop is entered with no Events posted. It is possible for this to happen after instantiate due to PollEvent events. This patch separates out `external' events into a different handler in sc_module.cc to prevent the error from occurring. Diffs - util/systemc/Makefile 1a9e235cab09 util/systemc/main.cc 1a9e235cab09 util/systemc/sc_module.hh 1a9e235cab09 util/systemc/sc_module.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2504/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2504: config: Fix to SystemC example's event handling
On Nov. 19, 2014, 12:22 a.m., Cagdas Dirik wrote: Please ignore my last review. I made a mistake with my patches. In FS, X86 mode I was able to boot with python variant, checkpoint, run a short program. Then I was able to restore from checkpoint and run the same program again. And in systemc variant then I was able to restore from checkpoint and run the same program. The exit was not clean though. It failed with fatal: Missed an event at time 123366500 gem5: 5699875688000, SystemC: 5699875688000 @ tick 5699875688000 [eventLoop:sc_module.cc, line 192] But that may be due to m5_exit in the test program. Andrew Bardsley wrote: Hmm. The problem seems to be that sometimes asynchronous events schedule actions based on gem5 time in the asynchronous event handler. I'm adding code to catch up time in that handler and also a bit more 'in_simulate' checking and general event management to fix the problem. A patch will follow... Andrew Bardsley wrote: Oh, in the meantime, can you put the line: getEventQueue(0)-setCurTick(systemc_time); Near the top of serviceAsyncEvent and see if that helps. Cagdas Dirik wrote: Unfortunately that did not resolve the issue. Debugging it a bit more, here is what I believe is going wrong: There is no sync point between gem5 curTick and sc_time_stamp(). Therefore, all events in the system are gem5 events based on curTick. Somewhere between SimControl::SimControl, SimControl::before_end_of_elaboration, and SimControl::run(), gem5 sub-system starts ticking before systemc starts SimControl::run(). And then we go into wait statement to advance systemc time, but gem5 keeps ticking. No gem5 module knows about systemc scheduler and the fact that they have to wait if we are restoring from a checkpoint. So gem5 events gets scheduled just like normal execution, and shortly after things fall apart because curTick, sc_time_stamp, checkpoint time and event times are totally out of whack. I believe I have a solution in mind. Let me run it by you and may be you can add it to your patch. 1. I would remove config_manager-instantiate() from the end of SimControl::SimControl, because we don't want any gem5 parts start ticking yet. 2. Instead at the end of SimControl::SimControl() unserializeGlobals, save pointer to checkpoint, and only calculate what the restore time would be. 3. Don't anything in before_end_of_elaboration(), because we may need to wait if checkpoint_restore is true. 4. Have another SimControl method to finish instantiation, initState/loadState, and startup. 5. At the beginning of run(), continue with if (checkpoint_restore) statement, wait if needed. Afterwards reset curTick to sc_time_stamp() and then call method from step 4 which would setup everything else. Then gem5 will start ticking and curTick will be inline with sc_time_stamp(). - Cagdas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5482 --- On Nov. 17, 2014, 6:19 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/ --- (Updated Nov. 17, 2014, 6:19 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10555:d1e51dc6cf86 --- config: Fix to SystemC example's event handling This patch fixes checkpoint restore in the SystemC hosting example by handling early PollEvent events correctly before any EventQueue events are posted. The SystemC event queue handler (SCEventQueue) reports an error if the event loop is entered with no Events posted. It is possible for this to happen after instantiate due to PollEvent events. This patch separates out `external' events into a different handler in sc_module.cc to prevent the error from occurring. Diffs - util/systemc/Makefile 1a9e235cab09 util/systemc/main.cc 1a9e235cab09 util/systemc/sc_module.hh 1a9e235cab09 util/systemc/sc_module.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2504/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2515: x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays.
On Nov. 19, 2014, 4:45 p.m., Andreas Sandberg wrote: src/dev/x86/Pc.py, line 54 http://reviews.gem5.org/r/2515/diff/1/?file=42652#file42652line54 I might be confused by the weird semantics of the gem5 configuration scripts, but isn't this killing the fake device for port 0x80? Hmm, yes. The peril of making these changes late at night when it's time to go home. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2515/#review5490 --- On Nov. 19, 2014, 9:26 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2515/ --- (Updated Nov. 19, 2014, 9:26 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10550:9fcdf186d7ba --- x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays. There was already a stub device at 0x80, the port traditionally used for an IO delay. 0x80 is also the port used for POST codes sent by firmware, and that may have prompted adding this port as a second option. Diffs - src/dev/x86/Pc.py 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2515/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 2515: x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2515/ --- (Updated Nov. 19, 2014, 11:51 p.m.) Review request for Default. Repository: gem5 Description (updated) --- Changeset 10550:dbbee17f23e1 --- x86: pc: Put a stub IO device at port 0xed which the kernel can use for delays. There was already a stub device at 0x80, the port traditionally used for an IO delay. 0x80 is also the port used for POST codes sent by firmware, and that may have prompted adding this port as a second option. Diffs (updated) - src/dev/x86/Pc.py 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2515/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 2313: kvm, x86: Adding support for SE mode execution
On Nov. 18, 2014, 10:43 p.m., Gabe Black wrote: util/m5/m5ops.h, line 57 http://reviews.gem5.org/r/2313/diff/4/?file=42082#file42082line57 Why do we need psuedo ops for syscalls when there are actual syscall instructions? The same goes for page faults. I'm not saying I know that we don't, I'm just surprised that that would be necessary. It seems unlikely that a program is going to realize it's about to cause a pagefault and obligingly call a special instruction first. Andreas Sandberg wrote: The problem is that KVM doesn't normally intercept syscalls. This means that they need a small syscall handler and fault handler stub to support SE mode in KVM (see RB #2322). There are other ways of communicating with the host (e.g., IO ports, hypervisor calls). The beauty of this solution is that it is supported seamlessly by the simulated CPUs, which makes it possible to do CPU switching reliably (we need to handle situation where the switch takes place while the stub code is executing). It should be fairly straight forward to extend this to simulated CPUs, making mixed FS/SE mode simulation possible. Initially I have implemented syscall and pagefault intercepts using IO ports. This implementation imposes all CPU models to be aware of the magic ports KvmCPU is using to trap syscalls and page faults. Andreas suggested the MMIO interface as it is already commun to all CPU models. - Alexandru --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/#review5480 --- On Sept. 30, 2014, 4:21 p.m., Alexandru Dutu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/ --- (Updated Sept. 30, 2014, 4:21 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10421:d4162e1b1c56 --- kvm, x86: Adding support for SE mode execution This patch adds methods in KvmCPU model to handle KVM exits caused by syscall instructions and page faults. These types of exits will be encountered if KvmCPU is run in SE mode. Diffs - src/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/alpha/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/arm/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/arm/pseudo_inst.hh PRE-CREATION src/arch/arm/pseudo_inst.cc PRE-CREATION src/arch/mips/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/power/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/sparc/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/SConscript 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/pseudo_inst.hh PRE-CREATION src/arch/x86/pseudo_inst.cc PRE-CREATION src/arch/x86/tlb.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/arch/x86/utility.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/cpu/kvm/base.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/sim/pseudo_inst.cc 28b31101d9e6e5e75d04448451986d6318383f3c src/sim/system.cc 28b31101d9e6e5e75d04448451986d6318383f3c util/m5/m5ops.h 28b31101d9e6e5e75d04448451986d6318383f3c Diff: http://reviews.gem5.org/r/2313/diff/ Testing --- Quick regressions passed. Thanks, Alexandru Dutu ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2313: kvm, x86: Adding support for SE mode execution
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/ --- (Updated Nov. 20, 2014, 12:36 a.m.) Review request for Default. Changes --- Addressed all the raised issues. In addition, it seems that exitGroup syscall has been changed such that each thread context is halted. In the case of KvmCPU, BaseKVMCPU::haltContext calls BaseKVMCPU::suspendContext and, in this case, the _status can be something different than Running inside suspendContext. I don't see a strong reason to have a haltContext implementation independent of suspendContext, as the difference between the 2 methods will be just one assert. Therefore I have broaden a bit the assert condition in suspendContext. Repository: gem5 Description (updated) --- Changeset 10548:8f97f4918e7c --- kvm, x86: Adding support for SE mode execution This patch adds methods in KvmCPU model to handle KVM exits caused by syscall instructions and page faults. These types of exits will be encountered if KvmCPU is run in SE mode. Diffs (updated) - src/arch/SConscript 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/alpha/SConscript 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/arm/pseudo_inst.hh PRE-CREATION src/arch/generic/SConscript 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/generic/pseudo_inst.hh PRE-CREATION src/arch/generic/pseudo_inst.cc PRE-CREATION src/arch/mips/SConscript 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/power/SConscript 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/sparc/SConscript 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/x86/SConscript 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/x86/pseudo_inst.hh PRE-CREATION src/arch/x86/pseudo_inst.cc PRE-CREATION src/arch/x86/tlb.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/x86/utility.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/cpu/kvm/base.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/pseudo_inst.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/system.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 util/m5/m5ops.h 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2313/diff/ Testing --- Quick regressions passed. Thanks, Alexandru Dutu ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2462: mem: Page Table map api modification
On Nov. 18, 2014, 4:30 p.m., Andreas Hansson wrote: src/mem/page_table.hh, line 95 http://reviews.gem5.org/r/2462/diff/1/?file=42140#file42140line95 I'd suggest to specify the storage type (uint32_t) Thought it is the only enum that will have an explicit storage type. - Alexandru --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2462/#review5474 --- On Oct. 6, 2014, 6:58 p.m., Alexandru Dutu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2462/ --- (Updated Oct. 6, 2014, 6:58 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10429:e0f8a026df2c --- mem: Page Table map api modification This patch adds uncacheable/cacheable and read-only/read-write attributes to the map method of PageTableBase. It also modifies the constructor of TlbEntry structs for all architectures to consider the new attributes. Diffs - src/arch/alpha/pagetable.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/arch/arm/pagetable.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/arch/mips/pagetable.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/arch/power/tlb.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/arch/sparc/pagetable.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/arch/x86/pagetable.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/arch/x86/pagetable.cc 148b96b7bc77190686f532d3b8f9f30cf911b36a src/mem/multi_level_page_table.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/mem/multi_level_page_table_impl.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/mem/page_table.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/mem/page_table.cc 148b96b7bc77190686f532d3b8f9f30cf911b36a src/sim/Process.py 148b96b7bc77190686f532d3b8f9f30cf911b36a src/sim/process.hh 148b96b7bc77190686f532d3b8f9f30cf911b36a src/sim/process.cc 148b96b7bc77190686f532d3b8f9f30cf911b36a Diff: http://reviews.gem5.org/r/2462/diff/ Testing --- Quick regressions testing done. Thanks, Alexandru Dutu ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2462: mem: Page Table map api modification
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2462/ --- (Updated Nov. 20, 2014, 6:27 a.m.) Review request for Default. Changes --- Addressed raised issues. Repository: gem5 Description (updated) --- Changeset 10553:d4148bafebad --- mem: Page Table map api modification This patch adds uncacheable/cacheable and read-only/read-write attributes to the map method of PageTableBase. It also modifies the constructor of TlbEntry structs for all architectures to consider the new attributes. Diffs (updated) - src/arch/alpha/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/arm/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/mips/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/power/tlb.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/sparc/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/x86/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/x86/pagetable.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/multi_level_page_table.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/multi_level_page_table_impl.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/page_table.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/page_table.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/Process.py 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/process.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/process.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2462/diff/ Testing --- Quick regressions testing done. Thanks, Alexandru Dutu ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2462: mem: Page Table map api modification
On Nov. 18, 2014, 4:30 p.m., Andreas Hansson wrote: src/mem/page_table.hh, line 95 http://reviews.gem5.org/r/2462/diff/1/?file=42140#file42140line95 I'd suggest to specify the storage type (uint32_t) Alexandru Dutu wrote: Thought it is the only enum that will have an explicit storage type. We have to start somewhere :-) - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2462/#review5474 --- On Nov. 20, 2014, 6:27 a.m., Alexandru Dutu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2462/ --- (Updated Nov. 20, 2014, 6:27 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10553:d4148bafebad --- mem: Page Table map api modification This patch adds uncacheable/cacheable and read-only/read-write attributes to the map method of PageTableBase. It also modifies the constructor of TlbEntry structs for all architectures to consider the new attributes. Diffs - src/arch/alpha/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/arm/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/mips/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/power/tlb.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/sparc/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/x86/pagetable.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/arch/x86/pagetable.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/multi_level_page_table.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/multi_level_page_table_impl.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/page_table.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/mem/page_table.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/Process.py 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/process.hh 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 src/sim/process.cc 288eb5ee4b0026d0cc1f02ec31748e0eaac06bc3 Diff: http://reviews.gem5.org/r/2462/diff/ Testing --- Quick regressions testing done. Thanks, Alexandru Dutu ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
