date:20170125

Re: [gem5-dev] Bug in x86 stack instructions

2017-01-25 Thread Gabe Black

As far as explicitly vs. implicitly using the stack segment, I wasn't able
to find a very conclusive answer while looking through the manuals. This
would be something to check by running a little test program on an actual
computer, although I suspect implicit vs. explicit does matter.

One interesting thing I found while looking for that which might be worth
looking into is that instructions which reference rsp or rbp also
implicitly use the stack segment. I remember knowing that, but I don't
remember whether or not gem5 handles that properly.

Unfortunately, we can't really keep track of the effective address size in
the instruction, just whether we should be using the default size or the
alternative size. This is because whether or not we're using the default is
fixed based on the instruction encoding, while how that maps to the actual
address size is based on that and also segmentation state. The decode cache
doesn't (as far as I remember) keep track of that state, so it would
potentially return an instruction which was set up based on now faulty
assumptions.

As far as whether or not AddrSizeFlagBit can be removed entirely,
unfortunately it can't. The problem ultimately stems from the fact that
gem5 assumes that virtual to physical mappings don't change the page
alignment of a memory address. That means that the address that's presented
to the CPU as a virtual address needs to have its potentially non-page
aligned segment base value added into it already, and it has to be a full
width address. For instance, if the data segment for a byte load has a base
of 0x3 and an offset of 0xff8, the linear address (post segmentation
address) you're accessing is going to be 0x1001. As far as the CPU is
concerned the virtual address and the linear address look like they're from
different cache lines and different pages.

When presented to the TLB, the address than has to have the segment base
removed from it again so that the original offset can be checked against
the segment limit values. This gets tricky when the segment is expand down,
since in that case the limit value is actually an effective lower bound,
and the upper bound is either 0x or 0x depending on the size of
the "d" bit in the appropriate segment descriptor. Once you do the
subtraction, you need to know how to truncate the result you get, or sign
extension, carry bits, etc., cause a problem and, if I remember correctly,
cause spurious GP faults.

This could all be simplified if the TLB applied the segment bases, but then
I think that would likely complicate the CPU models significantly.

Gabe

On Wed, Jan 25, 2017 at 1:28 PM, Jason Lowe-Power 
wrote:

> I'm leaning towards deleting the AddrSizeFlagBit. Gabe, can you shed some
> light on the purpose of this flag? It's only ever used for masking
> addresses in the TLB:
> http://grok.gem5.org/xref/gem5/src/arch/x86/tlb.cc#318
> http://grok.gem5.org/xref/gem5/src/arch/x86/tlb.cc#330
>
> From what I can understand, it should be unnecessary to mask the address
> here. In the instruction implementation, the address is already masked if
> it is a 32-bit mode instruction:
> http://grok.gem5.org/xref/gem5/src/arch/x86/isa/microops/ldstop.isa#433
>
> It seems straightforward to add addressSize=ssz to the st instructions
> where necessary. I'm confused as to why the TLB ever needs to know what the
> address mode of the instruction is. Why/how would the TLB ever receive a
> request with an address > 4GB for a 32-bit mode instruction?
>
> Thanks again for the help!
>
> Cheers,
> Jason
>
> On Wed, Jan 25, 2017 at 10:37 AM Steve Reinhardt  wrote:
>
> > Thanks, Gabe! That's all really helpful. I appreciate you taking the time
> > to respond.
> >
> > One concern I have is that the portion of the manual Jason quoted says
> the
> > rule holds "For instructions that
> > *implicitly* access the stack segment (SS)" (emphasis mine)... would you
> > say then that instructions that *explicitly* choose SS as the segment
> > (e.g., with a segment override prefix) would not follow this rule? If so,
> > then it may not be correct to do things inside the instruction based
> solely
> > on the fact that segment==SS. Or maybe that's a case that just can't
> occur
> > so we don't have to worry about it?
> >
> > Also, would there be any harm in setting the AddrSizeFlagBit based on
> > whether addressSize==32 rather than looking at the legacy.addr bit? If
> not,
> > this seems like a simpler solution to me.
> >
> > Thanks again!
> >
> > Steve
> >
> >
> > On Wed, Jan 25, 2017 at 12:41 AM, Gabe Black 
> wrote:
> >
> > > Forgive me if I'm repeating a bit of what you said, Steve, but I
> looked a
> > > little more and there's more to fix.
> > >
> > > Also, if you look at x86/isa/microops/ldstop.isa, you'll find the
> python
> > > classes which receive the parameters of the load and store microops and
> > > translate them into C++ instantiations of the underlying

Re: [gem5-dev] Compilation error for gem5 after statfs change

2017-01-25 Thread Jason Lowe-Power

Yeah, it's a major problem that we say that we support macOS and others
when we allow commits that break builds on these other OSes.

If we are going to say that we have support for OSes other than Linux, we
need to at least verify gem5 builds on these OSes, preferably before
accepting a commit. I'm currently testing out the free Travis-CI service (
https://travis-ci.org/powerjg/gem5-ci-test). We could probably hook this up
to our gem5 github page, if it works out.

Another important point, though, is that we can't expect all committers to
own multiple machines to test their changes on. We need something that will
do pre-commit builds on all the platforms we claim to support.

