[gem5-dev] Arm native build/test time jumped tremendously on apr 30

[mike upton via gem5-dev]

   1. scons: Revert "Enable LTO for opt, perf and prof builds."
   2. scons: Add `--with-lto` to enabled LTO; remove `--no-lto`
   3. base: Stop "using namespace Debug" in DPRINTF style macros.
   4. sim: Stop using DPRINTF_UNCONDITIONAL in the event class.
   5. base: Fill out the 'H' thread setting command in remote GDB.
   6. base: Make the BaseRemoteGDB class able to handle multiple TCs.
   7. arch-sparc: Use GuestABI to call pseudo insts.


Hi, i was poking around my jenkins server and saw the build/test time on
native aarch64 build and run went from 4 hrs to 8 hrs on apr 30.

the above are the relevant commits.

maybe the LTO flags? I cant tell if 1 and 2 cancel each other out.

my arm build is on a 4 core raspberry pi 4, so pretty wimpy.
have the arm folks seen something similar?
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: tutorial docs

[mike upton via gem5-dev]

I have verified that the tutorial works in its original form on 20.0.0.3
and in its new form on 20.1.0.5

It segfaults on the current stable master: 21.0.0.0



On Thu, Apr 15, 2021 at 8:18 AM Jason Lowe-Power 
wrote:

> Hi Mike,
>
> It's a bit embarrassing how out of date our documentation is.
> Unfortunately, we have a really hard time finding the resources or
> convincing developers to update the documentation as the code changes.
>
> The canonical documentation can be found here:
> http://www.gem5.org/documentation/
> and the Learning gem5 material here:
> http://www.gem5.org/documentation/learning_gem5/introduction/
>
> There's definitely mistakes and things that have changed. We would greatly
> appreciate contributions. The code is available here:
> https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/
> and it's reviewed the same way as regular gem5 code.
>
> Let me know if you have any questions about contributing, etc.
>
> Cheers,
> Jason
>
> On Thu, Apr 15, 2021 at 8:04 AM mike upton via gem5-dev 
> wrote:
>
>> Hi,
>> do we (I) have edit permissions on the tutorial documentation?
>>
>> I tried to follow the first steps of the tutorial, and the instructions
>> are out of date for the develop head. Some googling resulted in the
>> solution, but for me it still does not execute correctly.
>>
>> It looks like there are Jira issues documenting the needed updates.
>>
>> I have some issue where the tutorial is segfaulting.
>>
>> Can someone else verify that the tutorial actually works?
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] tutorial docs

[mike upton via gem5-dev]

Hi,
do we (I) have edit permissions on the tutorial documentation?

I tried to follow the first steps of the tutorial, and the instructions are
out of date for the develop head. Some googling resulted in the solution,
but for me it still does not execute correctly.

It looks like there are Jira issues documenting the needed updates.

I have some issue where the tutorial is segfaulting.

Can someone else verify that the tutorial actually works?
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: Nightly #118

[mike upton via gem5-dev]

The proposed patch fixes the issue.
My long runs now pass again.


On Wed, Nov 4, 2020 at 8:14 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi all,
>
> I'm pretty sure https://gem5-review.googlesource.com/c/public/gem5/+/34984
> is the breaking change on last night's build.
>
> It's unfortunate how much time/effort supporting MIPS and other ISAs
> takes...
>
> Cheers,
> Jason
>
> On Tue, Nov 3, 2020 at 11:03 PM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/Nightly/118/display/redirect?page=changes>
>>
>> Changes:
>>
>> [gabe.black] arch: Clean up the __init__s in (Sub)OperandList.
>>
>> [davide.basilio.bartolini] configs: Do not require default options for
>> caches
>>
>> [giacomo.travaglini] cpu, fastmodel: Remove the old getDTBPtr/getITBPtr
>> virtual methods
>>
>> [giacomo.travaglini] arch-arm: Add el2Enabled cached variable
>>
>> [giacomo.travaglini] arch-arm: Fix implementation of TLBI_VMALL
>> instructions
>>
>> [giacomo.travaglini] arch-arm: TlbEntry flush to be considered as
>> functional lookup
>>
>> [giacomo.travaglini] arch-arm: Do not use _flushMva for TLBI IPA
>>
>> [yuhsingw] configs: Add dtb-gen to fs_bigLITTLE.py
>>
>>
>> --
>> [...truncated 68.77 KB...]
>>  [SO PARAM] DMA_Controller -> MIPS/params/DMA_Controller.hh
>>  [MAKE INC] MIPS/mem/ruby/common/BoolVec.hh -> protocol/BoolVec.hh
>>  [MAKE INC] MIPS/mem/ruby/structures/CacheMemory.hh ->
>> protocol/CacheMemory.hh
>>  [MAKE INC] MIPS/mem/ruby/system/DMASequencer.hh ->
>> protocol/DMASequencer.hh
>>  [MAKE INC] MIPS/mem/ruby/structures/DirectoryMemory.hh ->
>> protocol/DirectoryMemory.hh
>>  [MAKE INC] MIPS/mem/ruby/system/HTMSequencer.hh ->
>> protocol/HTMSequencer.hh
>>  [SO PARAM] RubyPrefetcher -> MIPS/params/RubyPrefetcher.hh
>>  [MAKE INC] MIPS/mem/ruby/structures/RubyPrefetcher.hh ->
>> protocol/RubyPrefetcher.hh
>>  [MAKE INC] MIPS/mem/ruby/system/Sequencer.hh -> protocol/Sequencer.hh
>>  [MAKE INC] MIPS/mem/ruby/common/Set.hh -> protocol/Set.hh
>>  [MAKE INC] MIPS/mem/ruby/structures/TimerTable.hh ->
>> protocol/TimerTable.hh
>>  [SO PARAM] RubyWireBuffer -> MIPS/params/RubyWireBuffer.hh
>>  [MAKE INC] MIPS/mem/ruby/structures/WireBuffer.hh ->
>> protocol/WireBuffer.hh
>>  [MAKE INC] MIPS/mem/ruby/common/WriteMask.hh -> protocol/WriteMask.hh
>>  [MAKE INC] MIPS/mem/ruby/slicc_interface/AbstractCacheEntry.hh ->
>> protocol/AbstractCacheEntry.hh
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Event.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_State.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_TBE.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DirectoryRequestType.cc -> .o
>>  [SO PARAM] Directory_Controller -> MIPS/params/Directory_Controller.hh
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Entry.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Event.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_State.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_TBE.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/HtmCallbackMode.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/HtmFailedInCacheReason.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/InvalidateGeneratorStatus.cc -> .o
>>  [SO PARAM] L1Cache_Controller -> MIPS/params/L1Cache_Controller.hh
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Entry.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Event.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_State.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_TBE.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/LinkDirection.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/LockStatus.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorIndex.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorTraining.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorType.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MemoryControlRequestType.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MemoryMsg.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MemoryRequestType.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MessageSizeType.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/PrefetchBit.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/RequestMsg.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/RequestStatus.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Respon

[gem5-dev] successful build setup on arm system

[mike upton via gem5-dev]

Hi,

I am back to testing on an arm SBC.

Does anyone know the recipe for a successful build on an arm box?

GCC9 and clang 10 builds both die with obscure internal compiler errors.

This is on an ubuntu 20.04 setup, compiling the develop branch.

scons CC=clang CXX=clang++ build/ARM/gem5.opt -j4

I needed quite a few compiler warning overrides to get the clang10 build
going.

the above build command works fine on an x86_64 box.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] ubuntu boot test failure

[mike upton via gem5-dev]

Hi,
I posted a jira issue on this but there has been no updates.

https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-795

When I run the long test regression, the compressed ubuntu boot images are
copied down OK,
but the uncompressed file is size 0 and the test dies.

If I manually unzip it so that it is there before the regression runs, then
the test works.

The location of all the files seems to have moved around some.

Any ideas what I am doing wrong?

thanks
Mike
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: simple simulator performance check?

[mike upton via gem5-dev]

x86 linux boot is a component of the '--length long' regression.
You need the kernel and disk image that are installed when the regression
is run.

command line:
 ./build/X86/gem5.opt ./tests/gem5/x86-boot-tests/run_exit.py --kernel
boot-test/vmlinux-4.19.83 --disk boot-test/base.img --cpu-type atomic
--num-cpus 1 --boot-type init



On Sat, Oct 10, 2020 at 10:22 PM Gabe Black via gem5-dev 
wrote:

> I'm planning to give this a shot, but is there a simple command line for
> this? It would take a lot of time to set up a system and all that, and it
> would be much nicer to just fire off, for instance, a linux boot test if we
> already have something lying around.
>
> Gabe
>
> On Wed, Oct 7, 2020 at 10:41 AM Jason Lowe-Power 
> wrote:
>
>> I think Linux boot is pretty reasonable. Or, Linux boot + some
>> multithreaded tests (parsec is available for x86 in gem5-resources). If
>> there isn't much performance impact there, I think that would be strong
>> evidence for little performance impact, generally.
>>
>> Cheers,
>> Jason
>>
>> On Mon, Oct 5, 2020 at 3:07 AM Gabe Black via gem5-dev 
>> wrote:
>>
>>> Hey folks. I'm trying out using dynamically allocated arrays to track
>>> source and destination register indices in static and dynamic instructions
>>> rather than fixed size arrays and would like to check what the impact on
>>> performance is. I used to use the twolf SPEC benchmark for that since it
>>> was fairly quick and easy to run but still ran long enough to get
>>> meaningful results, but do we have something like that now that's maybe
>>> even easier to set up? Or is easier for other people to run?
>>>
>>> As far as the arrays, what I'm aiming at is to make it unnecessary to
>>> measure the max number of indices needed and hence the minimum size of
>>> those arrays since that centralized global value needs to reflect every
>>> instruction in gem5, and it would be a bit of a pain to coordinate that
>>> with multiple ISAs. Allocating those arrays statically as part of the
>>> StaticInst or DynInst classes makes allocation cheaper since it just makes
>>> the classes a little bigger, and making them dynamic will inevitably
>>> involve secondary allocations to give the vectors (for instance) their
>>> backing store. I'm hopeful it won't be that bad though, since StaticInsts
>>> are usually reused from a cache and not reallocated, and dynamic
>>> instructions are used in CPUs which already have lots of other, more
>>> substantial overhead.
>>>
>>> Gabe
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] gem5 python version?

[mike upton via gem5-dev]

Do we still support python2.7?

I am adding some functionality and it is cleanest in python3, but the code
will fail if running in python2.


thanks
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: gem5_develop #155

[mike upton via gem5-dev]

I saw the develop regression failed on run 153, so i added gem5-dev to the
mail list, cleaned the workspace, and kicked off another build.
The next 2 builds 154, and 155 also failed.

I dont understand what is going on. These same checkins are working fine on
my private jenkins server.

maybe a python2.7 vs python3 thing?




