Blue Swirl writes: > On Fri, Oct 22, 2010 at 6:32 PM, Lluís <xscr...@gmx.net> wrote: >> 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 I thought about implementing guest-directed KVM control, such that the guest will be able to enable/disable KVM at will, but I'm not sure how this can be accomplished in a generic way (i.e., x86 has vmcall/vmmcall as you told me a lot of time ago). > and there are guest visible side effects. I don't understand what you mean with guest-visible 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. Ok, so far I see different approaches available: * MMIO/PIO device Needs no undocumented extensions to the ISA, but requires modifying the guest OS (adding a device driver). * New syscall Needs no undocumented extensions to the ISA, but will only work with *-user emulation. * watchpoint/breapoint Needs no undocumented extensions to the ISA, but will only work with softmmu emulation, and only as long as the backdoor channel requires no arguments. * ISA extensions Needs a per-target decoding of the instruction and won't work when running under KVM. What I used until now (with my old bochs-based implementation), is the presented ISA extensions, which are used through library interposition (e.g., in softmmu emulation, launch the application with a library in LD_PRELOAD that enables/disables simulation using a constructor/destructor attribute, plus some extra backdoor communication to simulate specific processes by interposing on the fork/clone syscall). My requirements here are: * Backdoor channels need to provide arguments. * It's better to provide the same mechanism for both *-user and softmmu (otherwise the application to simulate or the interposed librariy should be compiled differently on every case). * Some applications are not fully simulated, but just some pre-defined loops are, such that I would run the application (on KVM mode if possible) until the interesting loop starts executing, switch to simulation mode, simulate an arbitrary number of loops, switch back to non-simulated mode, run until another specific loop or iteration is reached, repeat the process again. This obviously requires some application modification to insert the communication points, unless these can be identified using symbol interposition (e.g., calls to the OpenMP runtime to simulate certain parallel loops). The instrumented watchpoint/breakpoint sounds as an interesting approach, but I don't see how I can: * Differentiate among instrumented and non-instrumented watchpoints/breakpoints * Pass arguments to the instrumentation backend Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