We're in the middle of moving the regression tests to a hosted jenkins
instance. Hopefully this will solve some of these issues (though I don't
think it will support multiple OS builds).

Do others have any ideas on a long-term solution here?

Cheers,
Jason

On Tue, Jan 24, 2017 at 5:46 PM Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:

On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:

> Hi Brandon,
>
> I think this is a "real" bug:
>
http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-build-arm-gem5-opt
.
> I think there are a few more places that need an #ifdef NO_STATFS.
> Could
> you look into it and post a patch if there's a problem? If not, please
> reply to the gem5 QA post and let them know.

Can people try this one and probably get the #ifdefs right for NetBSD as
well?  There are at least 3 different checks for that code;  if people
don’t care about “style” I could get it right, but ..

diff -r e47703369039 src/sim/syscall_emul.hh
--- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
+++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
@@ -70,6 +70,8 @@
  #include 
  #if (NO_STATFS == 0)
  #include 
+#else
+#include 
  #endif
  #include 
  #include 
@@ -530,20 +532,25 @@
  {
  TypedBufferArg tgt(addr);

+tgt->f_type = TheISA::htog(host->f_type);
  #if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
-tgt->f_type = 0;
+tgt->f_bsize = TheISA::htog(host->f_iosize);
  #else
-tgt->f_type = TheISA::htog(host->f_type);
+tgt->f_bsize = TheISA::htog(host->f_bsize);
  #endif
-tgt->f_bsize = TheISA::htog(host->f_bsize);
  tgt->f_blocks = TheISA::htog(host->f_blocks);
  tgt->f_bfree = TheISA::htog(host->f_bfree);
  tgt->f_bavail = TheISA::htog(host->f_bavail);
  tgt->f_files = TheISA::htog(host->f_files);
  tgt->f_ffree = TheISA::htog(host->f_ffree);
  memcpy(>f_fsid, >f_fsid, sizeof(host->f_fsid));
+#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
+tgt->f_namelen = TheISA::htog(host->f_namemax);
+tgt->f_frsize = TheISA::htog(host->f_bsize);
+#else
  tgt->f_namelen = TheISA::htog(host->f_namelen);
  tgt->f_frsize = TheISA::htog(host->f_frsize);
+#endif
  memcpy(>f_spare, >f_spare, sizeof(host->f_spare));

  tgt.copyOut(mem);
___
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] Bug in x86 stack instructions

2017-01-25 Thread Jason Lowe-Power

I'm leaning towards deleting the AddrSizeFlagBit. Gabe, can you shed some
light on the purpose of this flag? It's only ever used for masking
addresses in the TLB:
http://grok.gem5.org/xref/gem5/src/arch/x86/tlb.cc#318
http://grok.gem5.org/xref/gem5/src/arch/x86/tlb.cc#330

From what I can understand, it should be unnecessary to mask the address
here. In the instruction implementation, the address is already masked if
it is a 32-bit mode instruction:
http://grok.gem5.org/xref/gem5/src/arch/x86/isa/microops/ldstop.isa#433

It seems straightforward to add addressSize=ssz to the st instructions
where necessary. I'm confused as to why the TLB ever needs to know what the
address mode of the instruction is. Why/how would the TLB ever receive a
request with an address > 4GB for a 32-bit mode instruction?

Thanks again for the help!

Cheers,
Jason

On Wed, Jan 25, 2017 at 10:37 AM Steve Reinhardt  wrote:

