Great question!
Since KVM is executing using the host's hardware, you can't use the magic
instructions! However, we have another interface (called `m5_addr` or
`m5-addr` in the code, IIRC) that will work with KVM. If you compile using
-DM5_ADDR=, it should work in KVM. For x86, we usually
use 0xFF
Hello Jason and everyone,
I'll add the fix to my todo list :)
But before then, I'm confused by something. Thanks for the link to hooks and
indeed I "m5_work_begin(0,0);. I recompiled the benchmarks I had with work
begin and end. It's just adding "m5_work_begin(0,0)" and "m5_work_end(0,0)" at
the
Indeed there is a way to signal workbegin and workend from the program itself
with m5 ops. But I'm trying to avoid recompiling a whole bunch of code to make
it happen, though I can do that too. If there is a way to simulate workbegin
and workend from the command line great, otherwise no worries
Hi George,
For workbegin/workend, they can be called from within applications if you
link to the libm5 library. For instance, in the parsec resource here:
https://resources.gem5.org/resources/parsec we use the m5_workbegin()
function in the ROI hooks. See
https://gem5.googlesource.com/public/gem5-
I don't think we ever transitioned from an assembly based mechanism to a C
based one, since we have always (as far as I know) used both, assembly to
actually invoke the call into gem5, and C to provide a friendly
interface/wrapper around the assembly. That said, yes, it looks like work
begin and wo
Hi George,
Thanks for reporting this, I noticed the same issue. When we transitioned from
the old m5 subsystem (assembly based) to the new C based one we forgot to
provide an implementation for workbegin and workend I suppose. Putting Gabe on
CC
Kind Regards
Giacomo
From: George Michelogiann