Yep, I'll do that. Unfortunately (or fortunately?) this problem
mysteriously went away just like it had mysteriously started happening, so
I can't really poke at it at the moment. If it happens again I'll
definitely grab some traces for you.
Gabe
On Wed, Apr 4, 2018 at 3:39 AM, Andreas Sandberg
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
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
Now out of the blue I'm hitting errors having to do with setting GIC
"attributes" of some sort with code that was working a few hours earlier.
Any idea what it's upset about?
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compi
Ok, I think I figured it out, and it all has to do with the simulation
quantum. If the quantum is too big, the kernel might poke hardware and
expect to get an interrupt within a certain period of time. It could be
that the CPU gets to the end of its timeout before the simulated hardware
has had a c
I looked into this a little further, and I see the same problem happen with
one CPU but with the CPU and the devices in different event queues. I
haven't figured out exactly where things go wrong, but it looks like a
write DMA is set up but doesn't happen for some reason. I'm not sure if the
DMA st
Ok, thanks. We're deciding internally what approach to use to tackle this.
Gabe
On Wed, Mar 21, 2018 at 3:01 AM, Andreas Sandberg
wrote:
> Hi Gabe,
>
> There are issues with the IDE model that prevent it from working with
> in-kernel GIC emulation. I believe the model doesn't clear interrupts
>
Hi Gabe,
There are issues with the IDE model that prevent it from working with in-kernel
GIC emulation. I believe the model doesn't clear interrupts correctly, which
confuses the host kernel. I tried to debug this at some point, but wasn't able
to do much immaediate progress and decided it was
My next question is about disks. I see that the fs_bigLITTLE.py script uses
PciVirtIO to set up its disks, where I'm using IDE which I inherited from
the fs.py scripts I used as reference. The problem I'm seeing is that the
IDE controllers seem to be mangling commands and dropping interrupts, so
th
Ok, that (multiple event queues) made things way better. There are still
some glitches to figure out, but at least it makes good forward progress at
a reasonable speed. Thanks!
Gabe
On Mon, Mar 19, 2018 at 5:12 PM, Gabe Black wrote:
> This is on an chromebook based on the RK3399 with only ~4GB
This is on an chromebook based on the RK3399 with only ~4GB of RAM which is
not ideal, although we have a bigger machine in the works for the future. I
agree with your reasoning and don't think option 1 is a problem. We're
using static DTBs so I don't think that's an issue either. In my script,
I'm
Hmm, OK, this is very strange.
What type of hardware are you running on? Is it an A57-based chip or something
else? Also, what's your simulation quantum? I have been able to run with a
0.5ms quantum (5e8 ticks).
I think the following trace of two CPUs running in KVM should be roughly
equival
Ok, diving into this a little deeper, it looks like execution is
progressing but is making very slow progress for some reason. I added a
call to "dump()" before each ioctl invocation which enters the VM and
looked at the PC to get an idea of what it was up to. I made sure to put
that before the tim
Some output which I think is suspicious:
55462000: system.cpus0: Entering KVM...
55462000: system.cpus0: KVM: Executing for 1506000 ticks
55462000: system.cpus0: KVM: Executed 5159 instructions in 13646 cycles
(6823000 ticks, sim cycles: 13646).
56968000: system.cpus1: Entering KVM...
56968000: sy
I tried it just now, and I still don't see anything on the console. I
switched back to using my own script since it's a bit simpler (it doesn't
use all the configs/common stuff), and started looking at the KVM debug
output. I see that both cpus claim to execute instructions, although cpu1
didn't ta
Have you tried using the fs_bigLITTLE script in configs/examples/arm?
That's the script I have been using for testing.
I just tested the script with 8 little CPUs and 0 big CPUs and it seems
to work. Timing is a bit temperamental though, so you might need to
override the simulation quantum. The d
I'm trying to run in FS mode, to boot android/linux.
Gabe
On Mon, Mar 12, 2018 at 3:26 PM, Dutu, Alexandru
wrote:
> Hi Gabe,
>
> Are you running SE or FS mode?
>
> Thanks,
> Alex
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
> Sent: F
Hi Gabe,
Are you running SE or FS mode?
Thanks,
Alex
-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
Sent: Friday, March 9, 2018 5:46 PM
To: gem5 Developer List
Subject: [gem5-dev] Multicore ARM v8 KVM based simulation
Hi folks. I have a con
18 matches
Mail list logo