> Thanks, Gabe! That's all really helpful. I appreciate you taking the time
> to respond.
>
> One concern I have is that the portion of the manual Jason quoted says the
> rule holds "For instructions that
> *implicitly* access the stack segment (SS)" (emphasis mine)... would you
> say then that instructions that *explicitly* choose SS as the segment
> (e.g., with a segment override prefix) would not follow this rule? If so,
> then it may not be correct to do things inside the instruction based solely
> on the fact that segment==SS. Or maybe that's a case that just can't occur
> so we don't have to worry about it?
>
> Also, would there be any harm in setting the AddrSizeFlagBit based on
> whether addressSize==32 rather than looking at the legacy.addr bit? If not,
> this seems like a simpler solution to me.
>
> Thanks again!
>
> Steve
>
>
> On Wed, Jan 25, 2017 at 12:41 AM, Gabe Black  wrote:
>
> > Forgive me if I'm repeating a bit of what you said, Steve, but I looked a
> > little more and there's more to fix.
> >
> > Also, if you look at x86/isa/microops/ldstop.isa, you'll find the python
> > classes which receive the parameters of the load and store microops and
> > translate them into C++ instantiations of the underlying microop classes.
> > In their __init__ methods, you'll see at the end where the
> AddrSizeFlagBit
> > is set based on whether or not the machInst.legacy.addr bit is set,
> > basically whether the address size prefix had been found when the
> > instruction was decoded. For the two classes involved (LdStOp and
> > BigLdStOp), I think you'll want to add a check which doesn't set
> > AddrSizeFlagBit if the segment is the stack segment.
> >
> > Additionally, you'll want to make sure the TLB knows to use the stack
> > segment size (as opposed to either the default or alternate address
> sizes)
> > when manipulating the segment offset. You could add a new ISA specific
> flag
> > for x86 memory requests (there seems to be room for exactly one more in
> > arch/x86/ldstflags.hh) and set it if the segment is the stack in those ld
> > and st ops, similar to how AddrSizeFlagBit is being set. Then in the TLB,
> > specifically where it's calculating logSize, you'll want to make it
> > recognize your new flag and use the stack size from the m5Reg (called
> just
> > m5Reg.stack, I think) instead of either of the address size values.
> >
> > This is a little gross because it means there's some calculation going on
> > when address translation is being done (frequently) when it could have
> been
> > done earlier during decode (less frequently). One reason I did things
> this
> > way (all speculation, I've long since forgot) is that it makes the
> decoded
> > instructions hold less state. The same bytes may not always refer to the
> > same sizes depending on the segmentation state in the machine, so if
> those
> > particular bytes are being decoded, the gem5 decode cache needs to either
> > consider that segmentation state when deciding what instruction to spit
> > out. If it didn't, it might return an instruction which statically says
> to
> > use 32 bit addresses (for instance), when now segmentation state says it
> > the same bytes should mean it should use 16 bit addresses. Instead, it
> canh
> > be factored in dynamically using external state (the m5Reg) to an
> > instruction that says which version of the sizes to use but doesn't care
> > what values those actually map to at that moment.
> >
> > Gabe
> >
> > On Wed, Jan 25, 2017 at 12:03 AM, Gabe Black 
> wrote:
> >
> > > Hi. I think you guys are generally interpreting this code correctly,
> but
> > > I'll throw in my two cents. If you look at the pseudo code here:
> > >
> > > http://www.felixcloutier.com/x86/CALL.html
> > >
> > > then it appears that the size of the return address you push onto the
> > > stack should be based on the operand size, ie. the data size. That
> would
> > > mean that the displacement for the store should be -env.dataSize like
> it
> > > is. By the same logic, the

Re: [gem5-dev] Review Request 3791: dev: net/i8254xGBe add two more wakeup registers to ignore

2017-01-25 Thread Tony Gutierrez


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

Ship it!


Ship It!

- Tony Gutierrez


On Jan. 25, 2017, 3:28 a.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3791/
> ---
> 
> (Updated Jan. 25, 2017, 3:28 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> There are drivers writing to WUFC uncondtionally of anything.  In order to 
> not panic gem5 in these cases, ignore writes to WUFC and WUS as we do for 
> WUC.  Similarly return 0 (default reset value) on reads.
> 
> 
> Diffs
> -
> 
>   src/dev/net/i8254xGBe.cc e47703369039 
>   src/dev/net/i8254xGBe_defs.hh e47703369039 
> 
> Diff: http://reviews.gem5.org/r/3791/diff/
> 
> 
> Testing
> ---
> 
> Booted in FS with such a driver revision which would previously panic and now 
> boots fine.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

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

Re: [gem5-dev] Ideas for sprint projects

2017-01-25 Thread Andreas Hansson

Hi all,

A large-sized project for some crafty person out there: A
binary-translation CPU for fast-forwarding, much like the KVMCpu, but more
portable. It could, for example, be built on top of the Tiny Code
Generator (TCG), as it is BSD licensed.

Quite a big task, but also a very big contribution to gem5.

Andreas

On 23/01/2017, 16:57, "gem5-dev on behalf of Andreas Hansson"
 wrote:

>Hi all,
>
>Another medium-sized idea: Embed the generated system SVG in a web page
>that can be used to interactively navigate the simulation results
>
>This should be fairly easy for anyone skilled in client-side scripting. It
>may even be used to view incremental results while the simulation is
>running.
>
>Andreas
>
>On 23/01/2017, 15:57, "gem5-dev on behalf of Andreas Sandberg"
> wrote:
>
>>Hi Everyone,
>>
>>Thanks for organising this! See below for some of my ideas.
>>
>>Small projects:
>>   * Clean up serialization code for better code reuse (particularly
>>container helpers)
>>   * Create a separate test classification for CI smoke tests (faster
>>than quick)
>>
>>Medium-sized projects:
>>   * New test binaries based on the LLVM test suite
>>   * Mini-DSL for param overrides from the command line
>>   * Config cleanups. E.g., move some of config/common/ to a m5.config
>>name space.
>>   * Proper support for pthreads in SE mode
>>   * Implement a fast mode in the HDLCD controller to support graphical
>>worklaods (e.g., Android) in KVM
>>
>>Large projects:
>>   * Get scons to build basic components only once and share them
>>between architectures
>>
>>
>>I'd like to throw cmake in to the build system mix as well. I started
>>hacking on a small prototype a while back, but it isn't able to build
>>gem5 yet.
>>
>>
>>Cheers,
>>Andreas
>>
>>
>>On 17/01/17 16:12, Jason Lowe-Power wrote:
>>> Hi gem5 Developers!
>>>
>>> As you're probably aware, I'm going to be running a gem5 coding sprint
>>>in
>>> the afternoon after the Learning gem5 tutorial at HPCA on Sunday Feb 5.
>>>
>>> I'm looking for ideas for small projects that could be started (or even
>>> better, completed) in a few hours. Do you have any small bugs that have
>>> been bothering you? Any little features that would be nice, but you
>>>haven't
>>> had the time to work on? Now's the time to get these things done!
>>>
>>> Also, if you have any bigger projects that you think it would be good
>>>for
>>> people to chat about in the same room to come up with a plan of attack,
>>>we
>>> may be able to fit one or two of those in, too.
>>>
>>> Some examples that I have so far:
>>>
>>> Little projects:
>>> 1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/)
>>> 2. Modify EventWrapper to understand C++11 lambdas so you can pass
>>> parameters to simple process() functions without creating a new class.
>>> 3. Develop some ISA instruction tests to find out what is implemented
>>> correctly and possibly find some bugs. (See RISC-V insttest)
>>>
>>> Long-term things we may want to discuss:
>>> 1. Revamping the test infrastructure
>>> 2. Replacing scons, possibly with Bazel (see https://bazel.build/)
>>>
>>> Please respond with any ideas you have! We definitely won't get to
>>> everything, but throwing ideas out there now will give us a large base
>>>of
>>> options for the coding sprint.
>>>
>>> Thanks,
>>> Jason
>>
>>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.
>>___
>>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.
>___
>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.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3773: ruby: PerfectSwitch add assured access arbitration

2017-01-25 Thread Brad Beckmann


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

Ship it!


Ship It!

- Brad Beckmann


On Jan. 25, 2017, 6:49 a.m., Joel Hestness wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3773/
> ---
> 
> (Updated Jan. 25, 2017, 6:49 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11802:ca5c5b982ea5
> ---
> ruby: PerfectSwitch add assured access arbitration
> 
> When operating near bandwidth saturation and using finite cache hierarchy
> buffering, the round-robin arbitration in the PerfectSwitch caused low ID
> input buffers to gain access to the switch more frequently than other input
> buffers that might contain requests. This resulted from the priority cycling
> starting on input buffers with no pending requests and cycling around to the
> low ID buffers with pending requests. Part of the problem was that
> input-to-output port allocation was done on-the-fly while cycling through
> input ports.
> 
> To fix this, refactor the PerfectSwitch to remove on-the-fly arbitration, and
> better delineate port allocation from switch traversal. Then, implement
> cycling-priority assured access arbitration using output port request batches
> to ensure that all input ports are given the same priority when buffers are
> full.
> 
> This fix reduces GPU core progress asymmetry from >3x down to <12%, and in
> line with hardware.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/simple/PerfectSwitch.hh cd7f3a1dbf55 
>   src/mem/ruby/network/simple/PerfectSwitch.cc cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3773/diff/
> 
> 
> Testing
> ---
> 
> Extensive testing and use in gem5-gpu. Used GPU to saturate cache hierarchy
> bandwidth, and tracked threadblock progress to witness asymmetry. Repeated
> this testing after the fix to see greatly reduced asymmetry. Also, in these
> small tests, simulator run time improves slightly due to reduced amount of
> work performed by PerfectSwitch arbitration. Also, have run thousands of
> simulations with this patch to verify that the changes work for a wide
> range of simulated system behaviors.
> 
> 
> Thanks,
> 
> Joel Hestness
> 
>

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

Re: [gem5-dev] Bug in x86 stack instructions

2017-01-25 Thread Steve Reinhardt

Thanks, Gabe! That's all really helpful. I appreciate you taking the time
to respond.

One concern I have is that the portion of the manual Jason quoted says the
rule holds "For instructions that
*implicitly* access the stack segment (SS)" (emphasis mine)... would you
say then that instructions that *explicitly* choose SS as the segment
(e.g., with a segment override prefix) would not follow this rule? If so,
then it may not be correct to do things inside the instruction based solely
on the fact that segment==SS. Or maybe that's a case that just can't occur
so we don't have to worry about it?

Also, would there be any harm in setting the AddrSizeFlagBit based on
whether addressSize==32 rather than looking at the legacy.addr bit? If not,
this seems like a simpler solution to me.

Thanks again!

Steve


On Wed, Jan 25, 2017 at 12:41 AM, Gabe Black  wrote:

> Forgive me if I'm repeating a bit of what you said, Steve, but I looked a
> little more and there's more to fix.
>
> Also, if you look at x86/isa/microops/ldstop.isa, you'll find the python
> classes which receive the parameters of the load and store microops and
> translate them into C++ instantiations of the underlying microop classes.
> In their __init__ methods, you'll see at the end where the AddrSizeFlagBit
> is set based on whether or not the machInst.legacy.addr bit is set,
> basically whether the address size prefix had been found when the
> instruction was decoded. For the two classes involved (LdStOp and
> BigLdStOp), I think you'll want to add a check which doesn't set
> AddrSizeFlagBit if the segment is the stack segment.
>
> Additionally, you'll want to make sure the TLB knows to use the stack
> segment size (as opposed to either the default or alternate address sizes)
> when manipulating the segment offset. You could add a new ISA specific flag
> for x86 memory requests (there seems to be room for exactly one more in
> arch/x86/ldstflags.hh) and set it if the segment is the stack in those ld
> and st ops, similar to how AddrSizeFlagBit is being set. Then in the TLB,
> specifically where it's calculating logSize, you'll want to make it
> recognize your new flag and use the stack size from the m5Reg (called just
> m5Reg.stack, I think) instead of either of the address size values.
>
> This is a little gross because it means there's some calculation going on
> when address translation is being done (frequently) when it could have been
> done earlier during decode (less frequently). One reason I did things this
> way (all speculation, I've long since forgot) is that it makes the decoded
> instructions hold less state. The same bytes may not always refer to the
> same sizes depending on the segmentation state in the machine, so if those
> particular bytes are being decoded, the gem5 decode cache needs to either
> consider that segmentation state when deciding what instruction to spit
> out. If it didn't, it might return an instruction which statically says to
> use 32 bit addresses (for instance), when now segmentation state says it
> the same bytes should mean it should use 16 bit addresses. Instead, it canh
> be factored in dynamically using external state (the m5Reg) to an
> instruction that says which version of the sizes to use but doesn't care
> what values those actually map to at that moment.
>
> Gabe
>
> On Wed, Jan 25, 2017 at 12:03 AM, Gabe Black  wrote:
>
> > Hi. I think you guys are generally interpreting this code correctly, but
> > I'll throw in my two cents. If you look at the pseudo code here:
> >
> > http://www.felixcloutier.com/x86/CALL.html
> >
> > then it appears that the size of the return address you push onto the
> > stack should be based on the operand size, ie. the data size. That would
> > mean that the displacement for the store should be -env.dataSize like it
> > is. By the same logic, the subtraction below it should also be
> env.dataSize
> > (symbolically dsz) and not ssz.
> >
> > You are also correct, I think, that since the instruction references the
> > stack segment, it's address size should be set to the stack size when
> doing
> > memory operations. Adding addressSize=ssz to the st microop should do
> that.
> >
> > According to that pseudo code, the size of the target IP is also the
> > operand size, but that's the size the wrip microop will use by default
> and
> > so should be fine as written.
> >
> > I think if you make those two changes (change ssz to dsz in the sub, add
> > addressSize=ssz to the st), then this macroop definition will be correct.
> > It would be worthwhile to check the other definitions of CALL and make
> sure
> > they aren't similarly broken.
> >
> > Gabe
> >
> > On Tue, Jan 24, 2017 at 3:28 PM, Jason Lowe-Power 
> > wrote:
> >
> >> Thanks for helping me work this out.
> >>
> >> I got the binary working by completely removing the AddrSizeFlagBit. The
> >> only place this bit is used is in the LdStOp (it's set to true if

Re: [gem5-dev] Ideas for sprint projects

2017-01-25 Thread Gutierrez, Anthony

Here are some ideas we at AMD have for the sprint.

1) Adding checkpointing support to the GPU model
2) Fixing the structure and design of the GPU coalescer
3) Adding x86 inst tests
4) Properly supporting atomics
5) Add support for event-based scheduling in the GPU model, and FUPool-style 
functional units

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Tuesday, January 17, 2017 8:13 AM
To: gem5 Developer List 
Subject: [gem5-dev] Ideas for sprint projects

