Hi Ali,
Yeah I think it is partially there. The controller could capture
memInvalidate and see that as the timing -> atomic switch, although I¹d
say it is a bit of a hack. For the other way round I do not think there
are any such calls though. Perhaps the most sensible would be to have a
virtual c
There are functions that correspond to this functionality although they’re
poorly named for the purpose, but memWriteback() -> beginning of KVM
simulation; memInvalidate -> end of KVM simulation. Another option would be to
check for the memory time atomic_noncaching which I believe only KVM uses
Hi Alex,
Oh I was not suggesting you on your own should solve it, I merely think we
cannot just ignore the issue.
I think the first thing is to establish an API around the switching of the
mode. I am happy to make the changes needed to the controller once we have
worked out the switching.
Andrea
Hi Andreas,
Sorry for the late reply, I have missed your email. I will investigate more the
issues with memory controller refresh events and let you know what I find out.
Best regards,
Alex
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/m
Hi Alex,
I had a quick look trying to reproduce the problem, but didn't manage to
do so. However, I remember this being a problem when I initially
developed the KVM stuff. I don't think it is related to changeset
5c2ecad1a3c9, instead I'd suspect it's something that happened before that.
In gene
Hi Alex,
Thanks for the clarification. I still don¹t understand how an event every
64 ms (which should be an awful lot of CPU cycles), could cause such an
issue.
Andreas
On 12/06/2014 23:58, "Alex via gem5-dev" wrote:
>Andreas Hansson via gem5-dev writes:
>
>>
>> Hi Alex,
>>
>> That sounds ra
Andreas Hansson via gem5-dev writes:
>
> Hi Alex,
>
> That sounds rather odd. The only event that should happen when there are
> no request going through the memory system (the KVM CPU operates directly
> on the underlying backing store), is the refresh, which happens roughly
> every 64 ms. Cou
Hi Alex,
That sounds rather odd. The only event that should happen when there are
no request going through the memory system (the KVM CPU operates directly
on the underlying backing store), is the refresh, which happens roughly
every 64 ms. Could you elaborate on what event it is you are referring
Hi everyone,
It seems that the KVM enter-exit cycles with 0 instructions executed are
caused by the events scheduled from the DRAMCtrl object. The issues is that
these events have a very short period which is not sufficient for KvmCPU to
even start execution.
I am not familiar with DRAMCtrl memor
Hi all,
I am trying to understand the current behaviour of KvmCPU. Previous to the
following changeset
http://repo.gem5.org/gem5/rev/2360411a16be
after every kvmRun the status was switched to runningService, a new event
was scheduled to the event queue and so with new tick handleKvmExit will be
10 matches
Mail list logo
