Re: Introspection API development

Stephen Pape
2016-08-04T15:08:58Z

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@gmail.com> 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