Hi gem5 Developers!

As you're probably aware, I'm going to be running a gem5 coding sprint in the 
afternoon after the Learning gem5 tutorial at HPCA on Sunday Feb 5.

I'm looking for ideas for small projects that could be started (or even better, 
completed) in a few hours. Do you have any small bugs that have been bothering 
you? Any little features that would be nice, but you haven't had the time to 
work on? Now's the time to get these things done!

Also, if you have any bigger projects that you think it would be good for 
people to chat about in the same room to come up with a plan of attack, we may 
be able to fit one or two of those in, too.

Some examples that I have so far:

Little projects:
1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/) 2. Modify 
EventWrapper to understand C++11 lambdas so you can pass parameters to simple 
process() functions without creating a new class.
3. Develop some ISA instruction tests to find out what is implemented correctly 
and possibly find some bugs. (See RISC-V insttest)

Long-term things we may want to discuss:
1. Revamping the test infrastructure
2. Replacing scons, possibly with Bazel (see https://bazel.build/)

Please respond with any ideas you have! We definitely won't get to everything, 
but throwing ideas out there now will give us a large base of options for the 
coding sprint.

Thanks,
Jason
-- 

Jason
___
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] Ideas for sprint projects

2017-01-25 Thread Andreas Sandberg


Another small project:

