I have a prototype implementation that uses a mechanism very similar to
the one on x86. The main reason I haven't posted it externally is that I
wanted to get the user-space side (the m5 tool) to autodetect the memory
range. We currently have to hard-code it, which isn't ideal if the
memory map changes. My plan was to add a custom gem5 kernel driver that
discovers the location of the m5op space using the device tree and then
exposes it as a memory mapped device in /dev.
I need to find someone to review it internally. Once that's done, I
should be able to post it externally (probably Monday).
//Andreas
On 20/04/2017 15:23, Jason Lowe-Power wrote:
Hi Gabe,
I'm not sure about ARM, but for x86, when running with KVM the "magic
instructions" use MMIO. Most of them work fine for x86, except readfile,
which I need to post a patch for. I'm pretty sure that ARM works the same
way, but maybe Andreas S. can answer better.
Cheers,
Jason
On Wed, Apr 19, 2017 at 6:09 PM Gabe Black <[email protected]> wrote:
Hi everybody. Weiping is a colleague of mine at Google, and he's trying to
use the m5 utility to take a checkpoint from within a simulation on aarch64
which is running in KVM mode. The utility was causing an illegal
instruction fault, and so I started looking into it for him.
Unsurprisingly, the illegal instruction actually is an illegal instruction
which would trigger the checkpointing pseudo instruction if gem5 had seen
it, but I believe everything stayed within kvm land and so no checkpoint
was taken.
I remember a while ago there being an effort to switch the pseudo
instructions over to be a magical device with the same behavior so that it
could trap reads/writes when in KVM mode. I see some evidence that support
was added for that in the 32 bit version of the m5 utility, but then later
removed because it caused other problems. I don't see any evidence that
that support was added to the 64 bit version.
What's the current state of this? Is this something we could get working
with a reasonably small amount of effort, or is there a workaround, or...?
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
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
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
