> On Nov. 23, 2014, 11:56 a.m., Nilay Vaish wrote: > > src/cpu/o3/lsq_impl.hh, line 358 > > <http://reviews.gem5.org/r/2502/diff/1/?file=42581#file42581line358> > > > > But are you not losing the fault set by completeAcc()?
It would, indeed. What do you think is the problem here? I am not sure what the difference to a separate completion and later snoop hit would be. There effectively is a race between the snoop and the instruction, and we just gently change the timing, here, in what I would say is a benign way. Cannot build on my machine, but can have a look tomorrow into what it actually means for the load to produce a fault at completeAcc(). Shouldn't all the usual fault checking logic (page faults, access permissions) have happened way before this? - Stephan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2502/#review5523 ----------------------------------------------------------- On Nov. 24, 2014, 12:21 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2502/ > ----------------------------------------------------------- > > (Updated Nov. 24, 2014, 12:21 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10576:66ef592c85ac > --------------------------- > cpu, o3: Ignored invalidate causing same-address load reordering > > In case the memory subsystem sends a combined response with invalidate > (e.g. ReadRespWithInvalidate), we cannot ignore the invalidate part > of the response. > > If we were to ignore the invalidate part, under certain circumstances > this effectively leads to reordering of loads to the same address > which is not permitted under any memory consistency model implemented > in gem5. > > Consider the case where a later load's address is computed before an > earlier load in program order, and is therefore sent to the memory > subsystem first. At some point the earlier load's address is computed > and in doing so correctly marks the later load as a > possibleLoadViolation. In the meantime some other node writes and > sends invalidations to all other nodes. The invalidation races with > the later load's ReadResp, and arrives before ReadResp and is > deferred. Upon receipt of the ReadResp, the response is changed to > ReadRespWithInvalidate, and sent to the CPU. If we ignore the > invalidate part of the packet, we let the later load read the old > value of the address. Eventually the earlier load's ReadResp arrives, > but with new data. As there was no invalidate snoop (sunk into the > ReadRespWithInvalidate), and if we did not process the invalidate of > the ReadRespWithInvalidate, we obtain a load reordering. > > A similar scenario can be constructed where the earlier load's address > is computed after ReadRespWithInvalidate arrives for the younger > load. In this case hitExternalSnoop needs to be set to true on the > ReadRespWithInvalidate, so that upon knowing the address of the > earlier load, checkViolations will cause the later load to be > squashed. > > Finally we must account for the case where both loads are sent to the > memory subsystem (reordered), a snoop invalidate arrives and correctly > sets the later loads fault to ReExec. However, before the CPU > processes the fault, the later load's ReadResp arrives and the > writeback discards the outstanding fault. We must add a check to > ensure that we do not skip any unprocessed faults. > > > Diffs > ----- > > src/cpu/o3/lsq_impl.hh 426665ec11a9 > src/cpu/o3/lsq_unit_impl.hh 426665ec11a9 > > Diff: http://reviews.gem5.org/r/2502/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
