[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/inorder-timing passed. [ STRIP] X86_MESI_Two_Level/gem5.fast.unstripped - .fast * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/inorder-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby
[gem5-dev] Kernel panic caused by changeset 10552
Hi everyone, I found x86_64-vmlinux-2.6.28.4 panic when apply changeset 10552: cpuid, x86: Enabling more features in CPUid. (2.6.22.9 works fine) The gem5 also report warn: x86 cpuid: unimplemented function 13, and kernel report BUG at arch/x86/kernel/xsave.c:323 as following. Can anybody check/fix this bug? Thanks. KERNEL OUTPUT -- MPTABLE: APIC at: 0xFEE0 Processor #0 (Bootup-CPU) I/O APIC #1 Version 17 at 0xFEC0. Processors: 1 Allocating PCI resources starting at c400 (gap: c000:3fff) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 127500 Kernel command line: earlyprintk=ttyS0 console=ttyS0 lpj=723 root=/dev/hda1 Initializing CPU#0 FP/SSE not shown under xsave features 0x80050033000d [ cut here ] kernel BUG at arch/x86/kernel/xsave.c:323! invalid opcode: [#1] last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: GW 2.6.28.4 #2 RIP: 0010:[80577b45] [80577b45] xsave_cntxt_init+0x35/0x130 RSP: 0018:80769f48 EFLAGS: 00b8 RAX: 003c RBX: RCX: 807cd460 RDX: RSI: 0d5c RDI: 80702180 RBP: R08: R09: 03fd R10: R11: R12: R13: R14: R15: FS: () GS:807bf020() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 80050033 CR2: CR3: 00201000 CR4: 06a0 DR0: DR1: DR2: DR3: DR6: DR7: Process swapper (pid: 0, threadinfo 80768000, task 806f5380) Stack: 8078f133 80795000 8078fe72 8000896f59002087 8022ee104a50 80794000 80795000 8076a98d 80795000 Call Trace: [8078f133] fpu_init+0x3e/0x8e [8078fe72] cpu_init+0x222/0x240 [8076a98d] start_kernel+0x16f/0x2d9 [8076a407] x86_64_start_kernel+0xd9/0xdfCode: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 12 a6 24 00 83 e0 03 48 83 f8 03 74 12 48 c7 c7 50 74 67 80 31 c0 e8 9c 30 01 00 0f 0b eb fe f6 05 57 b7 1e 00 04 48 c7 05 e5 a5 24 00 03 00 00 RIP [80577b45] xsave_cntxt_init+0x35/0x130 RSP 80769f48 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Jiuyue ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Kernel panic caused by changeset 10552
Yeah, I was going to say something about that. CPUID shouldn't advertise features that we don't support. For instance, that change tells CPUID to say we support AVX, but the decoder has no idea what to do with those instructions and will trigger an exception if one is executed. I noticed a bunch of undefined instruction exceptions in my own workload that weren't happening before, and I wonder if that's the cause. I'm not sure how that change helps support KVM in SE mode. Perhaps it should be reverted? Can you explain why it's necessary Alex? If it is, maybe we can reshape it a bit to avoid these side effects. Gabe On Wed, Dec 10, 2014 at 12:43 AM, 马久跃 via gem5-dev gem5-dev@gem5.org wrote: Hi everyone, I found x86_64-vmlinux-2.6.28.4 panic when apply changeset 10552: cpuid, x86: Enabling more features in CPUid. (2.6.22.9 works fine) The gem5 also report warn: x86 cpuid: unimplemented function 13, and kernel report BUG at arch/x86/kernel/xsave.c:323 as following. Can anybody check/fix this bug? Thanks. KERNEL OUTPUT -- MPTABLE: APIC at: 0xFEE0 Processor #0 (Bootup-CPU) I/O APIC #1 Version 17 at 0xFEC0. Processors: 1 Allocating PCI resources starting at c400 (gap: c000:3fff) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 127500 Kernel command line: earlyprintk=ttyS0 console=ttyS0 lpj=723 root=/dev/hda1 Initializing CPU#0 FP/SSE not shown under xsave features 0x80050033000d [ cut here ] kernel BUG at arch/x86/kernel/xsave.c:323! invalid opcode: [#1] last sysfs file: CPU 0 Modules linked in: Pid: 0, comm: swapper Tainted: GW 2.6.28.4 #2 RIP: 0010:[80577b45] [80577b45] xsave_cntxt_init+0x35/0x130 RSP: 0018:80769f48 EFLAGS: 00b8 RAX: 003c RBX: RCX: 807cd460 RDX: RSI: 0d5c RDI: 80702180 RBP: R08: R09: 03fd R10: R11: R12: R13: R14: R15: FS: () GS:807bf020() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 80050033 CR2: CR3: 00201000 CR4: 06a0 DR0: DR1: DR2: DR3: DR6: DR7: Process swapper (pid: 0, threadinfo 80768000, task 806f5380) Stack: 8078f133 80795000 8078fe72 8000896f59002087 8022ee104a50 80794000 80795000 8076a98d 80795000 Call Trace: [8078f133] fpu_init+0x3e/0x8e [8078fe72] cpu_init+0x222/0x240 [8076a98d] start_kernel+0x16f/0x2d9 [8076a407] x86_64_start_kernel+0xd9/0xdfCode: 48 c1 e2 20 89 c0 48 8d 34 02 48 89 f0 48 89 35 12 a6 24 00 83 e0 03 48 83 f8 03 74 12 48 c7 c7 50 74 67 80 31 c0 e8 9c 30 01 00 0f 0b eb fe f6 05 57 b7 1e 00 04 48 c7 05 e5 a5 24 00 03 00 00 RIP [80577b45] xsave_cntxt_init+0x35/0x130 RSP 80769f48 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Jiuyue ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports
On Dec. 10, 2014, 3:17 a.m., Joel Hestness wrote: src/mem/ruby/system/RubyPort.cc, line 372 http://reviews.gem5.org/r/2549/diff/2/?file=42942#file42942line372 So, I'm not sure I follow how this can work... The RubySequencer can still block a request if (1) a master issues accesses in excess of the sequencer's outstanding request count, or (2) the master issues an access for a cache line with an existing outstanding access. Are there no mainline gem5 masters (e.g. CPU cores) that rely on the retry signal to restart injection after bumping up against either of these blocking conditions? Gem5-gpu GPU LSQs currently rely on the Sequencer retry signals. Ok, after another look there is indeed additional complications here due to the fact that we do not always pass the packet on to the normal port through schedTiming. I suggest we resolve the issue Steve highlighted before going any further with this patch. - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/#review5658 --- On Dec. 9, 2014, 3:15 p.m., Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2549/ --- (Updated Dec. 9, 2014, 3:15 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10602:d3bb9d95bf76 --- ruby: ruby port: do not check for blocked ports RubyPort used to maintain a list of blocked ports which are sent retries when the port becomes unblocked. This is unnecessary since RubyPort's port definitions inherit from QueuedPort. Diffs - src/mem/ruby/system/RubyPort.hh 6efb37480d87 src/mem/ruby/system/RubyPort.cc 6efb37480d87 Diff: http://reviews.gem5.org/r/2549/diff/ Testing --- Thanks, Nilay Vaish ___ 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.
--- 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. Summary (updated) - x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs. Repository: gem5 Description (updated) --- 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 (updated) - 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.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2557/#review5663 --- Ok, now it's for real. Review away. - Gabe Black 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] Review Request 2558: cpu: remove legion tracer
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2558/ --- Review request for Default. Repository: gem5 Description --- Changeset 10607:39f916f824c2 --- cpu: remove legion tracer If someone wants to debug with legion again they can restore the code from the repository, but no need to have it hang around indefinately. Diffs - src/cpu/LegionTrace.py 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 src/cpu/base.hh 4e09ae443c96 src/cpu/base.cc 4e09ae443c96 src/cpu/legiontrace.hh 4e09ae443c96 src/cpu/legiontrace.cc 4e09ae443c96 src/cpu/m5legion_interface.h 4e09ae443c96 src/cpu/simple/atomic.cc 4e09ae443c96 src/cpu/simple/timing.cc 4e09ae443c96 Diff: http://reviews.gem5.org/r/2558/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2559: cpu: Put all CPU instruction tracers in a single file
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2559/ --- Review request for Default. Repository: gem5 Description --- Changeset 10608:e4487b2cc58c --- cpu: Put all CPU instruction tracers in a single file Diffs - src/arch/arm/ArmNativeTrace.py 4e09ae443c96 src/arch/sparc/SparcNativeTrace.py 4e09ae443c96 src/arch/x86/X86NativeTrace.py 4e09ae443c96 src/cpu/BaseCPU.py 4e09ae443c96 src/cpu/CPUTracers.py PRE-CREATION src/cpu/ExeTracer.py 4e09ae443c96 src/cpu/IntelTrace.py 4e09ae443c96 src/cpu/NativeTrace.py 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 Diff: http://reviews.gem5.org/r/2559/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2560: cpu: Remove all notion that we know when the cpu is misspeculating.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2560/ --- Review request for Default. Repository: gem5 Description --- Changeset 10609:afab72978b08 --- cpu: Remove all notion that we know when the cpu is misspeculating. We have no way of knowing if a CPU model is on the wrong path with our execute-in-execute CPU models. Don't pretend that we do. Diffs - src/arch/alpha/ev5.cc 4e09ae443c96 src/arch/alpha/faults.cc 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 src/cpu/checker/thread_context.hh 4e09ae443c96 src/cpu/exetrace.hh 4e09ae443c96 src/cpu/exetrace.cc 4e09ae443c96 src/cpu/inorder/thread_context.hh 4e09ae443c96 src/cpu/inteltrace.hh 4e09ae443c96 src/cpu/nativetrace.hh 4e09ae443c96 src/cpu/o3/thread_context.hh 4e09ae443c96 src/cpu/simple/base.hh 4e09ae443c96 src/cpu/simple_thread.hh 4e09ae443c96 src/cpu/thread_context.hh 4e09ae443c96 src/sim/faults.cc 4e09ae443c96 src/sim/insttracer.hh 4e09ae443c96 Diff: http://reviews.gem5.org/r/2560/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2561: sim: Clean up InstRecord
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2561/ --- Review request for Default. Repository: gem5 Description --- Changeset 10610:67236857bfc6 --- sim: Clean up InstRecord Track memory size and flags as well as add some comments and consts. Diffs - src/cpu/base_dyn_inst.hh 4e09ae443c96 src/cpu/exetrace.cc 4e09ae443c96 src/cpu/inorder/resources/cache_unit.cc 4e09ae443c96 src/cpu/minor/lsq.cc 4e09ae443c96 src/cpu/simple/atomic.cc 4e09ae443c96 src/cpu/simple/timing.cc 4e09ae443c96 src/sim/insttracer.hh 4e09ae443c96 Diff: http://reviews.gem5.org/r/2561/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2562: arm: always set the IsFirstMicroop flag
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2562/ --- Review request for Default. Repository: gem5 Description --- Changeset 10611:1fd5aa3c4669 --- arm: always set the IsFirstMicroop flag While the IsFirstMicroop flag exists it was only occasionally used in the ARM instructions that gem5 microOps and therefore couldn't be relied on to be correct. Diffs - src/arch/arm/insts/macromem.cc 4e09ae443c96 src/arch/arm/isa/templates/mem.isa 4e09ae443c96 src/arch/arm/isa/templates/mem64.isa 4e09ae443c96 src/cpu/static_inst.hh 4e09ae443c96 Diff: http://reviews.gem5.org/r/2562/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2563: cpu: add support for outputing a protobuf formatted CPU trace
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2563/ --- Review request for Default. Repository: gem5 Description --- Changeset 10612:3e9fa4687536 --- cpu: add support for outputing a protobuf formatted CPU trace Diffs - src/cpu/InstPBTrace.py PRE-CREATION src/cpu/SConscript 4e09ae443c96 src/cpu/inst_pb_trace.hh PRE-CREATION src/cpu/inst_pb_trace.cc PRE-CREATION src/proto/SConscript 4e09ae443c96 src/proto/inst.proto PRE-CREATION util/decode_inst_trace.py PRE-CREATION Diff: http://reviews.gem5.org/r/2563/diff/ Testing --- Thanks, Ali Saidi ___ 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)
Thank you for all the clarifications. I see that for SE to work on vmx the TSS limit had to be extended, am and wp bits in CR0 had to be reset and *_EFF_BASE registers had be set in addition to *_BASE registers for TR TSG IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR register (which gets passed to kvm) are the same if with or without *_EFF_BASE registers set. Thank you, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Wednesday, December 10, 2014 1:21 AM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) Ok, I got SE working too. I'll clean up my patch and send that out in a bit. Gabe On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black gabebl...@google.com wrote: I figured out what the other problem was, so here's the review. http://reviews.gem5.org/r/2557/ Gabe On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black gabebl...@google.com wrote: It was attached in my sent mail. Maybe it's being blocked by something? I'm hunting down another problem so I don't want to move my tree around too much, but once that's done I'll post it as a review. Gabe On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: I haven't received any attachment to your email. So I don't have your patch. Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:42 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) And... it turns out the KVM change wasn't necessary. If you're working from my patch, get rid of where the segment limit is divided by PageBytes. That was only necessary because I wasn't adding 0xFFF to the limit when the granularity bit was set. Gabe On Tue, Dec 9, 2014 at 4:31 PM, Gabe Black gabebl...@google.com wrote: Oh, also segment limits weren't being computed correctly in the installSegDesc function, although I don't think that was from the KVM stuff. Once it was fixed it required adjusting the KVM stuff a little, though. Gabe On Tue, Dec 9, 2014 at 4:29 PM, Gabe Black gabebl...@google.com wrote: Here is my patch so far. There were a few things wrong, although I didn't really keep notes. The limits were mixed up, the long mode bit was set on all descriptors when it's only valid for the code segment, privilege level 0 is the OS and 3 is for applications and not the other way around, and I think the type was being set wrong for one of the segments. Also, the syscall and sysenter registers (star and friends) require the segments in the GDT to be in a particular order which I don't think they were. Gabe On Tue, Dec 9, 2014 at 4:22 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: So, I am doing this on an AMD system and I have SE working and am able to get FS entering into virtualized mode. However, in FS I get an early exception while the kernel is booting. This seems a bit different from what Nilay and Adrian observed for FS. Could you please share the diffs that got FS working? Thanks, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:07 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) Oh, I see you have FS working again and not SE. NM, I'll keep looking. Gabe On Tue, Dec 9, 2014 at 4:04 PM, Gabe Black gabebl...@google.com wrote: I have FS working again which is good, but I'm still having problems with SE. If you could let me know what you did to get things going that would be very helpful. Gabe On Tue, Dec 9, 2014 at 10:06 AM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Hi Adrian, Sorry for missing your first email. I do see the interchanged segment limits for full system mode, though I get a different behaviour on my system. The simulation seems to hang in the following manner: Processor #0 (Bootup-CPU) I/O APIC #1 at 0xFEC0. Setting APIC routing to flat Processors: 1 PANIC: early exception rip 807909a9 error 9 cr2 ff5fd020 Can please provide a patch with all the modifications that fixed the issue on your system? Thank you, Alex From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Adrián Colaso Diego via gem5-dev [gem5-dev@gem5.org] 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
Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel)
That's not actually extending the TSS limit, that's what it works out to be with the granularity bit set. The AM and WP bits were set to the wrong thing according to the comments next to them I'm pretty sure. If we wanted the other behavior, we might be able to change them back and have it work. The _BASE registers hold the base of segments as they're specified by the ISA. The _EFF_BASE registers hold the base that will actually be used in address calculations based on the mode of the CPU. For instance, if you're in 64 bit mode, the _BASE of DS might still be 0xFFF from when you were in another mode. The _EFF_BASE would be 0 though, since the DS base is ignored in that case. _EFF_BASE may not be used by the KVM CPU, but it should be set up anyway in case we switch back to a regular CPU. Gabe On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Thank you for all the clarifications. I see that for SE to work on vmx the TSS limit had to be extended, am and wp bits in CR0 had to be reset and *_EFF_BASE registers had be set in addition to *_BASE registers for TR TSG IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR register (which gets passed to kvm) are the same if with or without *_EFF_BASE registers set. Thank you, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Wednesday, December 10, 2014 1:21 AM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) Ok, I got SE working too. I'll clean up my patch and send that out in a bit. Gabe On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black gabebl...@google.com wrote: I figured out what the other problem was, so here's the review. http://reviews.gem5.org/r/2557/ Gabe On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black gabebl...@google.com wrote: It was attached in my sent mail. Maybe it's being blocked by something? I'm hunting down another problem so I don't want to move my tree around too much, but once that's done I'll post it as a review. Gabe On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: I haven't received any attachment to your email. So I don't have your patch. Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:42 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) And... it turns out the KVM change wasn't necessary. If you're working from my patch, get rid of where the segment limit is divided by PageBytes. That was only necessary because I wasn't adding 0xFFF to the limit when the granularity bit was set. Gabe On Tue, Dec 9, 2014 at 4:31 PM, Gabe Black gabebl...@google.com wrote: Oh, also segment limits weren't being computed correctly in the installSegDesc function, although I don't think that was from the KVM stuff. Once it was fixed it required adjusting the KVM stuff a little, though. Gabe On Tue, Dec 9, 2014 at 4:29 PM, Gabe Black gabebl...@google.com wrote: Here is my patch so far. There were a few things wrong, although I didn't really keep notes. The limits were mixed up, the long mode bit was set on all descriptors when it's only valid for the code segment, privilege level 0 is the OS and 3 is for applications and not the other way around, and I think the type was being set wrong for one of the segments. Also, the syscall and sysenter registers (star and friends) require the segments in the GDT to be in a particular order which I don't think they were. Gabe On Tue, Dec 9, 2014 at 4:22 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: So, I am doing this on an AMD system and I have SE working and am able to get FS entering into virtualized mode. However, in FS I get an early exception while the kernel is booting. This seems a bit different from what Nilay and Adrian observed for FS. Could you please share the diffs that got FS working? Thanks, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:07 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) Oh, I see you have FS working again and not SE. NM, I'll keep looking. Gabe On Tue, Dec 9, 2014 at 4:04 PM, Gabe Black gabebl...@google.com wrote: I have FS working again which is good, but I'm still having problems with SE. If you could let me know what you did to get things going that would be very helpful. Gabe On Tue, Dec 9, 2014 at 10:06 AM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Hi Adrian, Sorry for missing your
Re: [gem5-dev] Review Request 2558: cpu: remove legion tracer
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2558/#review5665 --- Ship it! Ship It! - Gabe Black On Dec. 10, 2014, 5:54 p.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2558/ --- (Updated Dec. 10, 2014, 5:54 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10607:39f916f824c2 --- cpu: remove legion tracer If someone wants to debug with legion again they can restore the code from the repository, but no need to have it hang around indefinately. Diffs - src/cpu/LegionTrace.py 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 src/cpu/base.hh 4e09ae443c96 src/cpu/base.cc 4e09ae443c96 src/cpu/legiontrace.hh 4e09ae443c96 src/cpu/legiontrace.cc 4e09ae443c96 src/cpu/m5legion_interface.h 4e09ae443c96 src/cpu/simple/atomic.cc 4e09ae443c96 src/cpu/simple/timing.cc 4e09ae443c96 Diff: http://reviews.gem5.org/r/2558/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2559: cpu: Put all CPU instruction tracers in a single file
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2559/#review5667 --- Ship it! Ship It! - Gabe Black On Dec. 10, 2014, 5:54 p.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2559/ --- (Updated Dec. 10, 2014, 5:54 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10608:e4487b2cc58c --- cpu: Put all CPU instruction tracers in a single file Diffs - src/arch/arm/ArmNativeTrace.py 4e09ae443c96 src/arch/sparc/SparcNativeTrace.py 4e09ae443c96 src/arch/x86/X86NativeTrace.py 4e09ae443c96 src/cpu/BaseCPU.py 4e09ae443c96 src/cpu/CPUTracers.py PRE-CREATION src/cpu/ExeTracer.py 4e09ae443c96 src/cpu/IntelTrace.py 4e09ae443c96 src/cpu/NativeTrace.py 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 Diff: http://reviews.gem5.org/r/2559/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2561: sim: Clean up InstRecord
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2561/#review5666 --- src/sim/insttracer.hh http://reviews.gem5.org/r/2561/#comment5053 Yeah, that was always a pain. It made some things a lot harder to debug. src/sim/insttracer.hh http://reviews.gem5.org/r/2561/#comment5054 Capitalization, execution = executing. The wording still makes it a little vague what the polarity of this flag means, but I think I got it. It would be nice if it could be clarified. Should a block style comment like this have anything on its first line? IE /* foo */ vs. /* * foo */ src/sim/insttracer.hh http://reviews.gem5.org/r/2561/#comment5055 void on its own line. I don't think there's much to gain from squishing everything on one line like that. But it's not the end of the world. - Gabe Black On Dec. 10, 2014, 5:55 p.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2561/ --- (Updated Dec. 10, 2014, 5:55 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10610:67236857bfc6 --- sim: Clean up InstRecord Track memory size and flags as well as add some comments and consts. Diffs - src/cpu/base_dyn_inst.hh 4e09ae443c96 src/cpu/exetrace.cc 4e09ae443c96 src/cpu/inorder/resources/cache_unit.cc 4e09ae443c96 src/cpu/minor/lsq.cc 4e09ae443c96 src/cpu/simple/atomic.cc 4e09ae443c96 src/cpu/simple/timing.cc 4e09ae443c96 src/sim/insttracer.hh 4e09ae443c96 Diff: http://reviews.gem5.org/r/2561/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2562: arm: always set the IsFirstMicroop flag
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2562/#review5668 --- Ship it! Ship It! - Gabe Black On Dec. 10, 2014, 5:56 p.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2562/ --- (Updated Dec. 10, 2014, 5:56 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10611:1fd5aa3c4669 --- arm: always set the IsFirstMicroop flag While the IsFirstMicroop flag exists it was only occasionally used in the ARM instructions that gem5 microOps and therefore couldn't be relied on to be correct. Diffs - src/arch/arm/insts/macromem.cc 4e09ae443c96 src/arch/arm/isa/templates/mem.isa 4e09ae443c96 src/arch/arm/isa/templates/mem64.isa 4e09ae443c96 src/cpu/static_inst.hh 4e09ae443c96 Diff: http://reviews.gem5.org/r/2562/diff/ Testing --- Thanks, Ali Saidi ___ 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)
I was testing this on both Intel and AMD platforms. The new code does seem to work for Intel platforms. The new code also seems to clean up a bunch of runtime warnings I was getting on AMD platforms. However the new code on AMD is either much slower, or it is stuck in a loop. A test that runs for 30 sec with the old code is running for more than 10 mins, and still has a long way to go. On Wed, Dec 10, 2014 at 12:27 PM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: That's not actually extending the TSS limit, that's what it works out to be with the granularity bit set. The AM and WP bits were set to the wrong thing according to the comments next to them I'm pretty sure. If we wanted the other behavior, we might be able to change them back and have it work. The _BASE registers hold the base of segments as they're specified by the ISA. The _EFF_BASE registers hold the base that will actually be used in address calculations based on the mode of the CPU. For instance, if you're in 64 bit mode, the _BASE of DS might still be 0xFFF from when you were in another mode. The _EFF_BASE would be 0 though, since the DS base is ignored in that case. _EFF_BASE may not be used by the KVM CPU, but it should be set up anyway in case we switch back to a regular CPU. Gabe On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Thank you for all the clarifications. I see that for SE to work on vmx the TSS limit had to be extended, am and wp bits in CR0 had to be reset and *_EFF_BASE registers had be set in addition to *_BASE registers for TR TSG IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR register (which gets passed to kvm) are the same if with or without *_EFF_BASE registers set. Thank you, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Wednesday, December 10, 2014 1:21 AM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) Ok, I got SE working too. I'll clean up my patch and send that out in a bit. Gabe On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black gabebl...@google.com wrote: I figured out what the other problem was, so here's the review. http://reviews.gem5.org/r/2557/ Gabe On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black gabebl...@google.com wrote: It was attached in my sent mail. Maybe it's being blocked by something? I'm hunting down another problem so I don't want to move my tree around too much, but once that's done I'll post it as a review. Gabe On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: I haven't received any attachment to your email. So I don't have your patch. Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:42 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) And... it turns out the KVM change wasn't necessary. If you're working from my patch, get rid of where the segment limit is divided by PageBytes. That was only necessary because I wasn't adding 0xFFF to the limit when the granularity bit was set. Gabe On Tue, Dec 9, 2014 at 4:31 PM, Gabe Black gabebl...@google.com wrote: Oh, also segment limits weren't being computed correctly in the installSegDesc function, although I don't think that was from the KVM stuff. Once it was fixed it required adjusting the KVM stuff a little, though. Gabe On Tue, Dec 9, 2014 at 4:29 PM, Gabe Black gabebl...@google.com wrote: Here is my patch so far. There were a few things wrong, although I didn't really keep notes. The limits were mixed up, the long mode bit was set on all descriptors when it's only valid for the code segment, privilege level 0 is the OS and 3 is for applications and not the other way around, and I think the type was being set wrong for one of the segments. Also, the syscall and sysenter registers (star and friends) require the segments in the GDT to be in a particular order which I don't think they were. Gabe On Tue, Dec 9, 2014 at 4:22 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: So, I am doing this on an AMD system and I have SE working and am able to get FS entering into virtualized mode. However, in FS I get an early exception while the kernel is booting. This seems a bit different from what Nilay and Adrian observed for FS. Could you please share the diffs that got FS working? Thanks, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:07 PM
Re: [gem5-dev] Review Request 2560: cpu: Remove all notion that we know when the cpu is misspeculating.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2560/#review5669 --- Ship it! Interesting, I had no idea all that was still in there... good to see it go. - Steve Reinhardt On Dec. 10, 2014, 9:55 a.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2560/ --- (Updated Dec. 10, 2014, 9:55 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10609:afab72978b08 --- cpu: Remove all notion that we know when the cpu is misspeculating. We have no way of knowing if a CPU model is on the wrong path with our execute-in-execute CPU models. Don't pretend that we do. Diffs - src/arch/alpha/ev5.cc 4e09ae443c96 src/arch/alpha/faults.cc 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 src/cpu/checker/thread_context.hh 4e09ae443c96 src/cpu/exetrace.hh 4e09ae443c96 src/cpu/exetrace.cc 4e09ae443c96 src/cpu/inorder/thread_context.hh 4e09ae443c96 src/cpu/inteltrace.hh 4e09ae443c96 src/cpu/nativetrace.hh 4e09ae443c96 src/cpu/o3/thread_context.hh 4e09ae443c96 src/cpu/simple/base.hh 4e09ae443c96 src/cpu/simple_thread.hh 4e09ae443c96 src/cpu/thread_context.hh 4e09ae443c96 src/sim/faults.cc 4e09ae443c96 src/sim/insttracer.hh 4e09ae443c96 Diff: http://reviews.gem5.org/r/2560/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2558: cpu: remove legion tracer
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2558/#review5670 --- Ship it! Ship It! - Steve Reinhardt On Dec. 10, 2014, 9:54 a.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2558/ --- (Updated Dec. 10, 2014, 9:54 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10607:39f916f824c2 --- cpu: remove legion tracer If someone wants to debug with legion again they can restore the code from the repository, but no need to have it hang around indefinately. Diffs - src/cpu/LegionTrace.py 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 src/cpu/base.hh 4e09ae443c96 src/cpu/base.cc 4e09ae443c96 src/cpu/legiontrace.hh 4e09ae443c96 src/cpu/legiontrace.cc 4e09ae443c96 src/cpu/m5legion_interface.h 4e09ae443c96 src/cpu/simple/atomic.cc 4e09ae443c96 src/cpu/simple/timing.cc 4e09ae443c96 Diff: http://reviews.gem5.org/r/2558/diff/ Testing --- Thanks, Ali Saidi ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2559: cpu: Put all CPU instruction tracers in a single file
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2559/#review5671 --- Ship it! Might want to update the commit message to clarify that you're just talking about the python files, not the C++ - Steve Reinhardt On Dec. 10, 2014, 9:54 a.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2559/ --- (Updated Dec. 10, 2014, 9:54 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10608:e4487b2cc58c --- cpu: Put all CPU instruction tracers in a single file Diffs - src/arch/arm/ArmNativeTrace.py 4e09ae443c96 src/arch/sparc/SparcNativeTrace.py 4e09ae443c96 src/arch/x86/X86NativeTrace.py 4e09ae443c96 src/cpu/BaseCPU.py 4e09ae443c96 src/cpu/CPUTracers.py PRE-CREATION src/cpu/ExeTracer.py 4e09ae443c96 src/cpu/IntelTrace.py 4e09ae443c96 src/cpu/NativeTrace.py 4e09ae443c96 src/cpu/SConscript 4e09ae443c96 Diff: http://reviews.gem5.org/r/2559/diff/ Testing --- Thanks, Ali Saidi ___ 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)
Thanks for the clarification, actually WP needs to be reset for CPU switching to work properly. I think it is better to leave alignment check off for SE mode as there is no handler in place for unaligned access exception. 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 2:28 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) That's not actually extending the TSS limit, that's what it works out to be with the granularity bit set. The AM and WP bits were set to the wrong thing according to the comments next to them I'm pretty sure. If we wanted the other behavior, we might be able to change them back and have it work. The _BASE registers hold the base of segments as they're specified by the ISA. The _EFF_BASE registers hold the base that will actually be used in address calculations based on the mode of the CPU. For instance, if you're in 64 bit mode, the _BASE of DS might still be 0xFFF from when you were in another mode. The _EFF_BASE would be 0 though, since the DS base is ignored in that case. _EFF_BASE may not be used by the KVM CPU, but it should be set up anyway in case we switch back to a regular CPU. Gabe On Wed, Dec 10, 2014 at 10:20 AM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: Thank you for all the clarifications. I see that for SE to work on vmx the TSS limit had to be extended, am and wp bits in CR0 had to be reset and *_EFF_BASE registers had be set in addition to *_BASE registers for TR TSG IDTR. I wonder what is TR_EFF_BASE. It seems that the contents of TR register (which gets passed to kvm) are the same if with or without *_EFF_BASE registers set. Thank you, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Wednesday, December 10, 2014 1:21 AM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) Ok, I got SE working too. I'll clean up my patch and send that out in a bit. Gabe On Tue, Dec 9, 2014 at 9:41 PM, Gabe Black gabebl...@google.com wrote: I figured out what the other problem was, so here's the review. http://reviews.gem5.org/r/2557/ Gabe On Tue, Dec 9, 2014 at 5:00 PM, Gabe Black gabebl...@google.com wrote: It was attached in my sent mail. Maybe it's being blocked by something? I'm hunting down another problem so I don't want to move my tree around too much, but once that's done I'll post it as a review. Gabe On Tue, Dec 9, 2014 at 4:51 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: I haven't received any attachment to your email. So I don't have your patch. Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:42 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs Intel) And... it turns out the KVM change wasn't necessary. If you're working from my patch, get rid of where the segment limit is divided by PageBytes. That was only necessary because I wasn't adding 0xFFF to the limit when the granularity bit was set. Gabe On Tue, Dec 9, 2014 at 4:31 PM, Gabe Black gabebl...@google.com wrote: Oh, also segment limits weren't being computed correctly in the installSegDesc function, although I don't think that was from the KVM stuff. Once it was fixed it required adjusting the KVM stuff a little, though. Gabe On Tue, Dec 9, 2014 at 4:29 PM, Gabe Black gabebl...@google.com wrote: Here is my patch so far. There were a few things wrong, although I didn't really keep notes. The limits were mixed up, the long mode bit was set on all descriptors when it's only valid for the code segment, privilege level 0 is the OS and 3 is for applications and not the other way around, and I think the type was being set wrong for one of the segments. Also, the syscall and sysenter registers (star and friends) require the segments in the GDT to be in a particular order which I don't think they were. Gabe On Tue, Dec 9, 2014 at 4:22 PM, Dutu, Alexandru via gem5-dev gem5-dev@gem5.org wrote: So, I am doing this on an AMD system and I have SE working and am able to get FS entering into virtualized mode. However, in FS I get an early exception while the kernel is booting. This seems a bit different from what Nilay and Adrian observed for FS. Could you please share the diffs that got FS working? Thanks, Alex -Original Message- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black via gem5-dev Sent: Tuesday, December 09, 2014 6:07 PM To: gem5 Developer List Subject: Re: [gem5-dev] x86 SE kvm functionality (AMD vs
Re: [gem5-dev] Review Request 2561: sim: Clean up InstRecord
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2561/#review5672 --- Ship it! Ship It! - Steve Reinhardt On Dec. 10, 2014, 9:55 a.m., Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2561/ --- (Updated Dec. 10, 2014, 9:55 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10610:67236857bfc6 --- sim: Clean up InstRecord Track memory size and flags as well as add some comments and consts. Diffs - src/cpu/base_dyn_inst.hh 4e09ae443c96 src/cpu/exetrace.cc 4e09ae443c96 src/cpu/inorder/resources/cache_unit.cc 4e09ae443c96 src/cpu/minor/lsq.cc 4e09ae443c96 src/cpu/simple/atomic.cc 4e09ae443c96 src/cpu/simple/timing.cc 4e09ae443c96 src/sim/insttracer.hh 4e09ae443c96 Diff: http://reviews.gem5.org/r/2561/diff/ Testing --- Thanks, Ali Saidi ___ 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.
--- 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] Review Request 2557: x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs.
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.
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. 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 --- 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
