Re: Introspection API development

Jan Kiszka
2016-08-04T09:13:49Z

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.