qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/17] [RFC] static instrumentation


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 00/17] [RFC] static instrumentation
Date: Sat, 23 Oct 2010 12:40:59 +0000

On Fri, Oct 22, 2010 at 6:32 PM, Lluís <address@hidden> wrote:
> Here's a set of patches with the current state of static
> instrumentation.
>
> Hope that this organization will help understanding the point of
> it. Patch 9 describes the taken approach for instrumenting during code
> generation, which is the main point of this.

The patches are now more readable, thanks for the effort.

> Code can also be reached at:
>     https://projects.gso.ac.upc.edu/projects/qemu-instrument
>     https://code.gso.ac.upc.edu/git/qemu-instrument
>
> Lluís Vilanova (17):
>  backdoor: Declare host-side backdoor helpers
>  backdoor: [all] Include backdoor helper declarations
>  backdoor: Declare guest-side interface macros
>  backdoor: [i386] Decode backdoor instructions
>  backdoor: [i386] Declare guest-side interface macros
>  backdoor: Add a simple example

The backdoor instruction is problematic. For example, handling that in
KVM may be difficult and there are guest visible side effects. The
same effect can be achieved with a MMIO/PIO device or instrumented
breakpoints/watchpoints.

For the MMIO/PIO device solution, there are several PV devices
available, for example virtio devices and fw_cfg. Instead of a
backdoor instruction, the guest should simply issue MMIO or PIO using
regular instructions. For Linux user, a new syscall can be added.
Anyway, the guest still needs to be modified.

Instrumenting GDB watchpoint and/or breakpoint support would be more
attractive because this would be completely invisible to the guest and
it may be controlled from GDB.

>  instrument: Handle config-time activation
>  instrument: Add initial instrumentation example
>  instrument: Dynamic per-CPU state of static instrumentation points
>  instrument: Code-generation macros
>  instrument: [all] Include instrumentation helper declarations
>  instrument: Add FETCH point
>  instrument: [i386] Call FETCH point
>  instrument: Add VMEM point
>  instrument: [all] Call VMEM point
>  instrument: Add PLVL point
>  instrument: [i386] Call PLVL point

At least in these examples, the instrumentation code just prints out a
few interesting fields, so they are almost identical to tracepoints.

The general approach seems to be that when an interesting event
happens, call the instrumentation code directly. A lot of internal
state needs to be made available to the instrumentation code, which is
a problem if that is considered as an API. Perhaps this could be
changed so that when the event happens, the only effect is that the VM
is stopped with some kind of notification. Then a controlling
application (external to QEMU) can inspect the state and
enable/disable tracepoints as it wishes, but using only the tools that
are available for tracepoints, QMP or GDB. Performance would be much
lower, though.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]