Could you provide some more details about your experiments? Which
architecture are you simulating and which CPU models are you using?
Also, which version of gem5 are you using? Preferably, which commit are
Could you try to run the regressions tests on the simulator?
Particularly the switcheroo tests.
I've been running several experiments where I've been 10s of thousands
of switches between kvm/atomic/o3, which worked fine on a version from
~November last year. There are a couple of known regressions that were
introduced around November that might be biting you. If you are using
KVM, you need to use a version from last Sunday or newer, otherwise
rflags synchronization on x86 won't work because of a regression
introduced a couple of months ago.
Post by Srinivasan Narayanamoorthy
Hi,I am Srini. I am kind of a new user to gem5 and for some of my experiments, I need to repeatedly switch between two cpu models. I figured configuring repeat-switch option is an easy way of doing it but was soon hitting some drain related assertions. Turns out that when the drain manager is signaled drainDone, decode/rename could be unblocking/blocked and the unblocking status is not propagated to fetch(1 cycle delay), and hence fails the drainSanityCheck happening in the same cycle.
So to avoid this , I qualified the isDrained() in each of the stages with the corresponding status signals and those assertions are not firing. I also emptied the branch history on a drain. Please let me know if what I am doing is correct.
gem5-users mailing list