Unify PS/2 handling: PS2 is implemented by both the i8042 and PL050
models, but almost no code is shared.

//Andreas

On 23/01/17 15:57, Andreas Sandberg wrote:

Hi Everyone,

Thanks for organising this! See below for some of my ideas.

Small projects:
  * Clean up serialization code for better code reuse (particularly
container helpers)
  * Create a separate test classification for CI smoke tests (faster
than quick)

Medium-sized projects:
  * New test binaries based on the LLVM test suite
  * Mini-DSL for param overrides from the command line
  * Config cleanups. E.g., move some of config/common/ to a m5.config
name space.
  * Proper support for pthreads in SE mode
  * Implement a fast mode in the HDLCD controller to support graphical
worklaods (e.g., Android) in KVM

Large projects:
  * Get scons to build basic components only once and share them
between architectures


I'd like to throw cmake in to the build system mix as well. I started
hacking on a small prototype a while back, but it isn't able to build
gem5 yet.


Cheers,
Andreas


On 17/01/17 16:12, Jason Lowe-Power wrote:

Hi gem5 Developers!

As you're probably aware, I'm going to be running a gem5 coding
sprint in
the afternoon after the Learning gem5 tutorial at HPCA on Sunday Feb 5.

I'm looking for ideas for small projects that could be started (or even
better, completed) in a few hours. Do you have any small bugs that have
been bothering you? Any little features that would be nice, but you
haven't
had the time to work on? Now's the time to get these things done!

