> On Aug. 17, 2016, 10: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. > > Andreas Sandberg wrote: > 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 Sandberg wrote: > Sorry, I'm being confused. Anyway, I agree with Michael. There is really > no reason to model this. The KVM CPU already makes a lot of other assumptions > that are several orders of magnitude worse when it comes to timing fidelity. > Issueing a handful of memory accesses in one cycle seems like a small issue > (especially considering it's extremely uncommon since it only happens for > ioport operations on x86 with the rep prefix) in the grand scheme of things.
As I said, I am less worried about the fidelity, and more about API compabitility. By allowing and using this construct, we are moving further away from TLM2 semantics. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3619/#review8652 ----------------------------------------------------------- On Aug. 17, 2016, 8: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, 8: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