On Fri, Aug 28, 2020 at 1:23 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> Started by user michael upton
> Running as SYSTEM
> Building in workspace 
> The recommended git tool is: NONE
> No credentials specified
> Cloning the remote Git repository
> Cloning repository https://gem5.googlesource.com/public/gem5
>  > git init  # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
>  > git config --add remote.origin.fetch
> +refs/heads/*:refs/remotes/origin/* # timeout=10
> Avoid second fetch
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
> Checking out Revision fa13042b5a1b4120bb7d96d15170bbd5d5068fad
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f fa13042b5a1b4120bb7d96d15170bbd5d5068fad # timeout=10
> Commit message: "ext: remove libelf"
>  > git rev-list --no-walk fa13042b5a1b4120bb7d96d15170bbd5d5068fad #
> timeout=10
> [gem5_develop] $ /bin/sh -xe /tmp/jenkins6579710378508302396.sh
> + cd tests
> + ./main.py run -j 4 -t 4
> Running the new gem5 testing script.
> For more information see TESTING.md.
> To see details as the testing scripts are running, use the option -v, -vv,
> or -vvv
>
> 
> Loading Tests
> Discovered 2544 tests and 2544 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/asmtest/tests.py>
> Discovered 264 tests and 132 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/cpu_tests/test.py>
> Discovered 24 tests and 12 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/dram-lowp/test_dram_lowp.py
> >
> Discovered 166 tests and 166 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/fs/linux/arm/test.py
> >
> Discovered 270 tests and 135 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/hello_se/test_hello_se.py
> >
> Discovered 0 tests and 0 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/insttest_se/test.py
> >
> Discovered 48 tests and 48 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/learning_gem5/part1_test.py
> >
> Discovered 48 tests and 24 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/learning_gem5/part2_test.py
> >
> Discovered 18 tests and 9 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/learning_gem5/part3_test.py
> >
> Discovered 12 tests and 6 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/m5_util/test_exit.py
> >
> Discovered 0 tests and 0 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/m5threads_test_atomic/test.py
> >
> Discovered 72 tests and 72 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/memory/test.py>
> Discovered 18 tests and 18 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/test_build/test_build.py
> >
> Discovered 18 tests and 18 suites in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/x86-boot-tests/test_linux_boot.py
> >
>
> 
> Running Tests from 502 suites
> Results will be stored in <
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/.testing-results>
>
> 
> Building the following targets. This may take a while.
> 
> You may want to run with only a single ISA(--isa=), use --skip-build, or
> use 'rerun'.
> Traceback (most recent call last):
>   File "<
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/../ext/testlib/runner.py";,>
> line 199, in setup
> fixture.setup(testitem)
>   File "<
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/fixture.py";,>
> line 111, in setup
> self._setup(testitem)
>   File "<
> https://jenkins.gem5.org/job/gem5_develop/ws/tests/gem5/fixture.py";,>
> line 156, in _setup
> log

[gem5-dev] Re: Change in gem5/gem5[develop]: mem-cache: Create Compressor namespace

[mike upton via gem5-dev]

http://jenkins.gem5.org:8080/job/gem5_develop/buildTimeTrend

Yes, there is a trend tab on the build history.
The pretty graph is not showing up for some reason. I will look into that.

Note that the build machine is a 4 thread google cloud VM, so somewhat weak.


On Thu, Aug 27, 2020 at 11:58 PM Daniel Carvalho 
wrote:

> Out of curiosity, is the average execution time of these builds available
> somewhere?
>
>
> I agree that this should not concern those who are not in gem5-dev, but I
> think it was relevant to archive such an answer in gem5-users in case
> someone does not comply with this expectation and searches for a solution
> there.
>
>
> Regards,
>
> Daniel
> Em quinta-feira, 27 de agosto de 2020 20:58:40 GMT+2, Bobby Bruce via
> gem5-dev  escreveu:
>
>
> Just an FYI on this:
>
> The nightly builds don't clean the gem5 directory before pulling and
> recompiling. This saves us some build time. Obviously for stuff like this,
> we need a work around. I've therefore tweaked the building scripts with
> stuff like this:
>
> ```
> scons build/ARM/gem5.opt -j4 || (rm -rf build && scons build/ARM/gem5.opt
> -j4)
> ```
>
> Essentially, if a build fails, we start fresh and give it a second go. So,
> we shouldn't be bothered when stuff like this comes up.
>
> It would be really nice if we could improve the build system, but that's a
> longer-term goal.
>
> On the topic at hand: I agree with Jason. Non-developers should be using
> the stable master branch, which is unaffected. They'll need to do a clean
> build per release, but i don't think that's a huge ask.
>
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Aug 26, 2020 at 9:56 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> It's a good idea to send an email to gem5-users. However, with our new
> release model, it should affect many fewer people. It's probably not true
> today, but the vision is that the only people who will care if develop
> breaks something are people subscribed to gem5-dev :).
>
> Cheers,
> Jason
>
> On Wed, Aug 26, 2020 at 12:32 AM Nikos Nikoleris via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Do we also need to notify users about this? It might be worth sending an
> email about this. In fact an email with a different subject to both
> gem5-users and gem5-dev as people might ignore emails for a specific CL.
>
> Nikos
>
> On 25/08/2020 23:17, Daniel Carvalho via gem5-dev wrote:
> > Was about to send an e-mail with a heads up, but I guess I was too late.
> >
> > As reported here
> > (
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-753),
> > itis not an issue caused by this patch itself. SCons does not trigger
> > recompilation when a change modifies the cxx_class; therefore,
> > params/BaseCache.hh is not recompiled and generates the error. To solve
> > this, one must manually delete this file and force a recompilation.
> >
> > Regards,
> > Daniel
> >
> > Em terça-feira, 25 de agosto de 2020 21:20:56 GMT+2, mike upton via
> > gem5-dev  escreveu:
> >
> >
> > This checkin breaks the build.
> >
> > you can check at:
> > http://jenkins.gem5.org:8080/job/gem5_develop/136/
> >
> >
> >
> > On Tue, Aug 25, 2020 at 8:13 AM Daniel Carvalho (Gerrit) via gem5-dev
> > mailto:gem5-dev@gem5.org>> wrote:
> >
> > Daniel Carvalho *submitted* this change.
> >
> > View Change <
> https://gem5-review.googlesource.com/c/public/gem5/+/33294>
> >
> > Approvals: Nikos Nikoleris: Looks good to me, approved; Looks good
> > to me, approved kokoro: Regressions pass
> >
> > mem-cache: Create Compressor namespace
> >
> > Creation of the Compressor namespace. It encapsulates all the cache
> > compressors, and other classes used by them.
> >
> > The following classes have been renamed:
> > BaseCacheCompressor -> Base
> > PerfectCompressor - Perfect
> > RepeatedQwordsCompressor -> RepeatedQwords
> > ZeroCompressor -> Zero
> >
> > BaseDictionaryCompressor and DictionaryCompressor were not renamed
> > because the there is a high probability that users may want to
> > create a Dictionary class that encompasses the dictionary contained
> > by these compressors.
> >
> > To apply this patch one must force recompilation (e.g., by deleting
> > it) of build//params/BaseCache.hh (a

[gem5-dev] Re: Change in gem5/gem5[develop]: mem-cache: Create Compressor namespace

[mike upton via gem5-dev]

This checkin breaks the build.

you can check at:
http://jenkins.gem5.org:8080/job/gem5_develop/136/



On Tue, Aug 25, 2020 at 8:13 AM Daniel Carvalho (Gerrit) via gem5-dev <
gem5-dev@gem5.org> wrote:

> Daniel Carvalho *submitted* this change.
>
> View Change 
> Approvals: Nikos Nikoleris: Looks good to me, approved; Looks good to me,
> approved kokoro: Regressions pass
>
> mem-cache: Create Compressor namespace
>
> Creation of the Compressor namespace. It encapsulates all the cache
> compressors, and other classes used by them.
>
> The following classes have been renamed:
> BaseCacheCompressor -> Base
> PerfectCompressor - Perfect
> RepeatedQwordsCompressor -> RepeatedQwords
> ZeroCompressor -> Zero
>
> BaseDictionaryCompressor and DictionaryCompressor were not renamed
> because the there is a high probability that users may want to
> create a Dictionary class that encompasses the dictionary contained
> by these compressors.
>
> To apply this patch one must force recompilation (e.g., by deleting
> it) of build//params/BaseCache.hh (and any other files that
> were previously using these compressors).
>
> Change-Id: I78cb3b6fb8e3e50a52a04268e0e08dd664d81230
> Signed-off-by: Daniel R. Carvalho 
> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33294
> Reviewed-by: Nikos Nikoleris 
> Maintainer: Nikos Nikoleris 
> Tested-by: kokoro 
> ---
> M src/mem/cache/base.hh
> M src/mem/cache/compressors/Compressors.py
> M src/mem/cache/compressors/base.cc
> M src/mem/cache/compressors/base.hh
> M src/mem/cache/compressors/base_delta.cc
> M src/mem/cache/compressors/base_delta.hh
> M src/mem/cache/compressors/base_delta_impl.hh
> M src/mem/cache/compressors/base_dictionary_compressor.cc
> M src/mem/cache/compressors/cpack.cc
> M src/mem/cache/compressors/cpack.hh
> M src/mem/cache/compressors/dictionary_compressor.hh
> M src/mem/cache/compressors/dictionary_compressor_impl.hh
> M src/mem/cache/compressors/fpcd.cc
> M src/mem/cache/compressors/fpcd.hh
> M src/mem/cache/compressors/multi.cc
> M src/mem/cache/compressors/multi.hh
> M src/mem/cache/compressors/perfect.cc
> M src/mem/cache/compressors/perfect.hh
> M src/mem/cache/compressors/repeated_qwords.cc
> M src/mem/cache/compressors/repeated_qwords.hh
> M src/mem/cache/compressors/zero.cc
> M src/mem/cache/compressors/zero.hh
> 22 files changed, 231 insertions(+), 165 deletions(-)
>
> diff --git a/src/mem/cache/base.hh b/src/mem/cache/base.hh
> index 3efc7c7..d30de3f 100644
> --- a/src/mem/cache/base.hh
> +++ b/src/mem/cache/base.hh
> @@ -320,7 +320,7 @@
>  BaseTags *tags;
>
>  /** Compression method being used. */
> -BaseCacheCompressor* compressor;
> +Compressor::Base* compressor;
>
>  /** Prefetcher */
>  Prefetcher::Base *prefetcher;
> diff --git a/src/mem/cache/compressors/Compressors.py 
> b/src/mem/cache/compressors/Compressors.py
> index eb1952a..46050f6 100644
> --- a/src/mem/cache/compressors/Compressors.py
> +++ b/src/mem/cache/compressors/Compressors.py
> @@ -1,4 +1,4 @@
> -# Copyright (c) 2018 Inria
> +# Copyright (c) 2018-2020 Inria
>  # All rights reserved.
>  #
>  # Redistribution and use in source and binary forms, with or without
> @@ -31,6 +31,7 @@
>  class BaseCacheCompressor(SimObject):
>  type = 'BaseCacheCompressor'
>  abstract = True
> +cxx_class = 'Compressor::Base'
>  cxx_header = "mem/cache/compressors/base.hh"
>
>  block_size = Param.Int(Parent.cache_line_size, "Block size in bytes")
> @@ -41,6 +42,7 @@
>  class BaseDictionaryCompressor(BaseCacheCompressor):
>  type = 'BaseDictionaryCompressor'
>  abstract = True
> +cxx_class = 'Compressor::BaseDictionaryCompressor'
>  cxx_header = "mem/cache/compressors/dictionary_compressor.hh"
>
>  dictionary_size = Param.Int(Parent.cache_line_size,
> @@ -48,49 +50,49 @@
>
>  class Base64Delta8(BaseDictionaryCompressor):
>  type = 'Base64Delta8'
> -cxx_class = 'Base64Delta8'
> +cxx_class = 'Compressor::Base64Delta8'
>  cxx_header = "mem/cache/compressors/base_delta.hh"
>
>  class Base64Delta16(BaseDictionaryCompressor):
>  type = 'Base64Delta16'
> -cxx_class = 'Base64Delta16'
> +cxx_class = 'Compressor::Base64Delta16'
>  cxx_header = "mem/cache/compressors/base_delta.hh"
>
>  class Base64Delta32(BaseDictionaryCompressor):
>  type = 'Base64Delta32'
> -cxx_class = 'Base64Delta32'
> +cxx_class = 'Compressor::Base64Delta32'
>  cxx_header = "mem/cache/compressors/base_delta.hh"
>
>  class Base32Delta8(BaseDictionaryCompressor):
>  type = 'Base32Delta8'
> -cxx_class = 'Base32Delta8'
> +cxx_class = 'Compressor::Base32Delta8'
>  cxx_header = "mem/cache/compressors/base_delta.hh"
>
>  class Base32Delta16(BaseDictionaryCompressor):
>  type = 'Base32Delta16'
> -cxx_class = 'Base32Delta16'
> +cxx_class = 'Compressor::Base32Delta16'
>  cxx_header = "mem/cache/compressors/base_delta.hh"
>
>  class 

[gem5-dev] testlib question

[mike upton via gem5-dev]

My Jenkins setup is getting errors in testlib.


The test is failing, and trying to call test.fail

from the results.pickle file:


File "/var/lib/jenkins/workspace/stress/tests/../ext/testlib/runner.py",
line 146, in test
test_params.test.test(test_params)
  File "/var/lib/jenkins/workspace/stress/tests/../ext/testlib/wrappers.py",
line 147, in test
self.obj.test(*args, **kwargs)
  File "/var/lib/jenkins/workspace/stress/tests/../ext/testlib/test_util.py",
line 69, in test
self.test_function(*args, **kwargs)
  File "/var/lib/jenkins/workspace/stress/tests/gem5/verifier.py",
line 43, in _test
self.test(*args, **kwargs)
  File "/var/lib/jenkins/workspace/stress/tests/gem5/verifier.py",
line 83, in test
test.fail('Stdout did not match:\n%s\nSee %s for full results'
AttributeError: module 'testlib.test_util' has no attribute 'fail'


Any ideas about how to fix? I am not familiar with testlib.

I would like to see the error message it is trying to print.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [gem5-dev] windows fs boot and simulation

[mike upton via gem5-dev]

hanism called chain loading where it
> > basically
> > > gets windows ready and then jumps to it as if grub hadn't run at all.
> > > Windows is non the wiser and starts running like normal.
> > >
> > > If you wanted to boot windows like we boot Linux, you'd need to get at
> > the
> > > part of windows that their boot strap process actually sets up, figure
> > out
> > > what work it does, and then get gem5 to do it. My assumption is that
> > that's
> > > basically impossible unless you work at Microsoft, and even then is
> > > probably quite difficult.
> > >
> > > Another option would be to make gem5 boot more like a real system.
> You'd
> > > need some firmware to act as the BIOS (or at least fake it within gem5
> > > itself), and you'd probably want to load windows off of the actual disk
> > (or
> > > let the firmware do it) and start it using the standard PC boot
> > mechanism.
> > > Writing a real BIOS for a real computer is very, very, very, very
> > > complicated, but writing a BIOS for a fake computer is significantly
> > > easier. If you want a reference, you can look at the BIOS
> implementation
> > > QEMU uses. There are also differences between a traditional BIOS
> > > implementation like you'd have found in older PCs, and EFI which you'd
> > find
> > > on newer systems. EFI is probably a lot harder to fake since it's a lot
> > > bigger and more complex, so if you can get away with looking like a
> > regular
> > > BIOS you're life might be a lot easier. More recent versions of windows
> > may
> > > require EFI, or they may just require it to put a sticker on the case
> > that
> > > says windows. You're mileage may vary.
> > >
> > > All in all, I think it might be a significant challenge to get windows
> > > running under gem5. You could probably do it, but beyond the difficult
> of
> > > getting it started, realistically you're also likely to run into bugs
> in
> > > gem5 itself. If you do, it might be really hard to debug them since you
> > > don't know what windows is trying to do since you can't (I assume) look
> > at
> > > its source. It would be really neat if you get it to work, but I
> wouldn't
> > > want you to jump into this without warning you what you were taking on.
> > >
> > > Good luck!
> > >
> > > Gabe
> > >
> > > On Wed, Jan 28, 2015 at 10:26 PM, mike upton via gem5-dev <
> > > gem5-dev@gem5.org
> > > > wrote:
> > >
> > > > I was going down 2 parallel paths.
> > > >
> > > > SE (win on win), and FS (on whatever works).
> > > > I have pretty much given up on the SE windows mode.
> > > > For now at least.
> > > >
> > > > I may revisit once cygwin/mingw support C11.
> > > > Even then, there are a lot of linux-isms built into the simulator.
> > > >
> > > >
> > > >
> > > > On Wed, Jan 28, 2015 at 10:14 PM, nathan binkert via gem5-dev <
> > > > gem5-dev@gem5.org> wrote:
> > > >
> > > > > I have a question.  If you're trying to simulate a windows guest
> on a
> > > > linux
> > > > > host.  What are you doing with cygwin?
> > > > >
> > > > > On Wed, Jan 28, 2015 at 8:05 PM, mike upton via gem5-dev <
> > > > > gem5-dev@gem5.org>
> > > > > wrote:
> > > > >
> > > > > > I would like to get started on trying to simulate a windows x86
> > > machine
> > > > > (on
> > > > > > top of a linux host).
> > > > > > I am not too picky about type at this point, XP, win7 or win8.1
> > would
> > > > all
> > > > > > be acceptable.
> > > > > >
> > > > > > I spent quite a while trying to get gem5 compiled under cygwin,
> but
> > > it
> > > > is
> > > > > > currently broken because of a lack of C11 support in the gcc
> stack
> > on
> > > > > > windows.
> > > > > >
> > > > > > I don’t really know how to get started.
> > > > > >
> > > > > > My understanding is that windows requires a USB device to be
> > present.
> > > > > > So it seem like the first step is to get that going.
> > > > > >
> > > > > > Any pointers on how to proceed?
> > > > > > Is there any kind of OS bringup documentation. I searched and did
> > not
> > > > > find
> > > > > > anything.
> > > > > >
> > > > > >
> > > > > > I was able to bring up win8.1 on qemu+kvm without much
> difficulty,
> > > so I
> > > > > am
> > > > > > hopeful.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Mike
> > > > > > ___
> > > > > > 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
> > > >
> > > ___
> > > 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
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] windows fs boot and simulation

[mike upton via gem5-dev]

I was going down 2 parallel paths.

SE (win on win), and FS (on whatever works).
I have pretty much given up on the SE windows mode.
For now at least.

I may revisit once cygwin/mingw support C11.
Even then, there are a lot of linux-isms built into the simulator.



On Wed, Jan 28, 2015 at 10:14 PM, nathan binkert via gem5-dev <
gem5-dev@gem5.org> wrote:

> I have a question.  If you're trying to simulate a windows guest on a linux
> host.  What are you doing with cygwin?
>
> On Wed, Jan 28, 2015 at 8:05 PM, mike upton via gem5-dev <
> gem5-dev@gem5.org>
> wrote:
>
> > I would like to get started on trying to simulate a windows x86 machine
> (on
> > top of a linux host).
> > I am not too picky about type at this point, XP, win7 or win8.1 would all
> > be acceptable.
> >
> > I spent quite a while trying to get gem5 compiled under cygwin, but it is
> > currently broken because of a lack of C11 support in the gcc stack on
> > windows.
> >
> > I don’t really know how to get started.
> >
> > My understanding is that windows requires a USB device to be present.
> > So it seem like the first step is to get that going.
> >
> > Any pointers on how to proceed?
> > Is there any kind of OS bringup documentation. I searched and did not
> find
> > anything.
> >
> >
> > I was able to bring up win8.1 on qemu+kvm without much difficulty, so I
> am
> > hopeful.
> >
> > Thanks,
> >
> > Mike
> > ___
> > 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

[gem5-dev] windows fs boot and simulation

[mike upton via gem5-dev]

I would like to get started on trying to simulate a windows x86 machine (on
top of a linux host).
I am not too picky about type at this point, XP, win7 or win8.1 would all
be acceptable.

I spent quite a while trying to get gem5 compiled under cygwin, but it is
currently broken because of a lack of C11 support in the gcc stack on
windows.

I don’t really know how to get started.

My understanding is that windows requires a USB device to be present.
So it seem like the first step is to get that going.

Any pointers on how to proceed?
Is there any kind of OS bringup documentation. I searched and did not find
anything.


I was able to bring up win8.1 on qemu+kvm without much difficulty, so I am
hopeful.

Thanks,

Mike
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2613: x86: kvm: fix the KVM CPU in SE and FS on both Intel and AMD host CPUs

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2613/
---

(Updated Jan. 23, 2015, 4:53 p.m.)


Review request for Default.


Summary (updated)
-

x86: kvm: fix the KVM CPU in SE and FS on both Intel and AMD host CPUs


Repository: gem5


Description
---

# Node ID aa3eb7453246b9489092bf6dbbc924ae435de0fc
# Parent  8fc6e7a835d1d313e139c9095251105f904ac1b4

imported patch kvm_processor_check


Added additional Host CPU type check on x86 platforms to do platform dependent 
code for sysenter/syscall.

This restores functionality for AMD platforms with rb2557.


Diffs
-

  src/arch/x86/process.cc 04923a93f2b5 
  src/arch/x86/regs/misc.hh 04923a93f2b5 
  src/arch/x86/system.hh 04923a93f2b5 
  src/arch/x86/system.cc 04923a93f2b5 
  src/arch/x86/utility.hh 04923a93f2b5 
  src/arch/x86/utility.cc 04923a93f2b5 
  src/cpu/kvm/x86_cpu.cc 04923a93f2b5 

Diff: http://reviews.gem5.org/r/2613/diff/


Testing
---

selection of specint tests on AMD and Intel KVM platforms


Thanks,

mike upton

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 2613: # Node ID aa3eb7453246b9489092bf6dbbc924ae435de0fc

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2613/
---

Review request for Default.


Repository: gem5


Description
---

# Node ID aa3eb7453246b9489092bf6dbbc924ae435de0fc
# Parent  8fc6e7a835d1d313e139c9095251105f904ac1b4

imported patch kvm_processor_check


Added additional Host CPU type check on x86 platforms to do platform dependent 
code for sysenter/syscall.

This restores functionality for AMD platforms with rb2557.


Diffs
-

  src/arch/x86/process.cc 04923a93f2b5 
  src/arch/x86/regs/misc.hh 04923a93f2b5 
  src/arch/x86/system.hh 04923a93f2b5 
  src/arch/x86/system.cc 04923a93f2b5 
  src/arch/x86/utility.hh 04923a93f2b5 
  src/arch/x86/utility.cc 04923a93f2b5 
  src/cpu/kvm/x86_cpu.cc 04923a93f2b5 

Diff: http://reviews.gem5.org/r/2613/diff/


Testing
---

selection of specint tests on AMD and Intel KVM platforms


Thanks,

mike upton

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

OK,

I believe I have a patch that unifies the code for both AMD and Intel.

Do I post it as a separate review-board item?

On Thu, Jan 22, 2015 at 11:32 AM, mike upton  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
>
> On January 21st, 2015, 9:22 p.m. UTC, *mike upton* wrote:
>
>   src/arch/x86/process.cc
>  (Diff
> revision 2)
>
> X86_64LiveProcess::initState()
>
>   217
>
> SegDescriptor csLowPLDesc = initDesc;
>
>   218
>
> csLowPLDesc.type.codeOrData = 1;
>
>   219
>
> csLowPLDesc.dpl = 0;
>
>   220
>
> uint64_t csLowPLDescVal = csLowPLDesc;
>
>   221
>
> physProxy.writeBlob(GDTPhysAddr + numGDTEntries * 8,
>
>   222
>
> (uint8_t *)(&csLowPLDescVal), 8);
>
>   223
>
>   224
>
> numGDTEntries++;
>
>   225
>
>   226
>
> SegSelector csLowPL = 0;
>
>   227
>
> csLowPL.si = numGDTEntries - 1;
>
>   228
>
> csLowPL.rpl = 0;
>
>   229
>
>   230
>
> //64 bit data segment
>
>   231
>
> SegDescriptor dsLowPLDesc = initDesc;
>
>   232
>
> dsLowPLDesc.type.codeOrData = 0;
>
>   233
>
> dsLowPLDesc.dpl = 0;
>
>   234
>
> uint64_t dsLowPLDescVal = dsLowPLDesc;
>
>   235
>
> physProxy.writeBlob(GDTPhysAddr + numGDTEntries * 8,
>
>   236
>
> (uint8_t *)(&dsLowPLDescVal), 8);
>
>For AMD systems, the sys descriptors need to come first. On intel systems 
> they need to come second.
>
> I do not know how to resolve...
>
>  On January 21st, 2015, 9:23 p.m. UTC, *mike upton* wrote:
>
> I have been debugging why patch rb2557 breaks AMD KVM functionality.
>
>
>
>
> I was hoping to get to code that would work on both intel and AMD platforms, 
> but am not there yet.
>
>
>
>
> This patch is to be applied on top of rb2557.patch.
>
>
>
>
> There are 2 main issues, neither of which I understand well enough to take 
> much further.
>
>
>
>
> The first issue is that the order that the segment descriptors get 
> instantiated in the GDT table seems to matter between AMD and Intel, and they 
> seem to be mutually incompatible.
>
>
>
>
> AMD wants:
>
> csSys
>
> dsSys
>
> ds
>
> cs
>
>
>
>
> Intel wants:
>
> ds
>
> cs
>
> dsSys
>
> csSys
>
>
>
>
> I am not sure the relative ordering of ds and cs within a class matters, only 
> that AMD wants the Sys ones first, and Intel wants them second.
>
>
>
>
> There is also an issue with how 'star' gets defined.
>
> I can not make the Intel code work for AMD.
>
>
>
>
> Both issues are addressed in this patch.
>
>
>
>
> The patch makes the AMD system work, but breaks Intel functionality.
>
>
>
>
> I am also not sure how to upload this into review board. Do I create a 
> separate patch from TOT, or can I somehow attach this to rb2557.
>
>
>
>
> Hopefully Gabe or Alexandru can weigh in. I am happy to help, but I am at my 
> 'Peter Principal Limit' as far as my understanding goes.
>
>
>
>
> I think it would be really ugly to have a machine-type test to version the 
> code...
>
>  On January 21st, 2015, 9:48 p.m. UTC, *Gabe Black* wrote:
>
> You should grab a copy of the architecture manual. From there:
>
>
> STAR—The STAR register has the following fields (unless otherwise noted, all 
> bits are
> read/write):
> - SYSRET CS and SS Selectors—Bits 63:48. This field is used to specify both 
> the CS and SS
> selectors loaded into CS and SS during SYSRET. If SYSRET is returning to 
> 32-bit mode
> (either legacy or compatibility), this field is copied directly into the CS 
> selector field. If
> SYSRET is returning to 64-bit mode, the CS selector is set to this field + 
> 16. SS.Sel is set to
> this field + 8, regardless of the target mode. Because SYSRET always returns 
> to CPL 3, the
> RPL bits 49:48 should be initialized to 11b.
> - SYSCALL CS and SS Selectors—Bits 47:32. This field is used to specify both 
> the CS and SS
> selectors loaded into CS and SS during SYSCALL. This field is copied directly 
> into CS.Sel.
> SS.Sel is set to this field + 8. Because SYSCALL always switches to CPL 0, 
> the RPL bits
> 33:32 should be initialized to 00b.
>
>
> That's why the order matters and is what it is.
>
>  On January 21st, 2015, 11:15 p.m. UTC, *mike upton* wrote:
>
> AMD and Intel use different solutions, right?
>
> AMD: Syscall, sysret
> Intel: Sysenter, sysexit
>
> Do we need independent code streams for each?
>
> The original code worked for AMD, but not intel.
> The current 2557 patch works for Intel, but not AMD.
>
>  On January 21st, 2015, 11:35 p.m. UTC, *Gabe Black* wrote:
>
> Yeah, there are some differences between the two. I think both support both 
> pairs of instructions, but I think one or the other only works in 32 bit mode 
> on for one of the vendors, or something along those lines. At one point I 
> could have told you exactly what the difference was, but now I'd have to 
> check t

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

> On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
> > src/arch/x86/process.cc, lines 218-237
> > 
> >
> > For AMD systems, the sys descriptors need to come first. On intel 
> > systems they need to come second.
> > 
> > I do not know how to resolve...
> 
> mike upton wrote:
> I have been debugging why patch rb2557 breaks AMD KVM functionality.
> 
> 
> 
> 
> I was hoping to get to code that would work on both intel and AMD 
> platforms, but am not there yet.
> 
> 
> 
> 
> This patch is to be applied on top of rb2557.patch.
> 
> 
> 
> 
> There are 2 main issues, neither of which I understand well enough to 
> take much further.
> 
> 
> 
> 
> The first issue is that the order that the segment descriptors get 
> instantiated in the GDT table seems to matter between AMD and Intel, and they 
> seem to be mutually incompatible.
> 
> 
> 
> 
> AMD wants:
> 
> csSys
> 
> dsSys
> 
> ds
> 
> cs
> 
> 
> 
> 
> Intel wants:
> 
> ds
> 
> cs
> 
> dsSys
> 
> csSys
> 
> 
> 
> 
> I am not sure the relative ordering of ds and cs within a class matters, 
> only that AMD wants the Sys ones first, and Intel wants them second.
> 
> 
> 
> 
> There is also an issue with how 'star' gets defined.
> 
> I can not make the Intel code work for AMD.
> 
> 
> 
> 
> Both issues are addressed in this patch.
> 
> 
> 
> 
> The patch makes the AMD system work, but breaks Intel functionality.
> 
> 
> 
> 
> I am also not sure how to upload this into review board. Do I create a 
> separate patch from TOT, or can I somehow attach this to rb2557.
> 
> 
> 
> 
> Hopefully Gabe or Alexandru can weigh in. I am happy to help, but I am at 
> my 'Peter Principal Limit' as far as my understanding goes.
> 
> 
> 
> 
> I think it would be really ugly to have a machine-type test to version 
> the code...
> 
> Gabe Black wrote:
> You should grab a copy of the architecture manual. From there:
> 
> 
> STAR—The STAR register has the following fields (unless otherwise noted, 
> all bits are
> read/write):
> - SYSRET CS and SS Selectors—Bits 63:48. This field is used to specify 
> both the CS and SS
> selectors loaded into CS and SS during SYSRET. If SYSRET is returning to 
> 32-bit mode
> (either legacy or compatibility), this field is copied directly into the 
> CS selector field. If
> SYSRET is returning to 64-bit mode, the CS selector is set to this field 
> + 16. SS.Sel is set to
> this field + 8, regardless of the target mode. Because SYSRET always 
> returns to CPL 3, the
> RPL bits 49:48 should be initialized to 11b.
> - SYSCALL CS and SS Selectors—Bits 47:32. This field is used to specify 
> both the CS and SS
> selectors loaded into CS and SS during SYSCALL. This field is copied 
> directly into CS.Sel.
> SS.Sel is set to this field + 8. Because SYSCALL always switches to CPL 
> 0, the RPL bits
> 33:32 should be initialized to 00b.
> 
> 
> That's why the order matters and is what it is.
> 
> mike upton wrote:
> AMD and Intel use different solutions, right?
> 
> AMD: Syscall, sysret
> Intel: Sysenter, sysexit
> 
> Do we need independent code streams for each?
> 
> The original code worked for AMD, but not intel.
> The current 2557 patch works for Intel, but not AMD.
> 
> Gabe Black wrote:
> Yeah, there are some differences between the two. I think both support 
> both pairs of instructions, but I think one or the other only works in 32 bit 
> mode on for one of the vendors, or something along those lines. At one point 
> I could have told you exactly what the difference was, but now I'd have to 
> check the manuals. My expectation/hope is that a single GDT layout would work 
> for both. I doubt the kernel, for instance, specializes its layout based on 
> who's CPU it's running on.

OK, it seems like the feedback is that we do need to runtime test the CPU we 
are running on and do CPU specific code.
I certainly can code this up.

Any pointers to what state is available in the simulator to test?
Or should I just add a cpuHostType() routine that will return Intel, AMD, or 
UNKNOWN?


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5782
---


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> 

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

> On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
> > src/arch/x86/process.cc, lines 218-237
> > 
> >
> > For AMD systems, the sys descriptors need to come first. On intel 
> > systems they need to come second.
> > 
> > I do not know how to resolve...
> 
> mike upton wrote:
> I have been debugging why patch rb2557 breaks AMD KVM functionality.
> 
> 
> 
> 
> I was hoping to get to code that would work on both intel and AMD 
> platforms, but am not there yet.
> 
> 
> 
> 
> This patch is to be applied on top of rb2557.patch.
> 
> 
> 
> 
> There are 2 main issues, neither of which I understand well enough to 
> take much further.
> 
> 
> 
> 
> The first issue is that the order that the segment descriptors get 
> instantiated in the GDT table seems to matter between AMD and Intel, and they 
> seem to be mutually incompatible.
> 
> 
> 
> 
> AMD wants:
> 
> csSys
> 
> dsSys
> 
> ds
> 
> cs
> 
> 
> 
> 
> Intel wants:
> 
> ds
> 
> cs
> 
> dsSys
> 
> csSys
> 
> 
> 
> 
> I am not sure the relative ordering of ds and cs within a class matters, 
> only that AMD wants the Sys ones first, and Intel wants them second.
> 
> 
> 
> 
> There is also an issue with how 'star' gets defined.
> 
> I can not make the Intel code work for AMD.
> 
> 
> 
> 
> Both issues are addressed in this patch.
> 
> 
> 
> 
> The patch makes the AMD system work, but breaks Intel functionality.
> 
> 
> 
> 
> I am also not sure how to upload this into review board. Do I create a 
> separate patch from TOT, or can I somehow attach this to rb2557.
> 
> 
> 
> 
> Hopefully Gabe or Alexandru can weigh in. I am happy to help, but I am at 
> my 'Peter Principal Limit' as far as my understanding goes.
> 
> 
> 
> 
> I think it would be really ugly to have a machine-type test to version 
> the code...
> 
> Gabe Black wrote:
> You should grab a copy of the architecture manual. From there:
> 
> 
> STAR—The STAR register has the following fields (unless otherwise noted, 
> all bits are
> read/write):
> - SYSRET CS and SS Selectors—Bits 63:48. This field is used to specify 
> both the CS and SS
> selectors loaded into CS and SS during SYSRET. If SYSRET is returning to 
> 32-bit mode
> (either legacy or compatibility), this field is copied directly into the 
> CS selector field. If
> SYSRET is returning to 64-bit mode, the CS selector is set to this field 
> + 16. SS.Sel is set to
> this field + 8, regardless of the target mode. Because SYSRET always 
> returns to CPL 3, the
> RPL bits 49:48 should be initialized to 11b.
> - SYSCALL CS and SS Selectors—Bits 47:32. This field is used to specify 
> both the CS and SS
> selectors loaded into CS and SS during SYSCALL. This field is copied 
> directly into CS.Sel.
> SS.Sel is set to this field + 8. Because SYSCALL always switches to CPL 
> 0, the RPL bits
> 33:32 should be initialized to 00b.
> 
> 
> That's why the order matters and is what it is.

AMD and Intel use different solutions, right?

AMD: Syscall, sysret
Intel: Sysenter, sysexit

Do we need independent code streams for each?

The original code worked for AMD, but not intel.
The current 2557 patch works for Intel, but not AMD.


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5782
---


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e13

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

> On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
> > src/arch/x86/process.cc, lines 218-237
> > 
> >
> > For AMD systems, the sys descriptors need to come first. On intel 
> > systems they need to come second.
> > 
> > I do not know how to resolve...

I have been debugging why patch rb2557 breaks AMD KVM functionality.


I was hoping to get to code that would work on both intel and AMD platforms, 
but am not there yet.


This patch is to be applied on top of rb2557.patch.


There are 2 main issues, neither of which I understand well enough to take much 
further.


The first issue is that the order that the segment descriptors get instantiated 
in the GDT table seems to matter between AMD and Intel, and they seem to be 
mutually incompatible.


AMD wants:

csSys

dsSys

ds

cs


Intel wants:

ds

cs

dsSys

csSys


I am not sure the relative ordering of ds and cs within a class matters, only 
that AMD wants the Sys ones first, and Intel wants them second.


There is also an issue with how 'star' gets defined.

I can not make the Intel code work for AMD.


Both issues are addressed in this patch.


The patch makes the AMD system work, but breaks Intel functionality.


I am also not sure how to upload this into review board. Do I create a separate 
patch from TOT, or can I somehow attach this to rb2557.


Hopefully Gabe or Alexandru can weigh in. I am happy to help, but I am at my 
'Peter Principal Limit' as far as my understanding goes.


I think it would be really ugly to have a machine-type test to version the 
code...


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5782
---


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/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 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5782
---



src/arch/x86/process.cc


For AMD systems, the sys descriptors need to come first. On intel systems 
they need to come second.

I do not know how to resolve...



src/arch/x86/process.cc


The AMD version only works with the original definition for star...

I could not get the new code to work.


- mike upton


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] AMD KVM SE functionality

