*
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing:
FAILED!
*
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic:
FAILED!*** gem5 stdout ***
*
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing:
FAILED!*** di
That's very strange. It seems like the KVM GIC interface is trying to read
register 0x9 in the GIC's CPU interface. The errno indicates that no such
register exists, which is expected (registers are usually 32 bit aligned). I'm
not why this happens. The write is /probably/ coming from the simul
The performance impact shouldn't be too bad. I did some scalability tests using
LU from SPLASH 2 years ago. IIRC, I was using an 8-core Westmere-EX based
system at the time. Native throughput for that benchmark was ~30GIPS @ 8 cores.
When running in KVM, I got something like ~15GIPS with a 1ms
Daniel Carvalho has uploaded this change for review. (
https://gem5-review.googlesource.com/9661
Change subject: mem-cache: Use Packet functions to write data blocks
..
mem-cache: Use Packet functions to write data blocks
In
Hi folks. I'm continuing to try to iron out problems with KVM on ARM, and
the problem I'm working on specifically right now is that the mouse device
gets spurious bad command bytes which panics gem5.
What I've found so far is that the guest kernel will frequently time out
while waiting for an ACK
Hello Jason Lowe-Power, Andreas Sandberg,
I'd like you to reexamine a change. Please visit
https://gem5-review.googlesource.com/9521
to look at the new patch set (#2).
Change subject: dev: Make sure the EtherTap device uses the right event
queue.
Gabe Black has submitted this change and it was merged. (
https://gem5-review.googlesource.com/9521 )
Change subject: dev: Make sure the EtherTap device uses the right event
queue.
..
dev: Make sure the EtherTap device uses
