> On June 18, 2015, 10:07 p.m., Nilay Vaish wrote: > > Can you give a more detailed example as to what's wrong with the current > > version? > > Nikos Nikoleris wrote: > Forcing kvm to update the register state breaks the m5_readfile, this > patch fixes it. The problem is that m5_readfile expects the numbers of bytes > that were read from the MMIO to be written to rax which is not happening at > the current version. > > When we mark the thread context as dirty, a sync with the kvm state is > forced and an ioctl with KVM_SET_REGS is executed. I don't fully understand > how the kernel handles the update of the registers in the middle of an MMIO > request but it seems that the update to the registers overwrites the value of > rax. > > When I wrote this patch I had a look at the pseudoInsts that are > implemented through MMIO requests but I missed a couple that explictly change > the register state like m5Syscall. So while the patch fixes m5_readfile and > probably other pseudoInsts, it breaks m5Syscall and maybe others.
I see, indeed m5Syscall in particular requires the context to be updated in order to be able to read RAX which specifies the syscall to perform. However, the context needs to updated as it is required for the finalization of MMIO operations; I am sure Andreas can have a more detailed comment on this. Are you running in SE mode? Maybe the solution to this is to handle differently m5 ops. - Alexandru ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2774/#review6498 ----------------------------------------------------------- On May 11, 2015, 3:52 p.m., Nikos Nikoleris wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2774/ > ----------------------------------------------------------- > > (Updated May 11, 2015, 3:52 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10833:9fd3d5837e1e > --------------------------- > cpu, kvm: Don't flag TC as dirty after m5op > > Currently, none of the m5ops changes the TC, and therefore it cannot be > dirty. Syncing the TC results in incorrect register state for the > simulated system, since the kernel will first emulate the instruction > and then update the guest's register state. > > > Diffs > ----- > > src/cpu/kvm/base.cc fbdaa08aaa42 > > Diff: http://reviews.gem5.org/r/2774/diff/ > > > Testing > ------- > > > Thanks, > > Nikos Nikoleris > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
