Lines Matching full:the
4 QEMU's Tiny Code Generator (TCG) provides the ability to emulate a
7 depending on the guest architecture.
40 - The ubiquitous desktop PC CPU architecture, 32 and 64 bit.
60 - Open source RISC architecture developed by the OpenRISC community
99 Semihosting is a feature defined by the owner of the architecture to
102 hooked directly to the board. QEMU's implementation allows for
103 semihosting calls to be passed to the host system or via the
112 to exit test code while reporting the success state.
114 Semihosting is only available using TCG emulation. This is because the
120 the guest and the host. As a result a program using semihosting can
129 during debugging via the :ref:`gdbstub<GDB usage>`. Output to the
138 minor changes to define the appropriate instruction to encode the
139 semihosting call and which registers hold the parameters. They tend to
141 write files, access the console and some other basic interactions.
143 For full details of the ABI for a particular target, and the set of
144 calls it provides, you should consult the semihosting specification
149 access in ``O_BINARY`` mode. The user-visible effect of this is
150 regardless of the text/binary mode the program sets QEMU will
153 support doesn't make the distinction between the modes and
185 advantage of the total system control emulation can have over a guest.
187 translation and execution and optionally callback into the plugin
188 during these events. TCG plugins are unable to change the system state
193 See the developer section of the manual for details about
212 behaviour. In this case the howvec plugin is being asked to use inline
213 ops to count and break down the hint instructions by type.
215 Linux user-mode emulation also evaluates the environment variable
220 QEMU plugins avoid to write directly to stdin/stderr, and use the log provided
221 by the API (see function ``qemu_plugin_outs``).
234 basic plugins that are used to test and exercise the API during the
235 ``make check-tcg`` target in ``tests/tcg/plugins`` that are never the
243 Purely a test plugin for measuring the overhead of the plugins system
252 each basic block is executed. By default the results are shown once
260 Behaviour can be tweaked with the following arguments:
271 - Dump the current execution stats whenever the guest vCPU idles
278 The bbv plugin allows you to generate basic block vectors for use with the
288 - The interval to generate a basic block vector specified by the number of
291 - The path to output files.
308 This is a basic instruction level instrumentation which can count the
325 Behaviour can be tweaked with the following arguments:
336 - Give a summary of the instruction sizes for the execution
338 - Only instrument instructions matching the string prefix
340 The ``match`` option will show some basic stats including how many
341 instructions have executed since the last execution. For
356 For more detailed execution tracing see the ``execlog`` plugin for
371 Behaviour can be tweaked with the following arguments:
392 default it will give a summary of syscall stats at the end of the
419 Behaviour can be tweaked with the following arguments:
428 - Print the number of times each syscall is called
430 - Log the buffer of each write syscall in hexdump format
446 The hotblocks plugin allows you to examine the where hot paths of
447 execution are in your program. Once the program has finished you will
448 get a sorted list of blocks reporting the starting PC, translation
460 collected 903 entries in the hash table
485 The hotpages plugin can be configured using the following arguments:
494 - Log the data sorted by either the number of reads, the number of writes, or
495 memory address. (Default: entries are sorted by the sum of reads and writes)
499 - The page size used. (Default: N = 4096)
508 counted. You can give a value to the ``count`` argument for a class of
509 instructions to break it down fully, so for example to see all the system
516 which will lead to a sorted list after the class breakdown::
561 To find the argument shorthand for the class you need to examine the
562 source code of the plugin at the moment, specifically the ``*opt``
563 argument in the InsnClassExecCount tables.
573 asynchronous events are introduced. While the use of -icount can
574 introduce determinism to the execution flow it doesn't always follow
575 the translation sequence will be exactly the same. Typically this is
576 caused by a timer firing to service the GUI causing a block to end
578 people at roughly where execution diverges. The only argument you need
579 for the plugin is a path for the socket the two instances will
606 The hwprofile tool can only be used with system emulation and allows
607 the user to see what hardware is accessed how often. It has a number of options:
616 - By default the plugin tracks both reads and writes. You can use
617 this option to limit the tracking to just one class of accesses.
619 - Will include a detailed break down of what the guest PC that made the
620 access was. Not compatible with the pattern option. Example output::
628 - Instead break down the accesses based on the offset into the HW
629 region. This can be useful for seeing the most used registers of
647 The execlog tool traces executed instructions with memory access. It can be used
651 The plugin needs default argument::
671 The output can be filtered to only track certain instructions or
672 addresses using the ``ifilter`` or ``afilter`` options. You can stack the
678 This plugin can also dump registers when they change value. Specify the name of the
685 execution quite considerably. You can optimise the number of register
686 checks done by using the rdisas option. This will only instrument
687 instructions that mention the registers in question in disassembly.
689 instructions. You can use the ifilter to catch these cases::
699 Cache modelling plugin that measures the performance of a given L1 cache
706 will report the following::
725 The plugin has a number of arguments, all of them are optional:
739 - Instruction cache configuration arguments. They specify the
740 cache size, block size, and associativity of the instruction
749 - Sets the eviction policy to POLICY. Available policies are:
750 ``lru``, ``fifo``, and ``rand``. The plugin will use
751 the specified policy for both instruction and data caches.
754 - Sets the number of cores for which we maintain separate icache
759 instructions and data) using the default L2 configuration (cache
773 The stoptrigger plugin allows to setup triggers to stop emulation.
783 For example, to stop at the 20-th instruction with return code 41, at address
789 The plugin will log the reason of exit, for example::
796 This plugin can limit the number of Instructions Per Second that are executed::
813 The plugin will sleep when the given number of instructions is reached.
816 The lower the number the more accurate time will be, but the less efficient the plugin.