[gem5-dev] changeset in gem5: dev: Use fixed size member variables to descr...
changeset 288eb5ee4b00 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=288eb5ee4b00 description: dev: Use fixed size member variables to describe fixed size PL111 registers. diffstat: src/dev/arm/pl111.hh | 24 1 files changed, 12 insertions(+), 12 deletions(-) diffs (65 lines): diff -r f66948658a36 -r 288eb5ee4b00 src/dev/arm/pl111.hh --- a/src/dev/arm/pl111.hh Mon Nov 17 01:45:42 2014 -0800 +++ b/src/dev/arm/pl111.hh Tue Nov 18 02:38:23 2014 -0800 @@ -200,10 +200,10 @@ TimingReg3 lcdTiming3; /** Upper panel frame base address register */ -int lcdUpbase; +uint32_t lcdUpbase; /** Lower panel frame base address register */ -int lcdLpbase; +uint32_t lcdLpbase; /** Control register */ ControlReg lcdControl; @@ -219,27 +219,27 @@ /** 256x16-bit color palette registers * 256 palette entries organized as 128 locations of two entries per word */ -int lcdPalette[LcdPaletteSize]; +uint32_t lcdPalette[LcdPaletteSize]; /** Cursor image RAM register * 256-word wide values defining images overlaid by the hw cursor mechanism */ -int cursorImage[CrsrImageSize]; +uint32_t cursorImage[CrsrImageSize]; /** Cursor control register */ -int clcdCrsrCtrl; +uint32_t clcdCrsrCtrl; /** Cursor configuration register */ -int clcdCrsrConfig; +uint32_t clcdCrsrConfig; /** Cursor palette registers */ -int clcdCrsrPalette0; -int clcdCrsrPalette1; +uint32_t clcdCrsrPalette0; +uint32_t clcdCrsrPalette1; /** Cursor XY position register */ -int clcdCrsrXY; +uint32_t clcdCrsrXY; /** Cursor clip position register */ -int clcdCrsrClip; +uint32_t clcdCrsrClip; /** Cursor interrupt mask set/clear register */ InterruptReg clcdCrsrImsc; @@ -290,10 +290,10 @@ Addr curAddr; /** DMA FIFO watermark */ -int waterMark; +uint32_t waterMark; /** Number of pending dma reads */ -int dmaPendingNum; +uint32_t dmaPendingNum; /** Send updated parameters to the vnc server */ void updateVideoParams(); ___ 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 Nov. 18, 2014, 2:54 a.m., Ali Saidi wrote: This will break compilation on non-linux platforms, so if we need something like this, it will need to have two checks, one that kvm is possible, and the other that it's enabled. However, that alone doesn't solve the problem because the issue is that now devices will exist that need KVM, but if KVM isn't compiled... One solution is a skeleton header that can be used in case !USE_KVM, but as you allude to this is very ugly. Off the top of my head the way I'd prefer to see it done is let objects register ranges with the System object and then the KVM code could iterate that list if it was compiled in. Sound reasonable? Gabe Black wrote: Well it's not just header files, it's also the python Param stuff. Param.KvmVM doesn't work if KvmVM isn't a parameter type, even if it won't be set to anything. It won't really help for there to be a static list of ranges because we need to move the framebuffer around in response to changes in the devices BARs. We need to control the placement dynamically, at least from the perspective of the simulation. Andreas Hansson wrote: As Ali points out, we need to make sure this still builds on non-Linux platforms, and another case to watch out for is the NULL isa. Is the reason for this patch the registration and enumeration of the memory ranges? If so, may I propose we introduce a DeviceMemory class or similar, and then use multiple inheritance. The DeviceMemory could be responsible for the APi needed to setup and manage the memory ranges, and still be independent of the KVM code. Do you think that would work? The original issue is that the device we're trying to use with x86 has its own framebuffer and doesn't DMA in a region of memory. That means that every byte the kernel writes into the frame buffer causes the VM to exit which wrecks performance. That's not a problem on ARM (as implemented) because it periodically grabs memory which will naturally batch together changes. The way we worked around the problem was to mark the framebuffer in the graphics device as memory so that writes to it don't cause the VM to exit. The device then periodically tells VNC its buffer is dirty whether it is or not. That was done by injecting new regions into PhysMem which would then use a hacked in back door to add the region to the VM after the fact. This version attempts to clean that up a bit by making the device talk to KVM directly instead of going through PhysMem. To do that, the graphics device needs to have a pointer to tell it where the KVM object is, and that requires a Param.KvmVM. If the KvmVM Simobject hasn't been enabled, that doesn't work. The graphics device can't record where it wants the framebuffer to map to ahead of time for the KvmVM object to discover since its location is set by a BAR configured by the kernel as it runs. The intention is that if KVM isn't available, the parameter/pointer passed to the graphics device will be NULL and the graphics device won't do anything KVM related. I'm not sure how a DeviceMemory class will help, particularly because it would need to reconfigure the memory range's mapping in the guest on the fly and hence need to operate on the KVM instance. If I'm just not seeing something please let me know. Is the USE_KVM setting visible as a preprocessor directive in the C++? If so, I could use that to set the kvm pointer to NULL if KVM is turned off instead of getting it from the parameters. Then the question is how to condition adding the KVM parameter to the python version of the device. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2513/#review5461 --- On Nov. 18, 2014, 2:27 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2513/ --- (Updated Nov. 18, 2014, 2:27 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10548:47efc3192cf5 --- KVM: Build in most of the KVM stuff even if we're not going to use it. Otherwise it's impossible (or at least highly impractical) to use the KVM VM as an optional parameter on objects which aren't conditionally built. If there's no KVM instance that gets set up, those pointers should just be NULL. Diffs - src/cpu/kvm/SConscript f66948658a36b6874e84ee5da37e70d351287cb4 Diff: http://reviews.gem5.org/r/2513/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
The member functions before_end_of_elaboration and end_of_elaboration are
defined on sc_core::sc_module and the SystemC simulation kernel handles calling
them at the appropriate times.
Try printing something in main.cc:SimControl::before_end_of_elaboration and you
should see that print happening before the simulation starts running.
- Andrew
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Cagdas Dirik via
gem5-dev
Sent: 17 November 2014 23:45
To: Cagdas Dirik; Andreas Hansson; Default
Subject: Re: [gem5-dev] Review Request 2504: config: Fix to SystemC example's
event handling
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2504/#review5460
---
I think you are missing the call to SimControl::before_end_of_elaboration().
May be after sim_control is instantiated, but before sc_start is called?
int
sc_main(int argc, char **argv)
{
SimControl sim_control(gem5, argc, argv);
== sim_control.before_end_of_elaboration();
sc_core::sc_start();
return EXIT_SUCCESS;
}
- Cagdas Dirik
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
-- 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 2513: KVM: Build in most of the KVM stuff even if we're not going to use it.
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 Steve ___ 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.
Is the USE_KVM setting visible as a preprocessor directive in the C++? If so, I could use that to set the kvm pointer to NULL if KVM is turned off instead of getting it from the parameters. Then the question is how to condition adding the KVM parameter to the python version of the device. Seems like this should be easy to make happen, no? There's something that has to choose to link KVM or not. That could easily create a config option. Nate ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2491: mem: Add const getters for write packet data
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/#review5467 --- src/mem/packet.hh http://reviews.gem5.org/r/2491/#comment4917 I think we can keep the function name as getPtr() and rely on the compiler to pick the right version. Also how about const_castT* instead of C style casting? - Nilay Vaish On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10541:d68e4d58597b --- mem: Add const getters for write packet data This patch takes a first step in tightening up how we use the data pointer in write packets. A const getter is added for the pointer itself (getConstPtr), and a number of member functions are also made const accordingly. In a range of places throughout the memory system the new member is used. Diffs - src/cpu/inorder/resources/cache_unit.cc 1a9e235cab09 src/cpu/inorder/resources/fetch_unit.cc 1a9e235cab09 src/cpu/minor/execute.cc 1a9e235cab09 src/cpu/minor/lsq.cc 1a9e235cab09 src/cpu/o3/fetch_impl.hh 1a9e235cab09 src/cpu/simple/atomic.cc 1a9e235cab09 src/cpu/testers/memtest/memtest.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/abstract_mem.cc 1a9e235cab09 src/mem/cache/cache.hh 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/external_slave.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 src/mem/packet_access.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2491/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 2490: mem: Remove null-check bypassing in Packet::getPtr
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2490/#review5469 --- Overall I am fine with the patch. Can we set the size to 1 when the prefetch request is being created? I don't see any harm in that. src/mem/ruby/system/Sequencer.cc http://reviews.gem5.org/r/2490/#comment4919 Typo in prefetche. - Nilay Vaish On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2490/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10540:0d0fabda59bd --- mem: Remove null-check bypassing in Packet::getPtr This patch removes the parameter that enables bypassing the null check in the Packet::getPtr method. A number of call sites assume the value to be non-null. The one odd case is the RubyTester, which issues zero-sized prefetches(!), and despite being reads they had no valid data pointer. This is now fixed, but the size oddity remains (unless anyone object or has any good suggestions). Finally, in the Ruby Sequencer, appropriate checks are made for flush packets as they have no valid data pointer. Diffs - src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/DMASequencer.cc 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2490/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] bug? in elf loader
I checked the elf-64 draft and I think you right. But I am not able to
understand why do we use p_paddr at all. Should we not be using p_vaddr
everywhere?
--
Nilay
On Tue, 18 Nov 2014, Romana, Alexandre via gem5-dev wrote:
Hi everybody,
Looks to me like there is a bug/typo in elf_loader.cc:
318 // Check to see if this segment contains the bss section.
319 if (phdr.p_paddr = bssSecStart
320 phdr.p_paddr + phdr.p_memsz bssSecStart
321 phdr.p_memsz - phdr.p_filesz 0) {
322 bss.baseAddr = phdr.p_paddr + phdr.p_filesz;
323 bss.size = phdr.p_memsz - phdr.p_filesz;
324 bss.fileImage = NULL;
325 }
326
327 // Check to see if this is the text or data segment
328 if (phdr.p_vaddr = textSecStart
329 phdr.p_vaddr + phdr.p_filesz textSecStart) {
330 text.baseAddr = phdr.p_paddr;
331 text.size = phdr.p_filesz;
332 text.fileImage = fileData + phdr.p_offset;
333 } else if (phdr.p_vaddr = dataSecStart
334 phdr.p_vaddr + phdr.p_filesz dataSecStart) {
335 data.baseAddr = phdr.p_paddr;
336 data.size = phdr.p_filesz;
337 data.fileImage = fileData + phdr.p_offset;
338 } else {
339 // If it's none of the above but is loadable,
340 // load the filesize worth of data
341 Segment extra;
342 extra.baseAddr = phdr.p_paddr;
343 extra.size = phdr.p_filesz;
344 extra.fileImage = fileData + phdr.p_offset;
345 extraSegments.push_back(extra);
I guess nobody used so far the loader with the bss section mapped onto a
segment with different virtual and physical addresses…
To double check you can look at the bssSecStart definition:
bssSecStart = shdr.sh_addr;
sh_addr being the virtual address, I think we can safely assume there’s a typo
line 319-320, and I can submit a patch (changing 2 characters in the code),
or could anybody please explain why we are comparing virtual with physical
addresses here?
Thanks,
Alexandre
Texas Instruments France SAS, Immeuble Le Khapa, 65 Quai Georges Gorse, ZAC
Seguin Rives de Seine, 92100 Boulogne Billancourt. 036 420 040 R.C.S Nanterre.
Capital de EUR 12.654.784
___
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] Review Request 2492: mem: Use const pointers for port proxy write functions
On Nov. 18, 2014, 3:36 p.m., Nilay Vaish wrote: src/mem/port_proxy.cc, line 80 http://reviews.gem5.org/r/2492/diff/1/?file=42518#file42518line80 Do we need this scope resolution? We do. It took me the better part of a day to track it down even... - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2492/#review5468 --- On Nov. 17, 2014, 6:14 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2492/ --- (Updated Nov. 17, 2014, 6:14 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10542:6cbdd036f4b9 --- mem: Use const pointers for port proxy write functions This patch changes the various write functions in the port proxies to use const pointers for all sources (similar to how memcpy works). The one unfortunate aspect is the need for a const_cast in the packet, to avoid having to juggle a const and a non-const data pointer. This design decision can always be re-evaluated at a later stage. Diffs - src/mem/fs_translating_port_proxy.hh 1a9e235cab09 src/mem/fs_translating_port_proxy.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/port_proxy.hh 1a9e235cab09 src/mem/port_proxy.cc 1a9e235cab09 src/mem/se_translating_port_proxy.hh 1a9e235cab09 src/mem/se_translating_port_proxy.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2492/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 2490: mem: Remove null-check bypassing in Packet::getPtr
On Nov. 18, 2014, 3:44 p.m., Nilay Vaish wrote: Overall I am fine with the patch. Can we set the size to 1 when the prefetch request is being created? I don't see any harm in that. It might incur stats changes...that's my main reason for not changing anything. Perhaps it's worth fixing that as part of a patch on its own though. I would assume the prefetch should be cache line sized? - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2490/#review5469 --- On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2490/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10540:0d0fabda59bd --- mem: Remove null-check bypassing in Packet::getPtr This patch removes the parameter that enables bypassing the null check in the Packet::getPtr method. A number of call sites assume the value to be non-null. The one odd case is the RubyTester, which issues zero-sized prefetches(!), and despite being reads they had no valid data pointer. This is now fixed, but the size oddity remains (unless anyone object or has any good suggestions). Finally, in the Ruby Sequencer, appropriate checks are made for flush packets as they have no valid data pointer. Diffs - src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/DMASequencer.cc 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2490/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 2491: mem: Add const getters for write packet data
On Nov. 18, 2014, 3:32 p.m., Nilay Vaish wrote: src/mem/packet.hh, line 860 http://reviews.gem5.org/r/2491/diff/1/?file=42506#file42506line860 I think we can keep the function name as getPtr() and rely on the compiler to pick the right version. Also how about const_castT* instead of C style casting? I'd actually prefer it to be explicit at this point if you don't mind. I has helped me figure out where we should be using const but cannot due to the way read/write is part of the same function, but with a bool is_read (which is currently done in a lot of devices for example). - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/#review5467 --- On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10541:d68e4d58597b --- mem: Add const getters for write packet data This patch takes a first step in tightening up how we use the data pointer in write packets. A const getter is added for the pointer itself (getConstPtr), and a number of member functions are also made const accordingly. In a range of places throughout the memory system the new member is used. Diffs - src/cpu/inorder/resources/cache_unit.cc 1a9e235cab09 src/cpu/inorder/resources/fetch_unit.cc 1a9e235cab09 src/cpu/minor/execute.cc 1a9e235cab09 src/cpu/minor/lsq.cc 1a9e235cab09 src/cpu/o3/fetch_impl.hh 1a9e235cab09 src/cpu/simple/atomic.cc 1a9e235cab09 src/cpu/testers/memtest/memtest.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/abstract_mem.cc 1a9e235cab09 src/mem/cache/cache.hh 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/external_slave.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 src/mem/packet_access.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2491/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 2462: mem: Page Table map api modification
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2462/#review5474 --- src/arch/x86/pagetable.hh http://reviews.gem5.org/r/2462/#comment4922 i guess these should be const src/mem/page_table.hh http://reviews.gem5.org/r/2462/#comment4923 I'd suggest to specify the storage type (uint32_t) src/sim/process.hh http://reviews.gem5.org/r/2462/#comment4924 please update the doxygen comments Some minor things. Looks ok for the rest. - Andreas Hansson 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 2492: mem: Use const pointers for port proxy write functions
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2492/#review5475 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:14 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2492/ --- (Updated Nov. 17, 2014, 6:14 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10542:6cbdd036f4b9 --- mem: Use const pointers for port proxy write functions This patch changes the various write functions in the port proxies to use const pointers for all sources (similar to how memcpy works). The one unfortunate aspect is the need for a const_cast in the packet, to avoid having to juggle a const and a non-const data pointer. This design decision can always be re-evaluated at a later stage. Diffs - src/mem/fs_translating_port_proxy.hh 1a9e235cab09 src/mem/fs_translating_port_proxy.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/port_proxy.hh 1a9e235cab09 src/mem/port_proxy.cc 1a9e235cab09 src/mem/se_translating_port_proxy.hh 1a9e235cab09 src/mem/se_translating_port_proxy.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2492/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 2491: mem: Add const getters for write packet data
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/#review5477 --- Ship it! Ship It! - Nilay Vaish On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10541:d68e4d58597b --- mem: Add const getters for write packet data This patch takes a first step in tightening up how we use the data pointer in write packets. A const getter is added for the pointer itself (getConstPtr), and a number of member functions are also made const accordingly. In a range of places throughout the memory system the new member is used. Diffs - src/cpu/inorder/resources/cache_unit.cc 1a9e235cab09 src/cpu/inorder/resources/fetch_unit.cc 1a9e235cab09 src/cpu/minor/execute.cc 1a9e235cab09 src/cpu/minor/lsq.cc 1a9e235cab09 src/cpu/o3/fetch_impl.hh 1a9e235cab09 src/cpu/simple/atomic.cc 1a9e235cab09 src/cpu/testers/memtest/memtest.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/abstract_mem.cc 1a9e235cab09 src/mem/cache/cache.hh 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/external_slave.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 src/mem/packet_access.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2491/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 2491: mem: Add const getters for write packet data
On Nov. 18, 2014, 3:32 p.m., Nilay Vaish wrote: src/mem/packet.hh, line 860 http://reviews.gem5.org/r/2491/diff/1/?file=42506#file42506line860 I think we can keep the function name as getPtr() and rely on the compiler to pick the right version. Also how about const_castT* instead of C style casting? Andreas Hansson wrote: I'd actually prefer it to be explicit at this point if you don't mind. I has helped me figure out where we should be using const but cannot due to the way read/write is part of the same function, but with a bool is_read (which is currently done in a lot of devices for example). As you like it. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/#review5467 --- On Nov. 17, 2014, 6:13 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2491/ --- (Updated Nov. 17, 2014, 6:13 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10541:d68e4d58597b --- mem: Add const getters for write packet data This patch takes a first step in tightening up how we use the data pointer in write packets. A const getter is added for the pointer itself (getConstPtr), and a number of member functions are also made const accordingly. In a range of places throughout the memory system the new member is used. Diffs - src/cpu/inorder/resources/cache_unit.cc 1a9e235cab09 src/cpu/inorder/resources/fetch_unit.cc 1a9e235cab09 src/cpu/minor/execute.cc 1a9e235cab09 src/cpu/minor/lsq.cc 1a9e235cab09 src/cpu/o3/fetch_impl.hh 1a9e235cab09 src/cpu/simple/atomic.cc 1a9e235cab09 src/cpu/testers/memtest/memtest.cc 1a9e235cab09 src/cpu/testers/rubytest/Check.cc 1a9e235cab09 src/mem/abstract_mem.cc 1a9e235cab09 src/mem/cache/cache.hh 1a9e235cab09 src/mem/cache/cache_impl.hh 1a9e235cab09 src/mem/external_slave.cc 1a9e235cab09 src/mem/packet.hh 1a9e235cab09 src/mem/packet.cc 1a9e235cab09 src/mem/packet_access.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.hh 1a9e235cab09 src/mem/ruby/common/DataBlock.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubyRequest.cc 1a9e235cab09 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 1a9e235cab09 src/mem/ruby/system/Sequencer.cc 1a9e235cab09 Diff: http://reviews.gem5.org/r/2491/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
I did not know about those (timely) systemc callbacks - reading about them now.
Thank you for pointing them out!
Cagdas
On Nov 18, 2014, at 5:10 AM, Andrew Bardsley via gem5-dev
gem5-dev@gem5.orgmailto:gem5-dev@gem5.org wrote:
The member functions before_end_of_elaboration and end_of_elaboration are
defined on sc_core::sc_module and the SystemC simulation kernel handles calling
them at the appropriate times.
Try printing something in main.cc:SimControl::before_end_of_elaboration and you
should see that print happening before the simulation starts running.
- Andrew
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Cagdas Dirik via
gem5-dev
Sent: 17 November 2014 23:45
To: Cagdas Dirik; Andreas Hansson; Default
Subject: Re: [gem5-dev] Review Request 2504: config: Fix to SystemC example's
event handling
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2504/#review5460
---
I think you are missing the call to SimControl::before_end_of_elaboration().
May be after sim_control is instantiated, but before sc_start is called?
int
sc_main(int argc, char **argv)
{
SimControl sim_control(gem5, argc, argv);
== sim_control.before_end_of_elaboration();
sc_core::sc_start();
return EXIT_SUCCESS;
}
- Cagdas Dirik
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.cchttp://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.orgmailto: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.orgmailto: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] [gem5-users] x86 SE mode kvm support?
Hi Mike, There are some patches ready to be committed for this to work. I expect them to be committed by the end of this week. Best regards, Alex -- Forwarded message -- From: Mike Upton via gem5-users gem5-us...@gem5.orgmailto:gem5-us...@gem5.org Date: Mon, Nov 17, 2014 at 3:15 PM Subject: [gem5-users] x86 SE mode kvm support? To: gem5-us...@gem5.orgmailto:gem5-us...@gem5.org gem5-us...@gem5.orgmailto:gem5-us...@gem5.org How do I do a gem5 run in SE with KVM enabled? I tried: ./build/X86/gem5.opt configs/example/se.py –c hello_world_path/hello --cpu-type=kvm I get an error : Can’t resolve proxy ‘any’ of type ‘KvmVM’ from ‘system.cpu’ Looking in Options.py, I think I have the right type setting… I see a few other folks have asked the same question, but I could not find an answer. Thanks, Mike ___ gem5-users mailing list gem5-us...@gem5.orgmailto:gem5-us...@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ 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 Tue, 18 Nov 2014, 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 But would not this also cause the same problem that we cannot compile on systems that do not have kvm support? In Andreas' suggestion, we would be selectively compiling certain file(s) which should resolve the issue. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Error while building gem5.fast on latest on copy of gem5
Here are my versions - 1) python 2.7.3 2) SCons by Steven Knight et al.: script: v2.1.0.r5357[MODIFIED], 2011/09/09 21:31:03, by bdeegan on ubuntu engine: v2.1.0.r5357[MODIFIED], 2011/09/09 21:31:03, by bdeegan on ubuntu engine path: ['/usr/lib/scons/SCons'] Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 The SCons Foundation 3) gcc - 4.6.2 4) g++ - 4.6.2 Does a simulation run also depend on the compiler used to compile the files? I have a fs simulation that works on my ubuntu 14.04 machine for latest gem5 code, but does not work on the ubuntu 12.04 machine. I am trying to run a full system simulation for ARMv8. What compiler and version are you using? Ali On 11/17/14, 2:37 PM, Urmish Ajit Thakker via gem5-dev gem5-dev@gem5.org wrote: Hi, I pulled up the latest copy of gem5 and got the following error while building gem5.fast. build/ARM/proto/protoio.fo (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters /tmp/ccLsqIGW.ltrans31.ltrans.o:(.rodata+0xb70): undefined reference to `ArmISA::ArmFaultValsArmISA::IllegalInstSetStateFault::offset(ThreadCont ext*)' /tmp/ccLsqIGW.ltrans31.ltrans.o:(.rodata+0x1e50): undefined reference to `ArmISA::ArmFaultValsArmISA::IllegalInstSetStateFault::offset(ThreadCont ext*)' collect2: ld returned 1 exit status scons: *** [build/ARM/gem5.fast.unstripped] Error 1 scons: building terminated because of errors. Could anyone help me with this error? Regards, Urmish ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev [1] -- 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 [1] Links: -- [1] 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] Review Request 2504: config: Fix to SystemC example's event handling
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5479 --- I think there are still synchronization issues with curTick and systemc time I am testing FS, X86 with a small array manipulation program. I booted using python variant, created a checkpoint right before ROI. Python variant seems to restore checkpoint and run. But systemc variant cannot. I have both r2503 and this patch applied. Checkpoint restores in FS mode, but right after it fails the check assert(curTick() = systemc_time) on Module::EventLoop info: kernel located at: ... Listening for com_1 connection on port 3456 Info: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 warn: Reading current count from inactive timer. Restoring checkpoint Waiting for 5714639839500ps for SystemC to catch up to gem5 gem5.opt.sc: sc_module.cc:148: void Gem5SystemC::Module::eventLoop(): Assertion `curTick() = systemc_time' failed. Program aborted at cycle 5714639839500 Aborted - Cagdas Dirik 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] bug? in elf loader
I think there were cases where the ELF loader was used to load to actual
physical addresses in FS mode. I don't remember the specifics.
Gabe
On Tue, Nov 18, 2014 at 8:21 AM, Nilay Vaish via gem5-dev gem5-dev@gem5.org
wrote:
I checked the elf-64 draft and I think you right. But I am not able to
understand why do we use p_paddr at all. Should we not be using p_vaddr
everywhere?
--
Nilay
On Tue, 18 Nov 2014, Romana, Alexandre via gem5-dev wrote:
Hi everybody,
Looks to me like there is a bug/typo in elf_loader.cc:
318 // Check to see if this segment contains the bss section.
319 if (phdr.p_paddr = bssSecStart
320 phdr.p_paddr + phdr.p_memsz bssSecStart
321 phdr.p_memsz - phdr.p_filesz 0) {
322 bss.baseAddr = phdr.p_paddr + phdr.p_filesz;
323 bss.size = phdr.p_memsz - phdr.p_filesz;
324 bss.fileImage = NULL;
325 }
326
327 // Check to see if this is the text or data segment
328 if (phdr.p_vaddr = textSecStart
329 phdr.p_vaddr + phdr.p_filesz textSecStart) {
330 text.baseAddr = phdr.p_paddr;
331 text.size = phdr.p_filesz;
332 text.fileImage = fileData + phdr.p_offset;
333 } else if (phdr.p_vaddr = dataSecStart
334 phdr.p_vaddr + phdr.p_filesz dataSecStart) {
335 data.baseAddr = phdr.p_paddr;
336 data.size = phdr.p_filesz;
337 data.fileImage = fileData + phdr.p_offset;
338 } else {
339 // If it's none of the above but is loadable,
340 // load the filesize worth of data
341 Segment extra;
342 extra.baseAddr = phdr.p_paddr;
343 extra.size = phdr.p_filesz;
344 extra.fileImage = fileData + phdr.p_offset;
345 extraSegments.push_back(extra);
I guess nobody used so far the loader with the bss section mapped onto a
segment with different virtual and physical addresses…
To double check you can look at the bssSecStart definition:
bssSecStart = shdr.sh_addr;
sh_addr being the virtual address, I think we can safely assume there’s
a typo line 319-320, and I can submit a patch (changing 2 characters in the
code),
or could anybody please explain why we are comparing virtual with
physical addresses here?
Thanks,
Alexandre
Texas Instruments France SAS, Immeuble Le Khapa, 65 Quai Georges Gorse,
ZAC Seguin Rives de Seine, 92100 Boulogne Billancourt. 036 420 040 R.C.S
Nanterre. Capital de EUR 12.654.784
___
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] 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/#review5480 --- src/arch/x86/pseudo_inst.hh http://reviews.gem5.org/r/2313/#comment4930 I think this can probably be in the main X86ISA namespace. That would remove the need for a new magic macro up in src/SConscript. src/arch/x86/pseudo_inst.hh http://reviews.gem5.org/r/2313/#comment4931 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*. src/arch/x86/pseudo_inst.cc http://reviews.gem5.org/r/2313/#comment4927 Don't put spaces inside the parenthesis. src/arch/x86/pseudo_inst.cc http://reviews.gem5.org/r/2313/#comment4928 Put spaces around the operator. src/arch/x86/pseudo_inst.cc http://reviews.gem5.org/r/2313/#comment4929 Remove extra space. util/m5/m5ops.h http://reviews.gem5.org/r/2313/#comment4932 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. - Gabe Black 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
