Plugin support for cost modelling (a.k.a. controlling time)

Introduction

Under emulation the disparity between emulation efficiency and wall clock time can lead to some weird effects. A large multi-core system for example will eventually start complaining of stalled tasks because we can’t execute enough code quickly enough. The solution for this is to change the guests view of time to from that of the host system to one that is computed based on the number of guest instructions executed. QEMU already has limited support for this in the way of icount. The pure icount mode is needed for deterministic execution but there also is a mode that attempts to auto-scale the execution rate based on what has been executed. The principle aim being to ensure micro-controller class emulations don’t run too fast. The upstream project has no intention of introducing any sort of more advanced cost modelling into the translator as it adds additional complexity to a generic translator as well as requiring an understanding of the underlying micro-architecture of CPUs which is out of scope for QEMU.

Plugins

TCG plugins allow instrumentation of streams of instructions for the purposes of analysis the execution. The original RFC included an API which allowed the plugin to assume control of the passage of time and allow for the plugin to do the cost modelling work. It was left out in the original merging due to upstream concerns about plugins becoming a mechanism for GPL avoidance however now plugins are well integrated and given the core codes lack of interest in this sort of modelling we could revisit that discussion.

Proposed work

• Create an API that allows the passage of time to be controlled by TCG plugins

• Recreate and enhance the existing icount=autio code via a plugin with a simplified i/face (maybe avg IPC/Hz)

• Deprecate the icount=auto modes and create a new -deterministic mode for that use case

It is important for any new API we have an in-tree user of it. Upstream will not be interested in maintaining an API only used by out-of-tree binaries.

Potential issues

The final work may not be accepted by upstream. The structure of the plugin code should help in maintaining and out-of-tree fork relatively lightweight if we need to although obviously upstreaming is preferable.