> On Aug. 17, 2016, 11:05 p.m., Andreas Hansson wrote: > > src/cpu/kvm/base.cc, line 228 > > <http://reviews.gem5.org/r/3619/diff/2/?file=57574#file57574line228> > > > > Conceptually this is not very nice, as it assumes infinite throughput. > > > > I see how we save an even this way, but I am tempted to suggest the > > inclusion of an even rather. > > Michael LeBeane wrote: > I'm not sure it's worth modeling this in KVM, but if you feel strongly > about it I can implement a fixed number of requests per cycle. > > Andreas Hansson wrote: > I am inclinced to agree. It's probably not worth changing. Perhaps add a > comment to make it clear that this is unrealistic. > > My worry is mostly that we are drifting further away from SystemC TLM2, > and the fact that we don't have a proper 4-phase handshake where we are told > when a request is accepted. If we have the "ack" for the request then it > would be clear that we must not send a second request until the first one is > accepted. That's a much bigger topic though, but just so you know the > background.
KVM actually requires this. The only case you'll get multiple requests in one tick is if the CPU executes an IO instruction with a rep prefix on x86. In this case, the model MUST accept all of the data before returning to KVM. The whole point of this routine is to buffer such requests until the interconnect accepts them. Once we get a return for KVM to handle IO, we won't hand back control until that batch of MMIOs have been handled. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3619/#review8652 ----------------------------------------------------------- On Aug. 17, 2016, 9:07 p.m., Michael LeBeane wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3619/ > ----------------------------------------------------------- > > (Updated Aug. 17, 2016, 9:07 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11561:4595cc3848fc > --------------------------- > kvm: Support timing accesses for KVM cpu > This patch enables timing accesses for KVM cpu. A new state, > RunningMMIOPending, is added to indicate that there are outstanding timing > requests generated by KVM in the system. KVM's tick() is disabled and the > simulation does not enter into KVM until all outstanding timing requests have > completed. The main motivation for this is to allow KVM CPU to perform MMIO > in Ruby, since Ruby does not support atomic accesses. > > > Diffs > ----- > > src/cpu/kvm/base.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c > src/cpu/kvm/base.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c > src/cpu/kvm/x86_cpu.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c > > Diff: http://reviews.gem5.org/r/3619/diff/ > > > Testing > ------- > > > Thanks, > > Michael LeBeane > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
