Adding a new instruction to QEMU

Issue

I'm a little confused going about adding a new instruction to QEMU and want to confirm if my understanding is right. After going through the source code, I think adding an instruction to QEMU involves the following steps:

1. Define a helper function of the format CHERI_HELPER_IMPL(*instruction* in \target\target_arch\op_helper.c that emulates this instruction.
2. Define generate_*instruction* in \target\target_arch\translate.c that calls gen_helper_*instruction* which calls the helper function.

Am I missing any steps?

Solution

The fact that you mention a "CHERI_HELPER_IMPL" macro tells me that you're not working with upstream QEMU, but with the CHERI project's fork of it. So you should talk to them about anything special that might be needed there. As I understand it their local modifications may be quite significant.

For upstream QEMU, this depends on whether the target architecture is using decodetree or not.

For decodetree-based architectures:

• add a suitable instruction pattern or patterns to the .decode file. This will result in the generation of code which calls a function whose name begins trans_ to handle instructions that match that pattern, passing it a pointer to a structure which contains the values of the various instruction fields defined by your pattern.
• implement the trans_ functions appropriately. What you need to do depends on what the instruction behaviour is. For simple instructions, you can just emit TCG ops which do the actions the instruction must do. For more complicated work, you might want to emit TCG ops for "call a runtime helper function". The tcg/README file has some "recommended coding rules" at the bottom which include a rule of thumb for when to use a helper function.
• if you decided to emit a helper call, you need to implement the helper function. The DEF_HELPER_* macros in helper.h both define the prototype for the C function you're going to write and also auto-generate a function gen_helper_whatever that your translate-time code can call to generate the TCG code to call it.

For non-decodetree-based architectures:

• There will be hand-written code, usually starting in translate.c, which identifies instructions using switch statements and bit-masking code. You'll need to look at that code to find out where in that to add the code which identifies the instruction that you're adding. This is all completely target-specific; some targets use a somewhat table-driven setup or some preprocessor macros as part of this, some use completely hand-written code.
• Once you've figured out where to add the "is this my instruction type?" check, the rest is similar to decodetree-based targets: you need to emit TCG ops to either do the work or to call a helper to do the work at runtime.

You'll find that there's a lot of specific detail that needs to be got right in each of these steps, but that's the basic outline.

Answered By - Peter Maydell