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