[mike upton via gem5-dev]

I have been debugging why patch rb2557 breaks AMD KVM functionality.

I was hoping to get to code that would work on both intel and AMD
platforms, but am not there yet.

This patch is to be applied on top of rb2557.patch.

There are 2 main issues, neither of which I understand well enough to take
much further.

The first issue is that the order that the segment descriptors get
instantiated in the GDT table seems to matter between AMD and Intel, and
they seem to be mutually incompatible.

AMD wants:
csSys
dsSys
ds
cs

Intel wants:
ds
cs
dsSys
csSys

I am not sure the relative ordering of ds and cs within a class matters,
only that AMD wants the Sys ones first, and Intel wants them second.

There is also an issue with how 'star' gets defined.
I can not make the Intel code work for AMD.

Both issues are addressed in this patch.

The patch makes the AMD system work, but breaks Intel functionality.

I am also not sure how to upload this into review board. Do I create a
separate patch from TOT, or can I somehow attach this to rb2557.

Hopefully Gabe or Alexandru can weigh in. I am happy to help, but I am at
my 'Peter Principal Limit' as far as my understanding goes.

I think it would be really ugly to have a machine-type test to version the
code...
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

I am making some progress on debugging this.
I hope to have it tomorrow.



On Sun, Jan 11, 2015 at 12:48 AM, Alexandru Dutu 
wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
>
> On December 10th, 2014, 10:30 p.m. UTC, *mike upton* wrote:
>
> There is some issue with AMD platforms. A test that used to run in 30 sec is 
> not finishing.
>
>
>  On December 10th, 2014, 10:32 p.m. UTC, *mike upton* wrote:
>
> hello world passes. SPEC apps hang.
>
>  On December 10th, 2014, 10:41 p.m. UTC, *Gabe Black* wrote:
>
> Can you identify where it's getting stuck? It could be there's something 
> wrong with how exception handling is set up, and it gets stuck faulting over 
> and over when a page fault happens, for instance. You could have the KVM CPU 
> print what the IP is each time it regains control and see if they cluster 
> somewhere interesting.
>
>  On December 11th, 2014, 8:12 a.m. UTC, *Gabe Black* wrote:
>
> Any luck? Unfortunately the time I have to work on gem5 is pretty limited, so 
> I probably won't be able to dig into this for a while.
>
>  On January 5th, 2015, 11:12 p.m. UTC, *mike upton* wrote:
>
> on the intel platform, with the test input set, all of cpu2006 integer tests 
> pass, except for astar.
> astar dies with a panic and page fault.
> [m5PageFault:build/X86/arch/x86/pseudo_inst.cc, line 85]
>
> on the amd platform, all of the tests I tried fail to complete.
> time continues to advance, but instructions are not completing.
>
> I am not sure what to do, I need the Intel platform code, but we should not 
> break the AMD side.
>
> Are there any AMD folks I can work with to figure out how to get both sides 
> working?
>
>
>  On January 6th, 2015, 6:39 p.m. UTC, *Alexandru Dutu* wrote:
>
> Sorry about the late reply, I remember replying on a different mailing list 
> thread about this. I have tried this patch on my AMD system with some short 
> running applications and things worked fine. So, I will run cpu2006 and see 
> if there are any issues.
>
>  When running SPEC CPU2006 with latest gem5 on a 6 core Bulldozer, Ubuntu 
> 14.04, linux 3.13.0-34, most of them call exit_group syscall except gromacs 
> which fails because of unimplemented clock_gettime syscall. This means they 
> ran until completion, however I have not yet checked if the output is 
> actually correct.
>
> However, after applying this patch things break and there are unexpected 
> exits in the middle of the execution. Looking more into it and coming up with 
> more details.
>
>
> - Alexandru
>
> On December 10th, 2014, 10:11 a.m. UTC, Gabe Black wrote:
>   Review request for Default.
> By Gabe Black.
>
> *Updated Dec. 10, 2014, 10:11 a.m.*
>  *Repository: * gem5
> Description
>
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
>
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
>
>   Diffs
>
>- src/arch/x86/process.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/regs/misc.hh (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/system.hh (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/system.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/utility.hh (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/utility.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/cpu/kvm/x86_cpu.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>
> View Diff 
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5773
---



src/arch/x86/process.cc


when limitHigh and limitLow get set by dataSegDesc(), it seems that 
limitHigh and limitLow get reversed.



- mike upton


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/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 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5772
---



src/arch/x86/utility.hh


Is there a reason the desc.l does not get set for the dataSegDesc()? code 
sets p,l,d,g,s.


- mike upton


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] X86 regression failures

[mike upton via gem5-dev]

I was trying to run a regression, I am still learning.

This is off of a clean build of the top of tree:
hg clone http://repo.gem5.org/gem5



I ran:

util/regress -j4 --builds X86


and I get a number of failures.

* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing passed

* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic passed

* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing passed

* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby
passed

* build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic
FAILED!

* build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing
FAILED!

The failures are both of the fs tests.

Am I doing something wrong?
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

it is:

hg qpush



On Fri, Jan 16, 2015 at 8:39 AM, Amit Gaikwad  wrote:

> Hello Mike,
>
> Thank you so much for taking out time to explain things. That was really
> helpful.
>
> But I have unsuccessful in getting KVM CPU working on my intel system.
> Since when I applied the patch , I get the below message :
>
> agaikwad@AV-LT265-Ubuntu:~/gem5$ hg push
> pushing to http://repo.gem5.org/gem5
> 
> searching for changes
> no changes found
>
> Can you please let me know if you got the same error message ? So may be I
> have the recent gem5 which includes this patch ?
>
>
>
>
>
> On Thu, Jan 15, 2015 at 4:53 PM, mike upton 
> wrote:
>
>> if you go here:
>>
>> http://reviews.gem5.org/r/2557/
>>
>> there is a 'Download Diff' button on the first active line of the review
>> (about 3 down from the 'Review board 1.7.9')
>>
>> You download it, and then apply it using the method I PMed you.
>>
>>
>> On Thu, Jan 15, 2015 at 4:36 PM, Amit Gaikwad  wrote:
>>
>>>This is an automatically generated e-mail. To reply, visit:
>>> http://reviews.gem5.org/r/2557/
>>>
>>> On December 10th, 2014, 10:30 p.m. UTC, *mike upton* wrote:
>>>
>>> There is some issue with AMD platforms. A test that used to run in 30 sec 
>>> is not finishing.
>>>
>>>
>>>  On December 10th, 2014, 10:32 p.m. UTC, *mike upton* wrote:
>>>
>>> hello world passes. SPEC apps hang.
>>>
>>>  On December 10th, 2014, 10:41 p.m. UTC, *Gabe Black* wrote:
>>>
>>> Can you identify where it's getting stuck? It could be there's something 
>>> wrong with how exception handling is set up, and it gets stuck faulting 
>>> over and over when a page fault happens, for instance. You could have the 
>>> KVM CPU print what the IP is each time it regains control and see if they 
>>> cluster somewhere interesting.
>>>
>>>  On December 11th, 2014, 8:12 a.m. UTC, *Gabe Black* wrote:
>>>
>>> Any luck? Unfortunately the time I have to work on gem5 is pretty limited, 
>>> so I probably won't be able to dig into this for a while.
>>>
>>>  On January 5th, 2015, 11:12 p.m. UTC, *mike upton* wrote:
>>>
>>> on the intel platform, with the test input set, all of cpu2006 integer 
>>> tests pass, except for astar.
>>> astar dies with a panic and page fault.
>>> [m5PageFault:build/X86/arch/x86/pseudo_inst.cc, line 85]
>>>
>>> on the amd platform, all of the tests I tried fail to complete.
>>> time continues to advance, but instructions are not completing.
>>>
>>> I am not sure what to do, I need the Intel platform code, but we should not 
>>> break the AMD side.
>>>
>>> Are there any AMD folks I can work with to figure out how to get both sides 
>>> working?
>>>
>>>
>>>  On January 6th, 2015, 6:39 p.m. UTC, *Alexandru Dutu* wrote:
>>>
>>> Sorry about the late reply, I remember replying on a different mailing list 
>>> thread about this. I have tried this patch on my AMD system with some short 
>>> running applications and things worked fine. So, I will run cpu2006 and see 
>>> if there are any issues.
>>>
>>>  On January 11th, 2015, 8:48 a.m. UTC, *Alexandru Dutu* wrote:
>>>
>>> When running SPEC CPU2006 with latest gem5 on a 6 core Bulldozer, Ubuntu 
>>> 14.04, linux 3.13.0-34, most of them call exit_group syscall except gromacs 
>>> which fails because of unimplemented clock_gettime syscall. This means they 
>>> ran until completion, however I have not yet checked if the output is 
>>> actually correct.
>>>
>>> However, after applying this patch things break and there are unexpected 
>>> exits in the middle of the execution. Looking more into it and coming up 
>>> with more details.
>>>
>>>  On January 15th, 2015, 5:27 p.m. UTC, *Amit Gaikwad* wrote:
>>>
>>> I am new to gem5. Can someone please let me know where can I find the 
>>> wip.patch and also what will be command for patching gem5 ?
>>>
>>>  On January 15th, 2015, 10:55 p.m. UTC, *mike upton* wrote:
>>>
>>> I am also having trouble running this patch on a different intel x86 system.
>>> It looks like there are both segmentation changes, and KVM changes merged 
>>> together.
>>>
>>> Can we split it into 2 separate patches?
>>>
>>> I think some of the style cleanup in the segmentation stuff changed the 
>>> behavior.
>>>
>>> If no one else does it, I will attempt a separate minimal patch that just 
>>> fixes the KVM stuff.
>>>
>>>  @ Mike Upton,
>>>
>>> I am not even able to find the patch and I am actively looking for it.
>>> Did you manually change the below 6 files ? Can you please let me know ?
>>>
>>> src/arch/x86/process.cc: 8 changes
>>> src/arch/x86/system.hh: 1 change
>>> src/arch/x86/system.cc: 3 changes
>>> src/arch/x86/utility.hh: 2 changes
>>> src/arch/x86/utility.cc: 1 change
>>> src/cpu/kvm/x86_cpu.cc: 2 changes
>>>
>>> The changes listed on this link : http://reviews.gem5.org/r/2557/diff/1-2/
>>>
>>>
>>>
>>> - Amit
>>>
>>> On December 10th, 2014, 10:11 a.m. 

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5769
---



src/arch/x86/regs/misc.hh


really <32, 0> in the new code?


- mike upton


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/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 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

if you go here:

http://reviews.gem5.org/r/2557/

there is a 'Download Diff' button on the first active line of the review
(about 3 down from the 'Review board 1.7.9')

You download it, and then apply it using the method I PMed you.


On Thu, Jan 15, 2015 at 4:36 PM, Amit Gaikwad  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
>
> On December 10th, 2014, 10:30 p.m. UTC, *mike upton* wrote:
>
> There is some issue with AMD platforms. A test that used to run in 30 sec is 
> not finishing.
>
>
>  On December 10th, 2014, 10:32 p.m. UTC, *mike upton* wrote:
>
> hello world passes. SPEC apps hang.
>
>  On December 10th, 2014, 10:41 p.m. UTC, *Gabe Black* wrote:
>
> Can you identify where it's getting stuck? It could be there's something 
> wrong with how exception handling is set up, and it gets stuck faulting over 
> and over when a page fault happens, for instance. You could have the KVM CPU 
> print what the IP is each time it regains control and see if they cluster 
> somewhere interesting.
>
>  On December 11th, 2014, 8:12 a.m. UTC, *Gabe Black* wrote:
>
> Any luck? Unfortunately the time I have to work on gem5 is pretty limited, so 
> I probably won't be able to dig into this for a while.
>
>  On January 5th, 2015, 11:12 p.m. UTC, *mike upton* wrote:
>
> on the intel platform, with the test input set, all of cpu2006 integer tests 
> pass, except for astar.
> astar dies with a panic and page fault.
> [m5PageFault:build/X86/arch/x86/pseudo_inst.cc, line 85]
>
> on the amd platform, all of the tests I tried fail to complete.
> time continues to advance, but instructions are not completing.
>
> I am not sure what to do, I need the Intel platform code, but we should not 
> break the AMD side.
>
> Are there any AMD folks I can work with to figure out how to get both sides 
> working?
>
>
>  On January 6th, 2015, 6:39 p.m. UTC, *Alexandru Dutu* wrote:
>
> Sorry about the late reply, I remember replying on a different mailing list 
> thread about this. I have tried this patch on my AMD system with some short 
> running applications and things worked fine. So, I will run cpu2006 and see 
> if there are any issues.
>
>  On January 11th, 2015, 8:48 a.m. UTC, *Alexandru Dutu* wrote:
>
> When running SPEC CPU2006 with latest gem5 on a 6 core Bulldozer, Ubuntu 
> 14.04, linux 3.13.0-34, most of them call exit_group syscall except gromacs 
> which fails because of unimplemented clock_gettime syscall. This means they 
> ran until completion, however I have not yet checked if the output is 
> actually correct.
>
> However, after applying this patch things break and there are unexpected 
> exits in the middle of the execution. Looking more into it and coming up with 
> more details.
>
>  On January 15th, 2015, 5:27 p.m. UTC, *Amit Gaikwad* wrote:
>
> I am new to gem5. Can someone please let me know where can I find the 
> wip.patch and also what will be command for patching gem5 ?
>
>  On January 15th, 2015, 10:55 p.m. UTC, *mike upton* wrote:
>
> I am also having trouble running this patch on a different intel x86 system.
> It looks like there are both segmentation changes, and KVM changes merged 
> together.
>
> Can we split it into 2 separate patches?
>
> I think some of the style cleanup in the segmentation stuff changed the 
> behavior.
>
> If no one else does it, I will attempt a separate minimal patch that just 
> fixes the KVM stuff.
>
>  @ Mike Upton,
>
> I am not even able to find the patch and I am actively looking for it.
> Did you manually change the below 6 files ? Can you please let me know ?
>
> src/arch/x86/process.cc: 8 changes
> src/arch/x86/system.hh: 1 change
> src/arch/x86/system.cc: 3 changes
> src/arch/x86/utility.hh: 2 changes
> src/arch/x86/utility.cc: 1 change
> src/cpu/kvm/x86_cpu.cc: 2 changes
>
> The changes listed on this link : http://reviews.gem5.org/r/2557/diff/1-2/
>
>
>
> - Amit
>
> On December 10th, 2014, 10:11 a.m. UTC, Gabe Black wrote:
>   Review request for Default.
> By Gabe Black.
>
> *Updated Dec. 10, 2014, 10:11 a.m.*
>  *Repository: * gem5
> Description
>
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
>
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
>
>   Diffs
>
>- src/arch/x86/process.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/regs/misc.hh (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/system.hh (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/system.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/utility.hh (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/arch/x86/utility.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>- src/cpu/kvm/x86_cpu.cc (8fc6e7a835d1d313e139c9095251105f904ac1b4)
>
> View Diff 
>
___
g

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

> On Dec. 10, 2014, 10:30 p.m., mike upton wrote:
> > There is some issue with AMD platforms. A test that used to run in 30 sec 
> > is not finishing.
> > 
> >
> 
> mike upton wrote:
> hello world passes. SPEC apps hang.
>
> 
> Gabe Black wrote:
> Can you identify where it's getting stuck? It could be there's something 
> wrong with how exception handling is set up, and it gets stuck faulting over 
> and over when a page fault happens, for instance. You could have the KVM CPU 
> print what the IP is each time it regains control and see if they cluster 
> somewhere interesting.
> 
> Gabe Black wrote:
> Any luck? Unfortunately the time I have to work on gem5 is pretty 
> limited, so I probably won't be able to dig into this for a while.
> 
> mike upton wrote:
> on the intel platform, with the test input set, all of cpu2006 integer 
> tests pass, except for astar.
> astar dies with a panic and page fault.
> [m5PageFault:build/X86/arch/x86/pseudo_inst.cc, line 85]
> 
> on the amd platform, all of the tests I tried fail to complete.
> time continues to advance, but instructions are not completing.
> 
> I am not sure what to do, I need the Intel platform code, but we should 
> not break the AMD side.
> 
> Are there any AMD folks I can work with to figure out how to get both 
> sides working?
> 
>
> 
> Alexandru Dutu wrote:
> Sorry about the late reply, I remember replying on a different mailing 
> list thread about this. I have tried this patch on my AMD system with some 
> short running applications and things worked fine. So, I will run cpu2006 and 
> see if there are any issues.
> 
> Alexandru Dutu wrote:
> When running SPEC CPU2006 with latest gem5 on a 6 core Bulldozer, Ubuntu 
> 14.04, linux 3.13.0-34, most of them call exit_group syscall except gromacs 
> which fails because of unimplemented clock_gettime syscall. This means they 
> ran until completion, however I have not yet checked if the output is 
> actually correct.
> 
> However, after applying this patch things break and there are unexpected 
> exits in the middle of the execution. Looking more into it and coming up with 
> more details.
>
> 
> Amit  Gaikwad wrote:
> I am new to gem5. Can someone please let me know where can I find the 
> wip.patch and also what will be command for patching gem5 ?

I am also having trouble running this patch on a different intel x86 system.
It looks like there are both segmentation changes, and KVM changes merged 
together.

Can we split it into 2 separate patches?

I think some of the style cleanup in the segmentation stuff changed the 
behavior.

If no one else does it, I will attempt a separate minimal patch that just fixes 
the KVM stuff.


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5673
---


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] simpoints and KVM

[mike upton via gem5-dev]

Oh, Bummer.

I was hoping to be able to get simpoints out of a KvmCPU run.
It seems like that is not possible.

Is it possible to generate checkpoints using the KvmCPU?
If so, I can run the benchmark once with the kvm, generating checkpoints
every N billion instructions.
I can then run each of those large samples in parallel to generate the
simpoints.

There will be some sample redundancy, but that is not a huge concern for me
at this point.


On Tue, Jan 13, 2015 at 12:11 AM, Andreas Hansson via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Mike,
>
> When you say KVM enabled, I presume you mean running the KvmCPU? As Mitch
> points out the problem is that you need something to attach the SimPoint
> probe to, and the KvmCPU does not have that functionality.
>
> Andreas
>
> On 13/01/2015 00:36, "Mitch Hayenga via gem5-dev" 
> wrote:
>
> >Hi Mike,
> >
> >I'm the one who wrote the initial version of the simpoint
> >collection/generation a few years ago. I enforced the "fastmem" option
> >primarily because I didn't see it necessary to simulate caches during
> >simpoint generation and it made simulation faster.  You can simply disable
> >this and it should all still work.
> >
> >For the "--cpu-type=atomic" option, initially simpoints were hardcoded
> >directly into the atomic CPU.  Since then, they've been changed to use the
> >"probe" system.  However, a quick grep of the code shows the
> >initialization
> >for the SimPoint probe only exists in the atomic CPU.  If you registered
> >the probe point with the TimingCPU as well, then that should work (I
> >think).
> >
> >
> >On Mon, Jan 12, 2015 at 5:02 PM, mike upton via gem5-dev
> >
> >wrote:
> >
> >> I am trying to enable simpoint generation with kvm enabled.
> >>
> >> Is there anything that inherently blocks this?
> >>
> >> Simpoints are currently enabled only with --fastmem and
> >>--cpu-type=atomic.
> >> How fundamental are each of these restrictions?
> >>
> >> Thanks,
> >>
> >> Mike
> >> ___
> >> 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
> >
>
>
> -- 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 mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] simpoints and KVM

[mike upton via gem5-dev]

I am trying to enable simpoint generation with kvm enabled.

Is there anything that inherently blocks this?

Simpoints are currently enabled only with --fastmem and --cpu-type=atomic.
How fundamental are each of these restrictions?

Thanks,

Mike
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] gem5 on redhat6

[mike upton via gem5-dev]

OK, thanks.

I don't understand what is going on, but blindly following the suggestion
made it work.

I needed to do:

python /usr/bin/scons 


Oh, I see what is going on.
/usr/bin/scons  has
#! /usr/bin/python

that is the wrong version...




On Fri, Jan 9, 2015 at 10:48 AM, Jason Power via gem5-dev  wrote:

> Hi Mike,
>
> The problem is that the python version your scons is using is different
> from your default python version (specified by environment variables e.g.
> PATH). Try "python scons ".
>
> Cheers,
> Jason
>
> On Fri Jan 09 2015 at 12:46:23 PM mike upton via gem5-dev <
> gem5-dev@gem5.org>
> wrote:
>
> > I have gem5 working fine on a redhat5 pool.
> > I was asked by our computing folks to move to redhat6.
> >
> > The compile goes fine. But when I try to run I get:
> >
> >  ./build/X86/gem5.opt ./configs/example/se.py -c
> > ./tests/test-progs/hello/bin/x86/linux/hello
> > Traceback (most recent call last):
> >   File "/home/mupton/gem5/src/python/importer.py", line 93, in 
> > sys.meta_path.append(importer)
> > TypeError: 'dict' object is not callable
> >
> >
> > I poked around some, but I don't understand what is going on.
> >
> > gcc=4.7
> > python=2.7.3
> > ___
> > 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

[gem5-dev] gem5 on redhat6

[mike upton via gem5-dev]

I have gem5 working fine on a redhat5 pool.
I was asked by our computing folks to move to redhat6.

The compile goes fine. But when I try to run I get:

 ./build/X86/gem5.opt ./configs/example/se.py -c
./tests/test-progs/hello/bin/x86/linux/hello
Traceback (most recent call last):
  File "/home/mupton/gem5/src/python/importer.py", line 93, in 
sys.meta_path.append(importer)
TypeError: 'dict' object is not callable


I poked around some, but I don't understand what is going on.

gcc=4.7
python=2.7.3
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] testing/regression update ETA?

[mike upton via gem5-dev]

Can you provide any further guidance?
What should be regressed? Just SE and FS across the ISAs?



On Wed, Jan 7, 2015 at 1:11 PM, Nilay Vaish via gem5-dev 
wrote:

> On Tue, 6 Jan 2015, mike upton via gem5-dev wrote:
>
>  Hi,
>>
>> I believe Ali had a proposal for an update to the testing/regression
>> infrastructure.
>>
>> Is there an ETA for that?
>>
>> I would like to automate testing and regressions across a bunch of ISAs.
>> I have available compute resources, but need some handholding on the
>> existing infrastructure.
>>
>> I would like to get to the point that we can test each proposed
>> modification.
>>
>>
> The current setup can be used through the script: util/regress.
>
> --
> Nilay
> ___
> 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] testing/regression update ETA?

