On 04/08/2016 05:25, Stephen Pape wrote: > > 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. I think the interface should be implemented entirely in userspace and it should be *mostly* socket-based; I say mostly because I understand that reading memory directly can be useful. So this is a lot like a mix of two interfaces: - a debugger interface which lets you read/write registers and set events - the vhost-user interface which lets you pass the memory map (a mapping between guest physical addresses and offsets in a file descriptor) from QEMU to another process. The gdb stub protocol seems limited for the kind of event you want to trap, but there was already a GSoC project a few years ago that looked at gdb protocol extensions. Jan, what was the outcome? In any case, I think there should be a separation between the ioctl KVM API and the socket userspace API. By the way most of the KVM API is already there---e.g. reading/writing registers, breakpoints, etc.---though you'll want to add events such as cr3 or idtr writes. Thanks, Paolo > My question is, is this anything the KVM group would be interested in > bringing upstream? I'd definitely be willing to change my approach if > necessary. If there's no interest, I'll just have to maintain my own > patches. -- 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
