> On March 18, 2016, 9:11 p.m., Alexandru Dutu wrote: > > > > Alexandru Dutu wrote: > I am not sure I understand why it is required to sync on every exit and > not just on a gdb breakpoint exit. Also, I am curious about your motivation > for a kvm-specific thread context. Can you please detail a bit?
The problem with the current solution is that we can't reliably detect if someone caches a pointer to the TC and when it has been modified. We assume that components outside of the CPU that need access to the TC will play nicely and ask for it using the public methods every time, which makes it possible for the KVM CPU to pull out the TC from the kernel. Similarly, if the KVM CPU knows that the a non-const context has been requested, it forces a synchrnization of /all/ registers the next time it starts the CPU. A more desirable solution would be to load registers as they are accessed via the TC interfaces. This allows us to limit the synchronization operations to the affected registers. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3388/#review8096 ----------------------------------------------------------- On March 16, 2016, 5:44 p.m., Andreas Sandberg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3388/ > ----------------------------------------------------------- > > (Updated March 16, 2016, 5:44 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11374:74c2b67b2684 > --------------------------- > kvm: Add an option to force context sync on kvm entry/exit > > This changeset adds an option to force the kvm-based CPUs to always > synchronize the gem5 thread context representation on entry/exit into > the kernel. This is very useful for debugging. Unfortunately, it is > also the only way to get reliable register contents when using remote > gdb functionality. The long-term solution for the latter would be to > implement a kvm-specific thread context. > > Signed-off-by: Andreas Sandberg <andreas.sandb...@arm.com> > > > Diffs > ----- > > src/cpu/kvm/BaseKvmCPU.py 3234b429fe04 > src/cpu/kvm/base.hh 3234b429fe04 > src/cpu/kvm/base.cc 3234b429fe04 > > Diff: http://reviews.gem5.org/r/3388/diff/ > > > Testing > ------- > > Used extensively for debugging. > > > Thanks, > > Andreas Sandberg > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