[mike upton via gem5-dev]

Hi,

I believe Ali had a proposal for an update to the testing/regression
infrastructure.

Is there an ETA for that?

I would like to automate testing and regressions across a bunch of ISAs.
I have available compute resources, but need some handholding on the
existing infrastructure.

I would like to get to the point that we can test each proposed
modification.

Mike
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

> On Dec. 10, 2014, 10:30 p.m., mike upton wrote:
> > There is some issue with AMD platforms. A test that used to run in 30 sec 
> > is not finishing.
> > 
> >
> 
> mike upton wrote:
> hello world passes. SPEC apps hang.
>
> 
> Gabe Black wrote:
> Can you identify where it's getting stuck? It could be there's something 
> wrong with how exception handling is set up, and it gets stuck faulting over 
> and over when a page fault happens, for instance. You could have the KVM CPU 
> print what the IP is each time it regains control and see if they cluster 
> somewhere interesting.
> 
> Gabe Black wrote:
> Any luck? Unfortunately the time I have to work on gem5 is pretty 
> limited, so I probably won't be able to dig into this for a while.

on the intel platform, with the test input set, all of cpu2006 integer tests 
pass, except for astar.
astar dies with a panic and page fault.
[m5PageFault:build/X86/arch/x86/pseudo_inst.cc, line 85]

