> 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?
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. - Nikos ----------------------------------------------------------- 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
