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>

Attachment: 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

Reply via email to