Hi, We have been using gem5 with the classic memory system for a while for full system X86 simulations integrating a number of different more modern PCIe device models. Now we are trying to get things to work with Ruby as well for multi-core X86 simulations. Currently we are tracking down some driver-related bugs that only show up with Ruby, and led us to the more fundamental question of how to model PCIe semantics, in particular with regards to ordering, correctly.
My understanding is that PCIe guarantees strong ordering of operations (at least within a traffic class). And modren devices do take advantage of this: e.g. with descriptor queues where a posted write for the data buffer is immediately followed by a posted write for the descriptor, and then an MSI. Now currently our bridge for our device simulations in gem5 is implemented as a PCI device and just calls dmaRead/dmaWrite operations asynchronously without sequencing them synchronously. This at least seems to work for the classic memory system, but with ruby (MESI_Two_Level atm) we are seeing problems (still need to dig a bit deeper to confirm that this is 100% due to ordering). Is there a proper specification of what the model is for these memory operations? If the current dma ordering is too weak for PCIe semantics (looking at device models like the e1000, I see that DMAs are manually ordered by the device), any suggestions for how to go about ordering operations correctly without fully sequentializing everything? Thanks in advance, Antoine -- Antoine Kaufmann <antoi...@mpi-sws.org>
signature.asc
Description: PGP signature
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s