on the amd platform, all of the tests I tried fail to complete.
time continues to advance, but instructions are not completing.

I am not sure what to do, I need the Intel platform code, but we should not 
break the AMD side.

Are there any AMD folks I can work with to figure out how to get both sides 
working?


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5673
---


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/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: arm: Add unlinkat syscall implementation

[mike upton via gem5-dev]

changeset ae3b12c845b8 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=ae3b12c845b8
description:
arm: Add unlinkat syscall implementation

added ARM aarch64 unlinkat syscall support, modeled on other at 
syscalls.
This gets all of the cpu2006 int workloads passing in SE mode on 
aarch64.

Committed by: Nilay Vaish 

diffstat:

 src/arch/arm/linux/process.cc |   2 +-
 src/sim/syscall_emul.cc   |   8 +++-
 src/sim/syscall_emul.hh   |  17 +
 3 files changed, 25 insertions(+), 2 deletions(-)

diffs (66 lines):

diff -r b415e0dabe21 -r ae3b12c845b8 src/arch/arm/linux/process.cc
--- a/src/arch/arm/linux/process.cc Sat Jan 03 17:51:48 2015 -0600
+++ b/src/arch/arm/linux/process.cc Sat Jan 03 17:51:48 2015 -0600
@@ -523,7 +523,7 @@
 /*   32 */ SyscallDesc("flock", unimplementedFunc),
 /*   33 */ SyscallDesc("mknodat", unimplementedFunc),
 /*   34 */ SyscallDesc("mkdirat", unimplementedFunc),
