On 2016-08-04 10:50, Paolo Bonzini wrote: > > > 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? IIRC, the project was not started in the end. Jan > > 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
