Loading the FS mode with multi-core O3CPU in gem5

user_13877717 0
Viewed 332

I need to run fs mode with 64 O3 cores.

According to： How to run a gem5 arm aarch64 full system simulation with fs.py with more than 8 cores? I should use one of these two methods：GICv2 extensions or GICv3.

But when I add the command：

--param 'system.realview.gic.gem5_extensions = True,

the terminal continues to output information similar to the following:

Warn:context 2:1900000 consecutive store conditional failures.

When I add the command：

--machine-type VExpress_GEM5_V2,

the terminal outputs the following information:

warn: Gicv3Distributor::write(): setting ARE to 0 is not supported!, and there is no more information after that, it seems to be still running.

I read this mailing list: https://www.mail-archive.com/gem5-users@gem5.org/msg18133.html It seems that the multi-O3CPU is not used to boot the Linux system in the end.

Therefore, should I use AtomicSimpleCPU to boot, establish a checkpoint and then load the checkpoint with out-of-order cores? Does the boot configuration need to be similar to the runtime configuration?

gem5 arm
1 Answers

As far as I can see from your description, there is no error messages that necessarily implies a GIC version problem, we have many warnings by default and those seem OK.

But yes, booting multiple cores with caches (which are required by O3) on ARM is in general broken due to uncacheable access problems issues described at https://gem5.atlassian.net/browse/GEM5-711 , and taking an atomic checkpoint after boot and restoring O3 is a solution to that mentioned in the comments of that ticket: https://gem5.atlassian.net/browse/GEM5-711?focusedCommentId=12001 There's a chance you won't hit that problem, but if you do you can easily see if that's likely to be the specific problem or not based on the error message, do you have the same assert failure as that issue?

Is there any reason why you don't want to checkpoint and restore, as that saves several minutes from boot time? Yes, it is supported, and it is one of the main use cases of checkpointing: Which system characteristics such as number of cores of cache configurations can I change when restoring a checkpoint in gem5?

Also please always provide the full CLI command and output and gem5 version when reporting this kind of problem. And in case of hangs, it is worth to have a quick --debug ExecAll and spot what were the last non-weird instructions being run, as that greatly narrows down the possible issues.

user_91607620
Related