a repository of test code that might be useful?
Finally, I agree that a CI system that could automatically run regressions
when a patch was posted would be a huge improvement from where we are
today.
Thanks,
Ali
On 12/4/14, 7:56 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote:
What I'd like
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
This is somewhat tangential, but are you saying the simulator is
multithreaded now? Or just your simulation?
Gabe
On Thu, Dec 4, 2014 at 10:03 AM, Andreas Sandberg via gem5-dev
gem5-dev@gem5.org wrote:
On 04/12/14 16:10, Nilay Vaish via gem5-dev wrote:
I have been trying to run ht kvm cpu
.
--
Nilay
On Thu, 4 Dec 2014, Gabe Black via gem5-dev wrote:
This is somewhat tangential, but are you saying the simulator is
multithreaded now? Or just your simulation?
Gabe
On Thu, Dec 4, 2014 at 10:03 AM, Andreas Sandberg via gem5-dev
gem5-dev@gem5.org wrote:
On 04/12/14 16:10, Nilay
On Dec. 2, 2014, 5:44 a.m., Steve Reinhardt wrote:
src/arch/isa_parser.py, line 1994
http://reviews.gem5.org/r/2505/diff/2/?file=42744#file42744line1994
it would be nice to update this variable name too ('case_list'?)
Gabe Black wrote:
How about decode_vals? I'm open to
changeset 7734249c92b9 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=7734249c92b9
description:
arch: Allow named constants as decode case values.
The values in a bitfield or in an ExtMachInst structure member may
not be a
literal value, it might
changeset 4fdc929c0aaa in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=4fdc929c0aaa
description:
config: Add two options for setting the kernel command line.
Both options accept template which will, through python string
formatting,
have mem, disk,
On Dec. 4, 2014, 4:01 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.hh, line 157
http://reviews.gem5.org/r/2538/diff/1/?file=42808#file42808line157
a comment here like '// size of cache in bytes' would be nice just to
be clear (and since that has changed)
Fixed.
- Gabe
changeset 25ecfc14f73f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=25ecfc14f73f
description:
misc: Make the GDB register cache accessible in various sized chunks.
Not all ISAs have 64 bit sized registers, so it's not always very
convenient
to
changeset 1eec33d2fc52 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1eec33d2fc52
description:
cpu: Only check for PC events on instruction boundaries.
Only the instruction address is actually checked, so there's no need to
check
repeatedly while
On Dec. 4, 2014, 6:59 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.hh, line 118
http://reviews.gem5.org/r/2540/diff/1/?file=42812#file42812line118
I'd be tempted to rename the other Event class rather than have to
disambiguate here, but I understand if you don't want to be
On Dec. 4, 2014, 6:50 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.cc, line 2
http://reviews.gem5.org/r/2540/diff/1/?file=42813#file42813line2
date?
Fixed.
On Dec. 4, 2014, 6:50 p.m., Steve Reinhardt wrote:
src/base/remote_gdb.cc, line 255
changeset bd68c6838b9f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=bd68c6838b9f
description:
sim: Ensure GDB interrupts the simulation at an instruction boundary.
Use the comInstEventQueue to ensure GDB interrupts the simulation at an
instruction
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2554/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2555/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2542/
---
(Updated Dec. 5, 2014, 10:45 a.m.)
Review request for Default.
Repository: gem5
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2542/
---
(Updated Dec. 5, 2014, 10:46 a.m.)
Review request for Default.
Repository: gem5
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2556/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
changeset 3d7653a2538b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3d7653a2538b
description:
misc: Rename the GDB Event event class to InputEvent.
The Event name is the same as the base event class. That's a bit
confusing,
and makes it a little
changeset 910fc5624d68 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=910fc5624d68
description:
misc: Add some utility functions for schedule inst commit events.
These can be used to simplify the implementation of single step in
derived
classes.
changeset e60c7758cf69 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=e60c7758cf69
description:
x86: Implement a remote GDB stub.
This stub should allow remote debugging of 32 bit and 64 bit targets.
Single
stepping seems to work, as do breakpoints.
changeset 6efb37480d87 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=6efb37480d87
description:
misc: Generalize GDB single stepping.
The new single stepping implementation for x86 doesn't rely on any ISA
specific properties or functionality. This
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
On Dec. 8, 2014, 2:36 p.m., Andreas Hansson wrote:
src/cpu/kvm/vm.cc, line 374
http://reviews.gem5.org/r/2510/diff/2/?file=42734#file42734line374
I think this causes problems with some of the officially supported
compilers. It's just a hunch, but please check.
Ugh. Yes, I think
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
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
(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
.
--
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
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
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
. 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
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
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/#review5659
---
Posted for reference, don't review yet.
- Gabe Black
On Dec. 10,
: 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
changeset 8fc6e7a835d1 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8fc6e7a835d1
description:
Let other objects set up memory like regions in a KVM VM.
diffstat:
src/cpu/kvm/vm.cc | 80 --
src/cpu/kvm/vm.hh |
On Dec. 8, 2014, 2:36 p.m., Andreas Hansson wrote:
src/cpu/kvm/vm.cc, line 374
http://reviews.gem5.org/r/2510/diff/2/?file=42734#file42734line374
I think this causes problems with some of the officially supported
compilers. It's just a hunch, but please check.
Gabe Black
On Nov. 19, 2014, 3:33 p.m., Andreas Sandberg wrote:
The change itself makes sense, but I'd really prefer if we could avoid
conditional compilation and use a kvm-agnostic interface to handle device
memory. See my reply in the email thread for RB #2513.
Consider this a ship it if it
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
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
---
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
---
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,
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
---
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
---
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
---
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
---
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
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
Hi Randolf. I'm not familiar with the multiboot patches, but yes, secondary
(AP) CPUs make a brief trip through real mode and 32 bit mode on their way
to 64 bit mode, and we simulate that.
The ELF loader in SE mode predates me, but I've always thought it tried too
hard to identify what was what
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
Hi folks. This is mostly addressed to people up on fancy new language
features. Back when I implemented the BitUnion stuff, I discovered that
there was an annoying and serious bug which resulted from a limitation of
C++. At the time, I think I saw that the missing feature would become
available in
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2565/#review5683
---
src/arch/arm/decoder.hh
http://reviews.gem5.org/r/2565/#comment5056
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2567/#review5684
---
While it's definitely nice to get these into regular C++ instead of the
It sounds like from this:
http://www.informit.com/guides/content.aspx?g=cplusplusseqNum=556
and this:
http://stackoverflow.com/questions/10693913/c11-anonymous-union-with-non-trivial-members
it might now be fixable if we're using C++11. Are we?
Gabe
On Fri, Dec 12, 2014 at 12:41 AM, Gabe
] 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
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2563/#review5685
---
I didn't see anything that seemed wrong, but I don't know anything about
I tried reverting this change and it fixes the undefined instruction
exceptions I was seeing. It does break KVM in SE mode though, so we
probably shouldn't yank it out entirely. We need to find a minimal version
of that change which makes KVM in SE work without breaking other things.
Gabe
On
.
On Sun, Dec 14, 2014 at 9:53 PM, Gabe Black via gem5-dev
gem5-dev@gem5.org
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
Yeah, I'm not sure which way to go. I think broadening the definition of a
pseudo instruction makes sense, but there's a reasonable amount of existing
usage we'd want to update to keep things from being confusing. You might
call the file util_inst? Or if it's in a directory of just instruction
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2583/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2584/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2585/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
I went to add a bitunion unit test, and I found that two of the unittests
don't compile, circletest and cprintftest. I fixed circletest, but
cprintftest still doesn't build.
circletest fix:
http://reviews.gem5.org/r/2583/
bitunion fix:
http://reviews.gem5.org/r/2584/
bitunion unit test:
On Nov. 25, 2014, 10:31 p.m., Nilay Vaish wrote:
What's TLC and CL?
tender loving care and change list
- Gabe
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2519/#review5547
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/
---
(Updated Dec. 17, 2014, 7:27 a.m.)
Review request for Default.
Repository: gem5
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2519/
---
(Updated Dec. 17, 2014, 7:35 a.m.)
Review request for Default.
Repository: gem5
On Nov. 25, 2014, 10:23 p.m., Nilay Vaish wrote:
src/dev/x86/i8042.cc, line 418
http://reviews.gem5.org/r/2519/diff/1/?file=42718#file42718line418
We don't need this nack().
I changed the panic to a warn and left the nack in.
On Nov. 25, 2014, 10:23 p.m., Nilay Vaish wrote:
These VNC/KVM changes are still pending:
http://reviews.gem5.org/r/2514/
http://reviews.gem5.org/r/2511/
http://reviews.gem5.org/r/2517/ (marked ship it)
http://reviews.gem5.org/r/2518/
http://reviews.gem5.org/r/2519/
http://reviews.gem5.org/r/2520/ (marked ship it)
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/
---
(Updated Dec. 17, 2014, 7:39 a.m.)
Review request for Default.
Repository: gem5
I tried to upload these patches to review board but it kept giving me this:
abort: The file was not found in the repository (207)
stat: fail
file: src/arch/x86/cpuid.cc
One is a revert of the original CPUID patch, and the second is a new patch
which enables just a few feature bits to make SE
Hi folks. I was just thinking about how that CPUID change caused problems
when running ChromeOS, and it occurred to me that it doesn't matter what
gem5 supports when CPUID is run if the host system doesn't support the
features it claims. To be really safe, when running with KVM, we should
report
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/#review5696
---
src/dev/Cirrus.py
http://reviews.gem5.org/r/2511/#comment5087
On Dec. 17, 2014, 1:53 p.m., Andreas Hansson wrote:
src/dev/x86/i8042.hh, line 118
http://reviews.gem5.org/r/2518/diff/2/?file=42731#file42731line118
I know it is not changed, but could you elaborate on the unit?
I'll have to look at it again to figure out what the unit is, but
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2589/#review5698
---
Ship it!
Ship It!
- Gabe Black
On Dec. 19, 2014, 1:20 p.m., Andreas
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2588/#review5699
---
Ship it!
Ship It!
- Gabe Black
On Dec. 19, 2014, 1:18 p.m., Andreas
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2565/#review5703
---
I added a comment to this review, but since the issue had been marked
I complained about those names a long time ago, and I still think they
aren't very good. quick and long aren't really on the same scale, to
start with. Something can be quick (a rate) and still take a long time.
Medium is very generic and so isn't on a different axis, but since the
others aren't
I mean quick, medium, slow, not quick, medium, fast.
On Mon, Dec 22, 2014 at 12:44 PM, Gabe Black gabebl...@google.com wrote:
I complained about those names a long time ago, and I still think they
aren't very good. quick and long aren't really on the same scale, to
start with. Something can
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2590/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2591/
---
Review request for Default.
Repository: gem5
Description
---
Changeset
On Dec. 18, 2014, 10:39 a.m., Gabe Black wrote:
src/dev/cirrus.hh, line 48
http://reviews.gem5.org/r/2511/diff/6/?file=43227#file43227line48
They probably shouldn't be. I'll fix that.
These default to private, but I'll make that explicit.
- Gabe
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/
---
(Updated Dec. 23, 2014, 1:04 a.m.)
Review request for Default.
Repository: gem5
On Dec. 23, 2014, 5:19 a.m., Steve Reinhardt wrote:
Fine with me, assuming that our implementations of those features are
indeed complete.
They aren't, but I think the bits that are missing will trigger warnings.
- Gabe
---
This
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2590/#review5712
---
bump
- Gabe Black
On Dec. 23, 2014, 12:37 a.m., Gabe Black wrote:
I'm still waiting for reviews on my bituion fix, unittest, and my fix
compilation fix for the circletest unittest.
Also the cprintftest unittest still won't compile, unless someone slipped
in a fix while I wasn't looking. I think that's likely from a change
Andreas did changing how varargs are
On Dec. 23, 2014, 10:25 a.m., Andreas Hansson wrote:
Looks fine. Could you mark the issues that are fixed as fixed (or dropped
for that matter)?
Thanks.
I am still not sure if I like the USE_KVM better, or perhaps having a
NullKvm object.
Yeah. There was one other mistake I
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2585/
---
(Updated Dec. 26, 2014, 9:32 p.m.)
Review request for Default.
Repository: gem5
In the x86 decoder, some architectural state (CPU mode, a couple other
things) is used to pick an active decode cache from a hash map of caches.
That state could then be used when decoding instructions since we'd still
always get the same thing for a particular ExtMachInst given a particular
I realize the context for this might not be something everybody is familiar
with. If you need me to explain what this is about more I can do that.
Gabe
On Wed, Feb 4, 2015 at 2:23 PM, Gabe Black gabebl...@google.com wrote:
In the x86 decoder, some architectural state (CPU mode, a couple other
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2642/#review5862
---
Ship it!
Ship It!
- Gabe Black
On Feb. 6, 2015, 10:07 p.m., Brandon
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2604/#review5755
---
This will break GDB single stepping.
- Gabe Black
On Jan. 14, 2015,
On Jan. 16, 2015, 12:44 a.m., mike upton wrote:
src/arch/x86/regs/misc.hh, line 922
http://reviews.gem5.org/r/2557/diff/2/?file=42949#file42949line922
really 32, 0 in the new code?
Yeah, I think that should be 31, 0
- Gabe
On Jan. 16, 2015, 11:56 p.m., mike upton wrote:
src/arch/x86/process.cc, lines 212-213
http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line212
when limitHigh and limitLow get set by dataSegDesc(), it seems that
limitHigh and limitLow get reversed.
This patch
On Jan. 16, 2015, 11:28 p.m., mike upton wrote:
src/arch/x86/utility.hh, line 219
http://reviews.gem5.org/r/2557/diff/2/?file=42952#file42952line219
Is there a reason the desc.l does not get set for the dataSegDesc()?
code sets p,l,d,g,s.
Yes. The long mode bit only means
It sounds like a bug/race condition in the O3 CPU, which I think you
already knew. You could try moving the suspend call into a fault returned
by the MicroHalt microop instead of the instruction itself. That might
break the race, although it's not really fixing the issue with O3.
Gabe
On Tue,
On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
src/arch/x86/process.cc, lines 218-237
http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line218
For AMD systems, the sys descriptors need to come first. On intel
systems they need to come second.
I do not know
On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
src/arch/x86/process.cc, lines 218-237
http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line218
For AMD systems, the sys descriptors need to come first. On intel
systems they need to come second.
I do not know
On Jan. 14, 2015, 8:52 p.m., Gabe Black wrote:
This will break GDB single stepping.
Nikos Nikoleris wrote:
If I undestand correctly, it won't be affected. When set, the GDB single
step schedules the corresponding event at the comInstEventQueue. The
comInstEventQueue services
I'd like to remove the ExtMachInst concept from gem5, or at least hide it
within the ISAs that need it. The only place where it isn't obvious how to
do that is in the Minor cpu where it treats the ExtMachInst as a 64 bit
integer (!) and masks it against a bit mask (!) to see when certain
need to have any additional state in ExtMachInst
relative to the MachInst object. If you end up going that direction,
though, what's the advantage of eliminating ExtMachInst vs. just defining
ExtMachInst == MachInst for that ISA?
Steve
On Wed, Feb 11, 2015 at 4:52 PM, Gabe Black via gem5-dev
101 - 200 of 512 matches
Mail list logo