Also, if you have any bigger projects that you think it would be good
for
people to chat about in the same room to come up with a plan of
attack, we
may be able to fit one or two of those in, too.

Some examples that I have so far:

Little projects:
1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/)
2. Modify EventWrapper to understand C++11 lambdas so you can pass
parameters to simple process() functions without creating a new class.
3. Develop some ISA instruction tests to find out what is implemented
correctly and possibly find some bugs. (See RISC-V insttest)

Long-term things we may want to discuss:
1. Revamping the test infrastructure
2. Replacing scons, possibly with Bazel (see https://bazel.build/)

Please respond with any ideas you have! We definitely won't get to
everything, but throwing ideas out there now will give us a large
base of
options for the coding sprint.

Thanks,
Jason


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.
___
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.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3791: dev: net/i8254xGBe add two more wakeup registers to ignore

2017-01-25 Thread Jason Lowe-Power


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

Ship it!


Ship It!

- Jason Lowe-Power


On Jan. 25, 2017, 11:28 a.m., Bjoern A. Zeeb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3791/
> ---
> 
> (Updated Jan. 25, 2017, 11:28 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> There are drivers writing to WUFC uncondtionally of anything.  In order to 
> not panic gem5 in these cases, ignore writes to WUFC and WUS as we do for 
> WUC.  Similarly return 0 (default reset value) on reads.
> 
> 
> Diffs
> -
> 
>   src/dev/net/i8254xGBe.cc e47703369039 
>   src/dev/net/i8254xGBe_defs.hh e47703369039 
> 
> Diff: http://reviews.gem5.org/r/3791/diff/
> 
> 
> Testing
> ---
> 
> Booted in FS with such a driver revision which would previously panic and now 
> boots fine.
> 
> 
> Thanks,
> 
> Bjoern A. Zeeb
> 
>

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

[gem5-dev] Review Request 3791: dev: net/i8254xGBe add two more wakeup registers to ignore

2017-01-25 Thread Bjoern A. Zeeb


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

Review request for Default.


Repository: gem5


Description
---

There are drivers writing to WUFC uncondtionally of anything.  In order to not 
panic gem5 in these cases, ignore writes to WUFC and WUS as we do for WUC.  
Similarly return 0 (default reset value) on reads.


Diffs
-

  src/dev/net/i8254xGBe.cc e47703369039 
  src/dev/net/i8254xGBe_defs.hh e47703369039 

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


Testing
---

Booted in FS with such a driver revision which would previously panic and now 
boots fine.


Thanks,

Bjoern A. Zeeb

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

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

2017-01-25 Thread Andreas Sandberg


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

Ship it!


Ship It!

- Andreas Sandberg


On Jan. 24, 2017, 4:33 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3781/
> ---
> 
> (Updated Jan. 24, 2017, 4:33 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11796:1c03f7dcaa8c
> ---
> riscv: Remove ECALL tests from insttest
> 
> The system calls tested in rv64i.cpp in RISC-V's insttest suite have
> different behavior depending on the operating system and file system they
> are run on. This patch removes those tests from the regression.
> 
> [Change deletion of ECALL test to block comment.]
> [Restore ECALL test but remove test output to test only for completion
> without error.]
> 
> 
> Diffs
> -
> 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/stats.txt 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.ini
>  97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.json
>  97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simout 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/stats.txt 
> 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3781/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alec Roelke
> 
>

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

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

2017-01-25 Thread Andreas Sandberg



> On Jan. 24, 2017, 9:43 a.m., Andreas Sandberg wrote:
> > Did you remove all files from the reference output directory? In that case, 
> > you'll need to add a an empty placeholder file called EMPTY in the 
> > reference directories. Some VCS systems (git being one of them) don't track 
> > empty directories, which would interfere with test discovery.
> 
> Alec Roelke wrote:
> I did add them; I'm not sure why it didn't put them into the patch.  Does 
> the file need to contain text for it to work?

It isn't a problem for the VCS, but it might be for ReviewBoard. Don't worry 
about it if the files show up in the patch.


- Andreas


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


On Jan. 24, 2017, 4:33 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3781/
> ---
> 
> (Updated Jan. 24, 2017, 4:33 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11796:1c03f7dcaa8c
> ---
> riscv: Remove ECALL tests from insttest
> 
> The system calls tested in rv64i.cpp in RISC-V's insttest suite have
> different behavior depending on the operating system and file system they
> are run on. This patch removes those tests from the regression.
> 
> [Change deletion of ECALL test to block comment.]
> [Restore ECALL test but remove test output to test only for completion
> without error.]
> 
> 
> Diffs
> -
> 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/minor-timing/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-atomic/stats.txt 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.ini
>  97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/config.json
>  97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/simout 
> 97eebddaae84 
>   
> tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing-ruby/stats.txt 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.ini 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/config.json 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simerr 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/simout 
> 97eebddaae84 
>   tests/quick/se/02.insttest/ref/riscv/linux-rv64i/simple-timing/stats.txt 
> 97eebddaae84 
> 
> Diff: http://reviews.gem5.org/r/3781/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alec Roelke
> 
>

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

Re: [gem5-dev] Bug in x86 stack instructions

2017-01-25 Thread Gabe Black

Forgive me if I'm repeating a bit of what you said, Steve, but I looked a
little more and there's more to fix.

Also, if you look at x86/isa/microops/ldstop.isa, you'll find the python
classes which receive the parameters of the load and store microops and
translate them into C++ instantiations of the underlying microop classes.
In their __init__ methods, you'll see at the end where the AddrSizeFlagBit
is set based on whether or not the machInst.legacy.addr bit is set,
basically whether the address size prefix had been found when the
instruction was decoded. For the two classes involved (LdStOp and
BigLdStOp), I think you'll want to add a check which doesn't set
AddrSizeFlagBit if the segment is the stack segment.

Additionally, you'll want to make sure the TLB knows to use the stack
segment size (as opposed to either the default or alternate address sizes)
when manipulating the segment offset. You could add a new ISA specific flag
for x86 memory requests (there seems to be room for exactly one more in
arch/x86/ldstflags.hh) and set it if the segment is the stack in those ld
and st ops, similar to how AddrSizeFlagBit is being set. Then in the TLB,
specifically where it's calculating logSize, you'll want to make it
recognize your new flag and use the stack size from the m5Reg (called just
m5Reg.stack, I think) instead of either of the address size values.

This is a little gross because it means there's some calculation going on
when address translation is being done (frequently) when it could have been
done earlier during decode (less frequently). One reason I did things this
way (all speculation, I've long since forgot) is that it makes the decoded
instructions hold less state. The same bytes may not always refer to the
same sizes depending on the segmentation state in the machine, so if those
particular bytes are being decoded, the gem5 decode cache needs to either
consider that segmentation state when deciding what instruction to spit
out. If it didn't, it might return an instruction which statically says to
use 32 bit addresses (for instance), when now segmentation state says it
the same bytes should mean it should use 16 bit addresses. Instead, it canh
be factored in dynamically using external state (the m5Reg) to an
instruction that says which version of the sizes to use but doesn't care
what values those actually map to at that moment.

Gabe

On Wed, Jan 25, 2017 at 12:03 AM, Gabe Black  wrote:

> Hi. I think you guys are generally interpreting this code correctly, but
> I'll throw in my two cents. If you look at the pseudo code here:
>
> http://www.felixcloutier.com/x86/CALL.html
>
> then it appears that the size of the return address you push onto the
> stack should be based on the operand size, ie. the data size. That would
> mean that the displacement for the store should be -env.dataSize like it
> is. By the same logic, the subtraction below it should also be env.dataSize
> (symbolically dsz) and not ssz.
>
> You are also correct, I think, that since the instruction references the
> stack segment, it's address size should be set to the stack size when doing
> memory operations. Adding addressSize=ssz to the st microop should do that.
>
> According to that pseudo code, the size of the target IP is also the
> operand size, but that's the size the wrip microop will use by default and
> so should be fine as written.
>
> I think if you make those two changes (change ssz to dsz in the sub, add
> addressSize=ssz to the st), then this macroop definition will be correct.
> It would be worthwhile to check the other definitions of CALL and make sure
> they aren't similarly broken.
>
> Gabe
>
> On Tue, Jan 24, 2017 at 3:28 PM, Jason Lowe-Power 
> wrote:
>
>> Thanks for helping me work this out.
>>
>> I got the binary working by completely removing the AddrSizeFlagBit. The
>> only place this bit is used is in the LdStOp (it's set to true if
>> legacy.addr is true) and then, in the TLB, if the AddrSizeFlagBit is set
>> it
>> truncates the address to 32-bits removing the upper-order bits.
>>
>> By removing this flag bit, and adding "addressSize=ssz" to the st
>> micro-op,
>> the binary is now working.
>>
>> My next question: How can I have any confidence that this doesn't break
>> other things? Especially when we're talking about 32-bit compatibility
>> mode. Other than the hello32 binary, are there other things I should run?
>>
>> My intuition says this is an OK change. The addr field in the Request
>> should never have the upper-order 32 bits set if the instruction is a
>> 32-bit-mode instruction. The instruction implementation already takes care
>> of this, as I found with this bug.
>>
>> Other thoughts? Does anyone know if it is definitely required to use
>> AddrSizeFlagBit to truncate the address in the TLB?
>>
>> If not, I'll post a patch for this tomorrow.
>>
>> Thanks,
>> Jason
>>
>> On Tue, Jan 24, 2017 at 12:19 PM Steve Reinhardt 
>>

Re: [gem5-dev] Bug in x86 stack instructions

2017-01-25 Thread Gabe Black

Hi. I think you guys are generally interpreting this code correctly, but
I'll throw in my two cents. If you look at the pseudo code here:

http://www.felixcloutier.com/x86/CALL.html

then it appears that the size of the return address you push onto the stack
should be based on the operand size, ie. the data size. That would mean
that the displacement for the store should be -env.dataSize like it is. By
the same logic, the subtraction below it should also be env.dataSize
(symbolically dsz) and not ssz.

You are also correct, I think, that since the instruction references the
stack segment, it's address size should be set to the stack size when doing
memory operations. Adding addressSize=ssz to the st microop should do that.

According to that pseudo code, the size of the target IP is also the
operand size, but that's the size the wrip microop will use by default and
so should be fine as written.

I think if you make those two changes (change ssz to dsz in the sub, add
addressSize=ssz to the st), then this macroop definition will be correct.
It would be worthwhile to check the other definitions of CALL and make sure
they aren't similarly broken.

Gabe

On Tue, Jan 24, 2017 at 3:28 PM, Jason Lowe-Power 
wrote:

> Thanks for helping me work this out.
>
> I got the binary working by completely removing the AddrSizeFlagBit. The
> only place this bit is used is in the LdStOp (it's set to true if
> legacy.addr is true) and then, in the TLB, if the AddrSizeFlagBit is set it
> truncates the address to 32-bits removing the upper-order bits.
>
> By removing this flag bit, and adding "addressSize=ssz" to the st micro-op,
> the binary is now working.
>
> My next question: How can I have any confidence that this doesn't break
> other things? Especially when we're talking about 32-bit compatibility
> mode. Other than the hello32 binary, are there other things I should run?
>
> My intuition says this is an OK change. The addr field in the Request
> should never have the upper-order 32 bits set if the instruction is a
> 32-bit-mode instruction. The instruction implementation already takes care
> of this, as I found with this bug.
>
> Other thoughts? Does anyone know if it is definitely required to use
> AddrSizeFlagBit to truncate the address in the TLB?
>
> If not, I'll post a patch for this tomorrow.
>
> Thanks,
> Jason
>
> On Tue, Jan 24, 2017 at 12:19 PM Steve Reinhardt  wrote:
>
> > Hmm, seems like there's a little bit of an inconsistency in that the
> > request is using the legacy.addr bit (which is set by the decoder when it
> > sees the address size override prefix [1]) directly, while the
> legacy.addr
> > bit is also used to calculate the addressSize value [2] but can be
> > overridden (as we are doing). So if addressSize is overridden then
> > AddrSizeFlagBit should no longer be set based on legacy.addr.
> >
> > Or another way of looking at it is that the same process of checking
> > legacy.addr to override the address size is done in two places, once in
> the
> > decoder [2] and again in the TLB [3] and it's not clear how to suppress
> the
> > latter one.
> >
> > I suppose one gnarly way of doing it would be to go into the micro-op
> > definition somewhere and clear the AddrSizeFlagBit out of memFlags if
> > addressSize != env.addressSize (i.e., the address size was overridden).
> > There's probably a cleaner way, but that's the easiest path I can think
> of
> > (if it even works).
> >
> > [1] http://grok.gem5.org/xref/gem5/src/arch/x86/decoder.cc#195
> > [2] http://grok.gem5.org/xref/gem5/src/arch/x86/decoder.cc#390
> > [3] http://grok.gem5.org/source/xref/gem5/src/arch/x86/tlb.cc#315
> >
> >
> > On Tue, Jan 24, 2017 at 8:37 AM, Jason Lowe-Power 
> > wrote:
> >
> > > Hi Steve,
> > >
> > > That was super helpful. I'm now a step closer to solving this!
> > >
> > > Your suggestion of =ssz, lead me to search for the uses of that in x86,
> > and
> > > it turns out that almost all of other stack instructions have
> > dataSize=ssz.
> > > So, I added both dataSize=ssz and addressSize=ssz to the call
> > instruction,
> > > though I think only the addressSize is actually needed, but I'm not
> > > certain.
> > >
> > > Now, the address is passed to the Request object correctly, but the
> > program
> > > still fails. The problem now is that the request object is getting
> > > the AddrSizeFlagBit set to true, because machInst.legacy.addr is true.
> > > Thus, the TLB only uses the lower 32 bits of the 64-bit address.
> > >
> > > Any ideas on how to change the instruction's memFlags from the macro-op
> > > definition? They are set on
> > > http://repo.gem5.org/gem5/file/cd7f3a1dbf55/src/arch/
> > > x86/isa/microops/ldstop.isa#l334
> > > .
> > >
> > > It would be nice if we could fix this in the decoder. I think the logic
> > > should be "if the address prefix is set and this is an implicit stack
> > > operation, ignore the address prefix". However, I'm not sure how

Re: [gem5-dev] Bug in x86 stack instructions

Re: [gem5-dev] Compilation error for gem5 after statfs change

Re: [gem5-dev] Bug in x86 stack instructions

Re: [gem5-dev] Review Request 3791: dev: net/i8254xGBe add two more wakeup registers to ignore

Re: [gem5-dev] Ideas for sprint projects

Re: [gem5-dev] Review Request 3773: ruby: PerfectSwitch add assured access arbitration

Re: [gem5-dev] Bug in x86 stack instructions

Re: [gem5-dev] Ideas for sprint projects

Re: [gem5-dev] Ideas for sprint projects

Re: [gem5-dev] Review Request 3791: dev: net/i8254xGBe add two more wakeup registers to ignore

[gem5-dev] Review Request 3791: dev: net/i8254xGBe add two more wakeup registers to ignore

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

Re: [gem5-dev] Review Request 3781: riscv: Remove ECALL tests from insttest

Re: [gem5-dev] Bug in x86 stack instructions

Re: [gem5-dev] Bug in x86 stack instructions

15 matches

Site Navigation

Mail list logo

Footer information