应该首选完整系统模式(如果可以使用它)。使用它有很多好处,主要是模拟的保真度,这是系统调用模拟模式无法实现的。(内核与应用程序的交互可能很重要,这取决于研究人员试图进行的研究。)此外,用户无需担心实现(或调试)系统调用实现。
话虽如此,系统调用仿真模式在适当的条件下可能很有用。运行应用程序代码更快,因为后台没有运行内核。如果您想完全减轻它,也没有系统噪音。可以说,引导新设备模型也更容易。您可以在没有驱动程序支持的情况下处理模型,并通过假接口使魔术发生。(它使您不必完美地建模裸机接口或不必编写自己的设备驱动程序。)
您对动态链接和多线程支持的评论是相关的。如果动态链接是固定的,您应该能够使用系统的 pthreads 库,并且可以完全忘记与 m5threads 的链接。pthread 库支持在模拟器中已经存在了一段时间(它正常工作所必需的系统调用)。
但是,线程实现有一个警告。您需要在模拟开始时预先分配足够的线程上下文(通过调用 se.py 脚本上的 -n 选项)。
详细地说,没有在后台运行的操作系统来调度处理器上的线程。(我在这里非常松散地使用术语线程和处理器。)为了避免调度问题,您必须预先分配足够的处理器,以便可以在调用 clone/execve 时创建线程。有一个限制,你不能拥有比处理器更多的线程(与操作系统可以随意调度它们的真实系统不同)。
配置脚本的行为可能与研究人员希望它们针对多线程工作负载的行为不同。研究人员需要验证缓存配置是否正确,以及它们是否像真机一样共享某些缓存级别。如果应用程序多次调用 clone/execve,则可能无法使生成的配置表现得真实。
您关于建模加速器的最后陈述是不正确的。AMD GFX8 模型确实使用系统调用仿真模式。(此外,我们开发了一个从未公开发布的 NIC 模型。)它涉及创建一个假驱动程序并通过与真正驱动程序相同的 ioctl 接口对其进行操作。Linux 将所有内容都视为文件,因此驱动程序通过开放的系统调用接口打开,您可以在那里捕获它。您可能还需要做其他事情(例如在配置中映射 mmio 范围),但驱动程序接口是主要部分。应用程序与驱动程序交互,驱动程序与加速器模型交互。