-/*   35 */ SyscallDesc("unlinkat", unimplementedFunc),
+/*   35 */ SyscallDesc("unlinkat", unlinkatFunc),
 /*   36 */ SyscallDesc("symlinkat", unimplementedFunc),
 /*   37 */ SyscallDesc("linkat", unimplementedFunc),
 /*   38 */ SyscallDesc("renameat", unimplementedFunc),
diff -r b415e0dabe21 -r ae3b12c845b8 src/sim/syscall_emul.cc
--- a/src/sim/syscall_emul.cc   Sat Jan 03 17:51:48 2015 -0600
+++ b/src/sim/syscall_emul.cc   Sat Jan 03 17:51:48 2015 -0600
@@ -400,9 +400,15 @@
 SyscallReturn
 unlinkFunc(SyscallDesc *desc, int num, LiveProcess *p, ThreadContext *tc)
 {
+return unlinkHelper(desc, num, p, tc, 0);
+}
+
+SyscallReturn
+unlinkHelper(SyscallDesc *desc, int num, LiveProcess *p, ThreadContext *tc,
+   int index)
+{
 string path;
 
-int index = 0;
 if (!tc->getMemProxy().tryReadString(path, p->getSyscallArg(tc, index)))
 return -EFAULT;
 
diff -r b415e0dabe21 -r ae3b12c845b8 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Sat Jan 03 17:51:48 2015 -0600
+++ b/src/sim/syscall_emul.hh   Sat Jan 03 17:51:48 2015 -0600
@@ -195,6 +195,9 @@
LiveProcess *p, ThreadContext *tc);
 
 /// Target unlink() handler.
+SyscallReturn unlinkHelper(SyscallDesc *desc, int num,
+   LiveProcess *p, ThreadContext *tc,
+   int index);
 SyscallReturn unlinkFunc(SyscallDesc *desc, int num,
  LiveProcess *p, ThreadContext *tc);
 
@@ -655,6 +658,20 @@
 return openFunc(desc, callnum, process, tc, 1);
 }
 
+/// Target unlinkat() handler.
+template 
+SyscallReturn
+unlinkatFunc(SyscallDesc *desc, int callnum, LiveProcess *process,
+ ThreadContext *tc)
+{
+int index = 0;
+int dirfd = process->getSyscallArg(tc, index);
+if (dirfd != OS::TGT_AT_FDCWD)
+warn("unlinkat: first argument not AT_FDCWD; unlikely to work");
+
+return unlinkHelper(desc, callnum, process, tc, 1);
+}
+
 /// Target facessat() handler
 template 
 SyscallReturn
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2548: arm: Add unlinkat syscall implementation

[mike upton via gem5-dev]

> On Dec. 5, 2014, 5:45 p.m., Steve Reinhardt wrote:
> > Ship It!

Is there something blocking this change?


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2548/#review5646
---


On Dec. 5, 2014, 1:14 a.m., mike upton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2548/
> ---
> 
> (Updated Dec. 5, 2014, 1:14 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm: Add unlinkat syscall implementation
> 
> added ARM aarch64 unlinkat syscall support, modeled on other at 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] x86 SE kvm functionality (AMD vs Intel)

[mike upton via gem5-dev]

Gabe, is that an AMD system?

The intel side works fine, it is failing on an AMD system.

I will try to run some regression tests and see if I can find a failure in
the standard set of tests.

The AMD system I am on has a pretty old OS, which might be part of my issue.

I don't want to block the fix if it is working fine for others.
Getting the intel functionality is what I needed.




On Sun, Dec 14, 2014 at 9:53 PM, Gabe Black via gem5-dev 
wrote:
>
> I just tried running bzip2 approximately like the regressions would but
> with the KVM CPU, and it seemed to work just fine. The only thing I changed
> was I hacked se.py to set the cwd to what bzip2 expects. Can you please
> provide more specific instructions how to reproduce the hang/crash you're
> seeing? If this is working as expected, it would be good to get it checked
> in and get KVM working again.
>
> Gabe
>
>
>
>
>
> $ M5_CPU2000=/usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/
> ./build/X86/gem5.opt configs/example/se.py -c
>
> /usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2
> --cpu-type=kvm -o 'input.source 1'
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 compiled Dec 14 2014 21:18:54
> gem5 started Dec 14 2014 21:49:12
> gem5 executing on gabeblackz620.mtv.corp.google.com
> command line: ./build/X86/gem5.opt configs/example/se.py -c
>
> /usr/local/google/home/gabeblack/gem5/dist/m5/cpu2000/binaries/x86/linux/bzip2
> --cpu-type=kvm -o input.source 1
> Global frequency set at 1 ticks per second
> warn: DRAM device capacity (8192 Mbytes) does not match the address range
> assigned (512 Mbytes)
> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
>  REAL SIMULATION 
> info: KVM: Coalesced MMIO disabled by config.
> info: Entering event queue @ 0.  Starting simulation...
> warn: kvm-x86: MSR (0x12) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x11) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4b564d01) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4b564d00) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4000) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4001) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4073) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4b564d02) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4b564d03) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x4b564d04) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x3a) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x3b) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x6e0) unsupported by gem5. Skipping.
> warn: kvm-x86: MSR (0x1a0) unsupported by gem5. Skipping.
> spec_init
> Loading Input Data
> Input data 1048576 bytes in length
> Compressing Input Data, level 7
> info: Increasing stack size by one page.
> info: Increasing stack size by one page.
> info: Increasing stack size by one page.
> Compressed data 198546 bytes in length
> Uncompressing Data
> Uncompressed data 1048576 bytes in length
> Uncompressed data compared correctly
> Compressing Input Data, level 9
> Compressed data 198677 bytes in length
> Uncompressing Data
> Uncompressed data 1048576 bytes in length
> Uncompressed data compared correctly
> Tested 1MB buffer: OK!
> Exiting @ tick 13987682791500 because target called exit()
> hack: Pretending totalOps is equivalent to totalInsts()
>
> On Sat, Dec 13, 2014 at 12:12 AM, Andreas Hansson via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >
> > This patch should hopefully solve the issue with the refresh event:
> > http://reviews.gem5.org/r/2573/
> >
> > Andreas
> >
> > On 11/12/2014 15:52, "Andreas Hansson via gem5-dev" 
> > wrote:
> >
> > >Hi Alex, Mike,
> > >
> > >I¹ll try and fix this whole issue of the refresh event once and for all.
> > >SimpleMemory should only really be used for fast-forwarding and
> high-level
> > >sweeps, and I would like to ensure there are really no reasons to move
> > >away from the DRAM controller.
> > >
> > >It seems the sensible thing to do is to use startup and drainResume as
> the
> > >points where we check the mode of the memory system and either
> > >disable/enable the refresh event of the DRAM controller.
> > >
> > >Hopefully I will have something working before the weekend.
> > >
> > >Andreas
> > >
> > >On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" 
> > >wrote:
> > >
> > >>Hi Mike,
> >

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

