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 timers to avoid taking up VM time with printing debug stuff. In any case, I see that neither CPU gets off of PC 0 for about 2ms simulated time (~500Hz), and that's EXTREMELY slow for a CPU which is supposed to be running in the ballpark of 2GHz. It's not clear to me why it's making such slow progress, but that would explain why I'm getting very little out on the simulated console. It's just taking forever to make it that far.
Any idea why it's going so slow, or how to debug further? Gabe On Wed, Mar 14, 2018 at 7:42 PM, Gabe Black <[email protected]> wrote: > 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: system.cpus1: KVM: Executing for 5317000 ticks > 56968000: system.cpus1: KVM: Executed 7229 instructions in 14379 cycles > (7189500 ticks, sim cycles: 14379). > 62285000: system.cpus0: Entering KVM... > 62285000: system.cpus0: KVM: Executing for 1872500 ticks > 62285000: system.cpus0: KVM: Executed 5159 instructions in 13496 cycles > (6748000 ticks, sim cycles: 13496). > 64157500: system.cpus1: Entering KVM... > 64157500: system.cpus1: KVM: Executing for 4875500 ticks > 64157500: system.cpus1: KVM: Executed 6950 instructions in 13863 cycles > (6931500 ticks, sim cycles: 13863). > 69033000: system.cpus0: Entering KVM... > 69033000: system.cpus0: KVM: Executing for 2056000 ticks > 69033000: system.cpus0: KVM: Executed 5159 instructions in 13454 cycles > (6727000 ticks, sim cycles: 13454). > 71089000: system.cpus1: Entering KVM... > 71089000: system.cpus1: KVM: Executing for 4671000 ticks > 71089000: system.cpus1: KVM: Executed 6950 instructions in 13861 cycles > (6930500 ticks, sim cycles: 13861). > 75760000: system.cpus0: Entering KVM... > 75760000: system.cpus0: KVM: Executing for 2259500 ticks > 75760000: system.cpus0: KVM: Executed 5159 instructions in 13688 cycles > (6844000 ticks, sim cycles: 13688). > > [...] > > 126512000: system.cpus0: handleKvmExit (exit_reason: 6) > 126512000: system.cpus0: KVM: Handling MMIO (w: 1, addr: 0x1c090024, len: > 4) > 126512000: system.cpus0: In updateThreadContext(): > > [...] > > 126512000: system.cpus0: PC := 0xd8 (t: 0, a64: 1) > > On Wed, Mar 14, 2018 at 7:37 PM, Gabe Black <[email protected]> wrote: > >> 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 take an exit in the output I was looking at. cpu0 took four exits, >> two which touched some UART registers, and two which touched RealView >> registes, the V2M_SYS_CFGDATA and V2M_SYS_CFGCTRL registers judging by the >> comments in the bootloader assembly file. >> >> After that they claim to be doing stuff, although I see no further >> console output or KVM exits. The accesses themselves and their PCs are from >> the bootloader blob, and so I'm pretty confident that it's starting that >> and executing some of those instructions. One thing that looks very odd now >> that I think about it, is that the KVM messages about entering and >> executing instructions (like those below) seem to say that cpu0 has >> executed thousands of instructions, but the exits I see seem to correspond >> to the first maybe 50 instructions it should be seeing in the bootloader >> blob. Are those values bogus for some reason? Is there some existing debug >> output which would let me see where KVM thinks it is periodically to see if >> it's in the kernel or if it went bananas and is executing random memory >> somewhere? Or if it just got stuck waiting for some event that's not going >> to show up? >> >> Are there any important CLs which haven't made their way into upstream >> somehow? >> >> Gabe >> >> On Wed, Mar 14, 2018 at 4:28 AM, Andreas Sandberg < >> [email protected]> wrote: >> >>> 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 default is 1ms, you might need to >>> decrease it to something slightly smaller (I'm currently using 0.5ms). >>> Another caveat is that there seem to be some issues related to dtb >>> auto-generation that affect KVM guests. We are currently testing a >>> solution for this issue. >>> >>> Cheers, >>> Andreas >>> >>> >>> >>> On 12/03/2018 22:26, Gabe Black wrote: >>> >>>> I'm trying to run in FS mode, to boot android/linux. >>>> >>>> Gabe >>>> >>>> On Mon, Mar 12, 2018 at 3:26 PM, Dutu, Alexandru < >>>> [email protected]> >>>> wrote: >>>> >>>> Hi Gabe, >>>>> >>>>> Are you running SE or FS mode? >>>>> >>>>> Thanks, >>>>> Alex >>>>> >>>>> -----Original Message----- >>>>> From: gem5-dev [mailto:[email protected]] On Behalf Of Gabe >>>>> Black >>>>> Sent: Friday, March 9, 2018 5:46 PM >>>>> To: gem5 Developer List <[email protected]> >>>>> Subject: [gem5-dev] Multicore ARM v8 KVM based simulation >>>>> >>>>> Hi folks. I have a config script set up where I can run a KVM based >>>>> ARM v8 >>>>> simulation just fine when I have a single CPU in it, but when I try >>>>> running >>>>> with more than one CPU, it just seems to get lost and not do anything. >>>>> Is >>>>> this a configuration that's supported? If so, are there any caveats to >>>>> how >>>>> it's set up? I may be missing something simple, but it's not apparent >>>>> to me >>>>> at the moment. >>>>> >>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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
