We've developed an introspection API that I'm using with Xen already. Our libraries right now have a core and a Xen plugin that gets loaded at runtime. My goal is to just make a KVM plugin, but KVM would need introspection features for that to happen. We have abstractions for things like mapping guest memory. Given a virtual address, vcpu, and length, it does the virt->phys translations for each page and maps them sequentially in the process' address space. It makes it convenient for accessing structures in the guest, especially if they span multiple pages. I didn't see a great way to get that kind of feature into QEMU. Besides that, we do things with #GP/#UD faults. As far as I understand it, QEmu doesn't have access to vmexits of that type, but maybe I'm missing something? -Stephen On Thu, Aug 4, 2016 at 8:48 AM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Wed, Aug 03, 2016 at 11:25:07PM -0400, Stephen Pape wrote: >> Hello all, >> >> For my own purposes, I've been modifying KVM to support introspection. >> I have a project that uses Xen's "vm event" API, and I'm trying to get >> things working with KVM as well. Our implementation needs to be able >> to map guest memory directly. I have seen the qemu patch used by >> libvmi, but they handle memory reads and writes through a socket, >> which just won't work for us. I'm also looking to add other types of >> hooks, and patching qemu seems too limited. >> >> My approach involves modifying the kernel driver to export a >> /dev/virt/ filesystem. I suppose I could do it all via /dev/kvm ioctls >> as well. >> >> My (relatively minor) patch allows processes besides the launching >> process to do things like map guest memory and read VCPU states for a >> VM. Soon, I'll be looking into adding support for handling events (cr3 >> writes, int3 traps, etc.). Eventually, an event should come in, a >> program will handle it (while able to read memory/registers), and then >> resume the VCPU. > > Why not put your code into QEMU if your end goal is to handle the > vmexit? > > Can you describe the use case and software you are developing? > > Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