[mike upton via gem5-dev]

libquantum runs fine.

I will do a sweep of all the apps and post the results.


On Thu, Dec 11, 2014 at 11:58 AM, mike upton  wrote:

> with --mem-type=SimpleMemory it panics and dies.
>
> this is using bzip2, I am going to try another benchmark as well.
>
>
> without SimpleMemory,
> bzip2 hangs sometime between the 20M and 30M instruction.  Time is
> advancing, but instructions are not retiring.
>
>
>
>
> On Thu, Dec 11, 2014 at 11:42 AM, mike upton 
> wrote:
>
>> I was using SE,  with just se.py --cpu-type=kvm
>>
>>
>>
>> On Thu, Dec 11, 2014 at 7:52 AM, Andreas Hansson via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hi Alex, Mike,
>>>
>>> I¹ll try and fix this whole issue of the refresh event once and for all.
>>> SimpleMemory should only really be used for fast-forwarding and
>>> high-level
>>> sweeps, and I would like to ensure there are really no reasons to move
>>> away from the DRAM controller.
>>>
>>> It seems the sensible thing to do is to use startup and drainResume as
>>> the
>>> points where we check the mode of the memory system and either
>>> disable/enable the refresh event of the DRAM controller.
>>>
>>> Hopefully I will have something working before the weekend.
>>>
>>> Andreas
>>>
>>> On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" 
>>> wrote:
>>>
>>> >Hi Mike,
>>> >
>>> >Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE,
>>> >I get very similar execution times with old implementation, for
>>> >SimpleMemory and classic memory with detailed memory controller. Also
>>> >what linux kernel are you using?
>>> >
>>> >Thanks,
>>> >Alex
>>> >
>>> >-Original Message-
>>> >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike
>>> upton
>>> >via gem5-dev
>>> >Sent: Wednesday, December 10, 2014 3:59 PM
>>> >To: gem5 Developer List
>>> >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
>>> >
>>> >I was testing this on both Intel and AMD platforms.
>>> >
>>> >The new code does seem to work for Intel platforms.
>>> >
>>> >The new code also seems to clean up a bunch of runtime warnings I was
>>> >getting on AMD platforms.
>>> >
>>> >However the new code on AMD is either much slower, or it is stuck in a
>>> >loop.
>>> >A test that runs for 30 sec with the old code is running for more than
>>> 10
>>> >mins, and still has a long way to go.
>>> >
>>> >
>>> >
>>> >On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev
>>> >>> >> wrote:
>>> >
>>> >> That's not actually extending the TSS limit, that's what it works out
>>> >> to be with the granularity bit set. The AM and WP bits were set to the
>>> >> wrong thing according to the comments next to them I'm pretty sure. If
>>> >> we wanted the other behavior, we might be able to change them back and
>>> >>have it work.
>>> >> The _BASE registers hold the base of segments as they're specified by
>>> >> the ISA. The _EFF_BASE registers hold the base that will actually be
>>> >> used in address calculations based on the mode of the CPU. For
>>> >> instance, if you're in 64 bit mode, the _BASE of DS might still be
>>> >> 0xFFF from when you were in another mode. The _EFF_BASE would be 0
>>> >> though, since the DS base is ignored in that case. _EFF_BASE may not
>>> >> be used by the KVM CPU, but it should be set up anyway in case we
>>> >>switch back to a regular CPU.
>>> >>
>>> >> Gabe
>>> >>
>>> >> On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev <
>>> >> gem5-dev@gem5.org> wrote:
>>> >>
>>> >> > Thank you for all the clarifications. I see that for SE to work on
>>> >> > vmx
>>> >> the
>>> >> > TSS limit had to be extended, am and wp bits in CR0 had to be reset
>>> >> > and *_EFF_BASE registers had be set in addition to *_BASE registers
>>> >> > for TR
>>> >> TSG
>>> >> > IDTR. I wonder what is TR_EFF_BASE. It seems that the con

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

[mike upton via gem5-dev]

with --mem-type=SimpleMemory it panics and dies.

this is using bzip2, I am going to try another benchmark as well.


without SimpleMemory,
bzip2 hangs sometime between the 20M and 30M instruction.  Time is
advancing, but instructions are not retiring.




On Thu, Dec 11, 2014 at 11:42 AM, mike upton  wrote:

> I was using SE,  with just se.py --cpu-type=kvm
>
>
>
> On Thu, Dec 11, 2014 at 7:52 AM, Andreas Hansson via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi Alex, Mike,
>>
>> I¹ll try and fix this whole issue of the refresh event once and for all.
>> SimpleMemory should only really be used for fast-forwarding and high-level
>> sweeps, and I would like to ensure there are really no reasons to move
>> away from the DRAM controller.
>>
>> It seems the sensible thing to do is to use startup and drainResume as the
>> points where we check the mode of the memory system and either
>> disable/enable the refresh event of the DRAM controller.
>>
>> Hopefully I will have something working before the weekend.
>>
>> Andreas
>>
>> On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" 
>> wrote:
>>
>> >Hi Mike,
>> >
>> >Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE,
>> >I get very similar execution times with old implementation, for
>> >SimpleMemory and classic memory with detailed memory controller. Also
>> >what linux kernel are you using?
>> >
>> >Thanks,
>> >Alex
>> >
>> >-Original Message-
>> >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike
>> upton
>> >via gem5-dev
>> >Sent: Wednesday, December 10, 2014 3:59 PM
>> >To: gem5 Developer List
>> >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
>> >
>> >I was testing this on both Intel and AMD platforms.
>> >
>> >The new code does seem to work for Intel platforms.
>> >
>> >The new code also seems to clean up a bunch of runtime warnings I was
>> >getting on AMD platforms.
>> >
>> >However the new code on AMD is either much slower, or it is stuck in a
>> >loop.
>> >A test that runs for 30 sec with the old code is running for more than 10
>> >mins, and still has a long way to go.
>> >
>> >
>> >
>> >On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev
>> >> >> wrote:
>> >
>> >> That's not actually extending the TSS limit, that's what it works out
>> >> to be with the granularity bit set. The AM and WP bits were set to the
>> >> wrong thing according to the comments next to them I'm pretty sure. If
>> >> we wanted the other behavior, we might be able to change them back and
>> >>have it work.
>> >> The _BASE registers hold the base of segments as they're specified by
>> >> the ISA. The _EFF_BASE registers hold the base that will actually be
>> >> used in address calculations based on the mode of the CPU. For
>> >> instance, if you're in 64 bit mode, the _BASE of DS might still be
>> >> 0xFFF from when you were in another mode. The _EFF_BASE would be 0
>> >> though, since the DS base is ignored in that case. _EFF_BASE may not
>> >> be used by the KVM CPU, but it should be set up anyway in case we
>> >>switch back to a regular CPU.
>> >>
>> >> Gabe
>> >>
>> >> On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev <
>> >> gem5-dev@gem5.org> wrote:
>> >>
>> >> > Thank you for all the clarifications. I see that for SE to work on
>> >> > vmx
>> >> the
>> >> > TSS limit had to be extended, am and wp bits in CR0 had to be reset
>> >> > and *_EFF_BASE registers had be set in addition to *_BASE registers
>> >> > for TR
>> >> TSG
>> >> > IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR
>> >> > register (which gets passed to kvm) are the same if with or without
>> >> > *_EFF_BASE registers set.
>> >> >
>> >> > Thank you,
>> >> > Alex
>> >> >
>> >> > -Original Message-
>> >> > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
>> >> Black
>> >> > via gem5-dev
>> >> > Sent: Wednesday, December 10, 2014 1:21 AM
>> >> > To: gem5 Developer 

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

[mike upton via gem5-dev]

I was using SE,  with just se.py --cpu-type=kvm



On Thu, Dec 11, 2014 at 7:52 AM, Andreas Hansson via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Alex, Mike,
>
> I¹ll try and fix this whole issue of the refresh event once and for all.
> SimpleMemory should only really be used for fast-forwarding and high-level
> sweeps, and I would like to ensure there are really no reasons to move
> away from the DRAM controller.
>
> It seems the sensible thing to do is to use startup and drainResume as the
> points where we check the mode of the memory system and either
> disable/enable the refresh event of the DRAM controller.
>
> Hopefully I will have something working before the weekend.
>
> Andreas
>
> On 11/12/2014 15:32, "Dutu, Alexandru via gem5-dev" 
> wrote:
>
> >Hi Mike,
> >
> >Are you running with SimpleMemory, SE or FS? On my AMD platform, for SE,
> >I get very similar execution times with old implementation, for
> >SimpleMemory and classic memory with detailed memory controller. Also
> >what linux kernel are you using?
> >
> >Thanks,
> >Alex
> >
> >-Original Message-
> >From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of mike upton
> >via gem5-dev
> >Sent: Wednesday, December 10, 2014 3:59 PM
> >To: gem5 Developer List
> >Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> >
> >I was testing this on both Intel and AMD platforms.
> >
> >The new code does seem to work for Intel platforms.
> >
> >The new code also seems to clean up a bunch of runtime warnings I was
> >getting on AMD platforms.
> >
> >However the new code on AMD is either much slower, or it is stuck in a
> >loop.
> >A test that runs for 30 sec with the old code is running for more than 10
> >mins, and still has a long way to go.
> >
> >
> >
> >On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev
> > >> wrote:
> >
> >> That's not actually extending the TSS limit, that's what it works out
> >> to be with the granularity bit set. The AM and WP bits were set to the
> >> wrong thing according to the comments next to them I'm pretty sure. If
> >> we wanted the other behavior, we might be able to change them back and
> >>have it work.
> >> The _BASE registers hold the base of segments as they're specified by
> >> the ISA. The _EFF_BASE registers hold the base that will actually be
> >> used in address calculations based on the mode of the CPU. For
> >> instance, if you're in 64 bit mode, the _BASE of DS might still be
> >> 0xFFF from when you were in another mode. The _EFF_BASE would be 0
> >> though, since the DS base is ignored in that case. _EFF_BASE may not
> >> be used by the KVM CPU, but it should be set up anyway in case we
> >>switch back to a regular CPU.
> >>
> >> Gabe
> >>
> >> On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev <
> >> gem5-dev@gem5.org> wrote:
> >>
> >> > Thank you for all the clarifications. I see that for SE to work on
> >> > vmx
> >> the
> >> > TSS limit had to be extended, am and wp bits in CR0 had to be reset
> >> > and *_EFF_BASE registers had be set in addition to *_BASE registers
> >> > for TR
> >> TSG
> >> > IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR
> >> > register (which gets passed to kvm) are the same if with or without
> >> > *_EFF_BASE registers set.
> >> >
> >> > Thank you,
> >> > Alex
> >> >
> >> > -Original Message-
> >> > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe
> >> Black
> >> > via gem5-dev
> >> > Sent: Wednesday, December 10, 2014 1:21 AM
> >> > To: gem5 Developer List
> >> > Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> >> >
> >> > Ok, I got SE working too. I'll clean up my patch and send that out
> >> > in a bit.
> >> >
> >> > Gabe
> >> >
> >> > On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black 
> >>wrote:
> >> >
> >> > > I figured out what the other problem was, so here's the review.
> >> > >
> >> > > http://reviews.gem5.org/r/2557/
> >> > >
> >> > > Gabe
> >> > >
> >> > > On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black 
> >> wrote:
> >>

Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

> On Dec. 10, 2014, 10:30 p.m., mike upton wrote:
> > There is some issue with AMD platforms. A test that used to run in 30 sec 
> > is not finishing.
> > 
> >

hello world passes. SPEC apps hang.


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5673
---


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/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 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5673
---


There is some issue with AMD platforms. A test that used to run in 30 sec is 
not finishing.



- mike upton


