Re: Introspection API development

Paolo Bonzini
2016-08-04T09:49:54Z

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.