Re: [RFC PATCH 1/1] QEMU plugin interface extension

[Peter Maydell]

On Tue, 24 Aug 2021 at 15:34, Florian Hauschild
<florian.hauschild@fs.ei.tum.de> wrote:
>
>
>
> Am 21.08.21 um 15:18 schrieb Peter Maydell:
> > On Sat, 21 Aug 2021 at 10:48, Florian Hauschild
> > <florian.hauschild@fs.ei.tum.de> wrote:
> >>
> >> This extension covers functions:
> >>   * to read and write guest memory
> >>   * to read and write guest registers
> >>   * to flush tb cache
> >>   * to control single stepping of qemu from plugin
> >>
> >> These changes allow the user to
> >>   * collect more information about the behaviour of the system
> >>   * change the guest state with a plugin during execution
> >>   * control cache of tcg
> >>   * allow for precise instrumentation in execution flow
> >
> >> +
> >> +static int plugin_read_register(CPUState *cpu, GByteArray *buf, int reg)
> >> +{
> >> +    CPUClass *cc = CPU_GET_CLASS(cpu);
> >> +    if (reg < cc->gdb_num_core_regs) {
> >> +        return cc->gdb_read_register(cpu, buf, reg);
> >> +    }
> >> +    return 0;
> >> +}
> >
> > At the point where these functions execute is the emulation
> > definitely stopped (ie no register values currently held
> > live in TCG locals) ?

> I am not sure, if it is definitely stopped.
> I call them during tb_exec_cb and insn_exec_cb.
> I have used the extension on ARM and RISC-V single cpu guests and the
> data collected is the one i would expect during normal execution on real
> hardware. How this would behave on a multi cpu/core system i have not
> tested yet.

Multicore isn't relevant here. What you want to check for
is what happens when the TB covers multiple guest instructions
such that a later insn in the TB uses a register that is
set by an earlier insn in the TB, eg:

    mov x0, 0
    add x0, x0, 1
    add x0, x0, 1

In this case TCG is likely to generate code which does not
write back the intermediate 0 and 1 values of x0 to the CPUState
struct, and so reading x0 via the gdb_read_register interface
before the execution of the 3rd insn will continue to return
whatever value x0 had before execution of the TB started.

For the gdbstub's use of the gdb_read_register API, this
can't happen, because we always completely stop the CPU
(which means it is not inside a TB at all) before handling
gdbstub packets requesting register information.

I don't know whether the TCG plugin infrastructure takes steps
with its various callbacks to ensure that intermediate values
get written back to the CPU state before the callback is
invoked: it's possible that this is safe, or can be made to
be safe.

thanks
-- PMM