On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2557/
> ---
> 
> (Updated Dec. 10, 2014, 10:11 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10606:aa3eb7453246
> ---
> x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
> 
> There were a number of problems with how things were initialized which prevent
> VMX from running the simulation as a guest.
> 
> 
> Diffs
> -
> 
>   src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
>   src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 
> 
> Diff: http://reviews.gem5.org/r/2557/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

[mike upton via gem5-dev]

> Sent: Tuesday, December 09, 2014 2:09 AM
> > >>> >>> >> To: gem5 Developer List
> > >>> >>> >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs
> > >>> >>> >> Intel)
> > >>> >>> >>
> > >>> >>> >> You are right Nilay. I sent an email last week but nobody has
> > >>> replied.
> > >>> >>> >>
> > >>> >>> >> It seems that descriptors (cdDesc, dsDesc and tssDesc)
> > >>> >>> >> located in src/arch/x86/system.cc file are not
> > >>> >>> >> well-initialized and as a consequence kvm does not work when
> > running in full-system mode.
> > >>> >>> >>
> > >>> >>> >> Segment limits values (limitHigh and limitLow) are
> > >>> >>> >> interchanged and several segment descriptor values are wrong
> > >>> >>> >> too. If these values are corrected kvm works again as before.
> > >>> >>> >>
> > >>> >>> >> Adrian
> > >>> >>> >>
> > >>> >>> >> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via
> > >>> >>> >> gem5-dev
> > >>> >>> escribió:
> > >>> >>> >> > I also faced problem in getting KVM CPU to run in FS mode.
> > >>> >>> >> > I figured
> > >>> >>> >> that
> > >>> >>> >> > the following changeset causes problems:
> > >>> >>> >> >
> > >>> >>> >> > authorAlexandru Dutu 
> > >>> >>> >> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> > >>> >>> >> > changeset 10554   fe2e2f06a7c8
> > >>> >>> >> >
> > >>> >>> >> > I saw the hardware reason 0x8021, but did not try to
> > >>> >>> >> > figure what was going on wrong.
> > >>> >>> >> >
> > >>> >>> >> > --
> > >>> >>> >> > Nilay
> > >>> >>> >> >
> > >>> >>> >> > On Mon, 8 Dec 2014, Gabe Black via gem5-dev wrote:
> > >>> >>> >> >
> > >>> >>> >> > > I'm pretty sure entering 64 bit mode is the same between
> > >>> >>> >> > > AMD and Intel CPUs. I vaguely remember there being some
> > >>> >>> >> > > subtle page table difference though, and gem5 is building
> > >>> >>> >> > > the page tables in SE mode instead of the kernel.
> > >>> >>> >> > >
> > >>> >>> >> > > Gabe
> > >>> >>> >> > >
> > >>> >>> >> > > On Mon, Dec 8, 2014 at 7:44 PM, Dutu, Alexandru via
> > >>> >>> >> > > gem5-dev < gem5-dev@gem5.org> wrote:
> > >>> >>> >> > >
> > >>> >>> >> > >> Hi Mike,
> > >>> >>> >> > >>
> > >>> >>> >> > >> trace-cmd is a very handy tool to get an overview of
> > >>> >>> >> > >> what the kvm
> > >>> >>> >> kernel
> > >>> >>> >> > >> module is doing before going into gdb. In extreme cases
> > >>> >>> >> > >> ftrace can be useful as well.
> > >>> >>> >> > >> What is the error that you are seeing? Is it still
> > >>> >>> >> > >> failing to enter virtualized mode?
> > >>> >>> >> > >>
> > >>> >>> >> > >> If that is the case and the hardware reason is
> > >>> >>> >> > >> 0x8021, that
> > >>> >>> >> seems to
> > >>> >>> >> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h
> > >>> >>> >> > >> in linux
> > >>> >>> >> kernel
> > >>> >>> >>

[gem5-dev] exit status of simpoint samples

[mike upton via gem5-dev]

I am running a set of checkpointed samples via the new simpoint patch.

it seems that when the simulation ends at the end of the sample, gem5
returns a non-zero code (127 I think).

Is this intended?

when gem5 reaches the end of the program via exit()  it returns 0.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)

[mike upton via gem5-dev]

Will someone be providing a patch for this? I am happy to test it.
From Adrian's description it seems there are a bunch of issues.



On Tue, Dec 9, 2014 at 12:09 AM, Adrián Colaso Diego via gem5-dev <
gem5-dev@gem5.org> wrote:

> You are right Nilay. I sent an email last week but nobody has replied.
>
> It seems that descriptors (cdDesc, dsDesc and tssDesc) located in
> src/arch/x86/system.cc file are not well-initialized and as a
> consequence kvm does not work when running in full-system mode.
>
> Segment limits values (limitHigh and limitLow) are interchanged and
> several segment descriptor values are wrong too. If these
> values are corrected kvm works again as before.
>
> Adrian
>
> El lun, 08-12-2014 a las 22:50 -0600, Nilay Vaish via gem5-dev escribió:
> > I also faced problem in getting KVM CPU to run in FS mode.  I figured
> that
> > the following changeset causes problems:
> >
> > authorAlexandru Dutu 
> >   Sun Nov 23 18:01:08 2014 -0800 (2 weeks ago)
> > changeset 10554   fe2e2f06a7c8
> >
> > I saw the hardware reason 0x8021, but did not try to figure what was
> > going on wrong.
> >
> > --
> > Nilay
> >
> > On Mon, 8 Dec 2014, Gabe Black via gem5-dev wrote:
> >
> > > I'm pretty sure entering 64 bit mode is the same between AMD and Intel
> > > CPUs. I vaguely remember there being some subtle page table difference
> > > though, and gem5 is building the page tables in SE mode instead of the
> > > kernel.
> > >
> > > Gabe
> > >
> > > On Mon, Dec 8, 2014 at 7:44 PM, Dutu, Alexandru via gem5-dev <
> > > gem5-dev@gem5.org> wrote:
> > >
> > >> Hi Mike,
> > >>
> > >> trace-cmd is a very handy tool to get an overview of what the kvm
> kernel
> > >> module is doing before going into gdb. In extreme cases ftrace can be
> > >> useful as well.
> > >> What is the error that you are seeing? Is it still failing to enter
> > >> virtualized mode?
> > >>
> > >> If that is the case and the hardware reason is 0x8021, that seems
> to
> > >> be an unrecoverable exception (drivers/hv/hyperv_vmbus.h in linux
> kernel
> > >> source code). When running in SE mode, we are trying to bring the
> machine
> > >> state to full 64bit mode without going through legacy modes. It might
> be
> > >> that Intel machines have a different way of going to 64bit mode than
> AMD
> > >> machines (different CR4, different way of enabling 64bit mode page
> tables
> > >> etc.). I remember dealing with these issue for AMD platforms by going
> > >> through System Programming manual and making sure gem5 gets all the
> bits
> > >> right as there is not much the KVM kernel model will tell about the
> cause
> > >> of failure.
> > >>
> > >> Best regards,
> > >> Alex
> > >> 
> > >> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black
> via
> > >> gem5-dev [gem5-dev@gem5.org]
> > >> Sent: Monday, December 08, 2014 7:08 PM
> > >> To: gem5 Developer List
> > >> Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
> > >>
> > >> I'm not an expert either, but I did have problems running KVM in SE
> mode on
> > >> an Intel CPU. I didn't look into it that much, but I think things
> failed in
> > >> the kernel somewhere. What might be happening is that the different
> vendors
> > >> hardware virtualization mechanisms are more or less picky about
> various
> > >> things. Something might be set up incorrectly, and one implementation
> gets
> > >> more upset about it than the other. I believe there are tools which
> will
> > >> help you determine whether your VM state is legal. Perhaps Andreas
> can tell
> > >> you more about those?
> > >>
> > >> Gabe
> > >>
> > >> On Mon, Dec 8, 2014 at 4:29 PM, mike upton via gem5-dev <
> gem5-dev@gem5.org
> > >>>
> > >> wrote:
> > >>
> > >>> I have verified that x86 kvm works fine on AMD platforms, but fails
> on
> > >>> Intel platforms.
> > >>>
> > >>> Any hints about how to narrow down the cause (other than diving into
> gdb,
> > >>> which I will do).
> > >>>
> > >>> I am not an expert in KVM or how gem5

[gem5-dev] x86 SE kvm functionality (AMD vs Intel)

[mike upton via gem5-dev]

I have verified that x86 kvm works fine on AMD platforms, but fails on
Intel platforms.

Any hints about how to narrow down the cause (other than diving into gdb,
which I will do).

I am not an expert in KVM or how gem5 hooks up to libkvm.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2548: arm: Add unlinkat syscall implementation

[mike upton via gem5-dev]

> On Dec. 4, 2014, 3:03 p.m., Nilay Vaish wrote:
> > src/sim/syscall_emul.hh, line 201
> > 
> >
> > How will the compiler choose between the two versions of unlinkFunc?  I 
> > think we should either drop the default argument or drop the second version.
> 
> mike upton wrote:
> I just copied other instances of similar functionality.
> 
> 
> My understanding is the compiler knows which to use because of the 
> parameter count passed in.
> 
> I am happy to remove the 4 parameter version, but it will take me a bit 
> to code and test it.
> 
>
> 
> Ali Saidi wrote:
> The 4 parameter version can't be removed because SyscallDesc requires a 
> function pointer that has four parameters. That is why this version gets 
> called and otherwise the 5 parameter version is used. The default parameter 
> for the 5 parameter version could probably be removed, but removing the 4 
> parameter version would required templetizing SyscallDesc to support 4 and 5 
> parameter functions or changing all sys call functions to require 5 
> parameters.

Steve suggested changing the name of the 5 element func to unlinkHelper.
I did that. Let me know if I should update the other syscall routines in a 
similar fashion.


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2548/#review5618
---


On Dec. 5, 2014, 1:14 a.m., mike upton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2548/
> ---
> 
> (Updated Dec. 5, 2014, 1:14 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm: Add unlinkat syscall implementation
> 
> added ARM aarch64 unlinkat syscall support, modeled on other at 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] Review Request 2548: arm: Add unlinkat syscall implementation

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2548/
---

(Updated Dec. 5, 2014, 1:14 a.m.)


Review request for Default.


Changes
---

Renamed 5 element function to unlinkHelper


Repository: gem5


Description
---

arm: Add unlinkat syscall implementation

added ARM aarch64 unlinkat syscall support, modeled on other at syscalls.
This gets all of the cpu2006 int workloads passing in SE mode on aarch64.

hmmer, omnetpp


Diffs (updated)
-

  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] Review Request 2548: arm: Add unlinkat syscall implementation

[mike upton via gem5-dev]

I am fine with the unlinkHelper suggestion, but this makes the new code
different from the other syscall implentations. (openFunc, readlinkFunc,
etc).

I simply copied what was already there.

I will update the diff, and folks can let me know if you want the other
functions mapped to a similar architecture...



On Thu, Dec 4, 2014 at 3:12 PM, Steve Reinhardt  wrote:

>
>
> On Thu, Dec 4, 2014 at 2:50 PM, Ali Saidi via gem5-dev 
> wrote:
>
>>
>> The default parameter for the 5 parameter version could probably be
>> removed
>
>
> s/could probably/should definitely/, I would say.
>
> I believe the 5-parameter version only gets called from either the
> 4-parameter version or from unlinkatFunc, so the default value is never
> used and only sows confusion.  The 5-parameter version could even be
> renamed something like unlinkHelper.
>
> Steve
>
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2548: arm: Add unlinkat syscall implementation

[mike upton via gem5-dev]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2548/
---

(Updated Dec. 4, 2014, 10:20 p.m.)


Review request for Default.


Changes
---

fixed the two indenting issues


Repository: gem5


Description
---

arm: Add unlinkat syscall implementation

added ARM aarch64 unlinkat syscall support, modeled on other at syscalls.
This gets all of the cpu2006 int workloads passing in SE mode on aarch64.

hmmer, omnetpp


Diffs (updated)
-

  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] Review Request 2548: arm: Add unlinkat syscall implementation

[mike upton via gem5-dev]

> On Dec. 4, 2014, 3:03 p.m., Nilay Vaish wrote:
> > src/sim/syscall_emul.hh, line 201
> > 
> >
> > How will the compiler choose between the two versions of unlinkFunc?  I 
> > think we should either drop the default argument or drop the second version.

I just copied other instances of similar functionality.


My understanding is the compiler knows which to use because of the parameter 
count passed in.

I am happy to remove the 4 parameter version, but it will take me a bit to code 
and test it.


- mike


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2548/#review5618
---


On Dec. 3, 2014, 7:10 p.m., mike upton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2548/
> ---
> 
> (Updated Dec. 3, 2014, 7:10 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> arm: Add unlinkat syscall implementation
> 
> added ARM aarch64 unlinkat syscall support, modeled on other at 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] testing

[mike upton via gem5-dev]

I would love to contribute to this...

Does anyone have gem5 hooked up to ant or other CI testing infrastructure?



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 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
>
___
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

[mike upton via gem5-dev]

---
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 at 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

[gem5-dev] Hooking up unimplemented syscalls

[Mike Upton via gem5-dev]

I am running CPU2006 benchmarks, and hit a few unimplemented syscalls.

For example: omnetpp
Fatal: syscall unlinkat (#35) unimplemented.
@ tick 958189000


I modified the src following the existing templates for the other syscalls, and 
got a model to compile.
However, when I run it I get the same result.

I cant figure out where in the code the syscall number mapping happens.

How do I get the syscall #35 to map to my new unlinkatFunc()?


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev