Paolo Bonzini writes: > On 10/25/2010 12:54 PM, Lluís wrote: >> * 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).
> You can add the syscall and, if it returns with ENOSYS, fall back to MMIO/PIO > (you don't really need a special driver, only some chmod since BARs are > accessible from /sys) or watchpoint/breakpoint. That sounds nice, but would only work with Linux. I, for example, did some full-system simulations with a QNX guest. I know extending the ISA is not nice at all, but I think that's much more maintainable than a per-guest OS interface (supposing some will need extra guest drivers). Another option is going along the path of PPC, where "meanlingless" operations such OR'ing two zeros is, in fact, an obscure extension of the ISA to communicate with the hardware SMT priority manager. Or, for example, using "special" arguments during a cpuid on x86 targets. But there's still another option. Simply using the recently-posted virtproxy infrastructure. The downside of this last method is that this backdoor channel will appear as the execution of a lot of regular code on the simulation (e.g., a syscall to write on a socket). If it's just an mmap'ed device, then we're back on the MMIO/PIO case. The point here is that the ISA-based backdoor (whether using invalid opcodes or overloading certain pre-existing operations) is the one providing the least interference on the guest-side. >> * 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). > Switching between KVM and TCG is not possible at the moment, even though in > principle it should be feasible for non-SMP guests. Aaahh... I was going to look into that after instrumenting physical memory accesses, but if you say it's not possible... I just looked into how kvm_cpu_exec is called from cpu_exec, and assumed that state can be transferred from/to each side at any time (e.g., using kvm_arch_get_registers/kvm_arch_put_registers). And why isn't it feasible on SMP guests? I suppose it's because each vCPU is running on a different pthread, and most of the QEMU code is not thread safe. If that's the reason, that seems like a lot more work than I'm able to do right now, but I see two possible solutions: * provide a crude hack on KVM-enabled QEMU builds to run all vCPUS only on one pthread when any of them switch off from KVM-mode * integrate part of the work from the coremu project, such that QEMU is effectively able to run cores on separate threads, even when using TCG. 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
