[Qemu-devel] Capture SIGSEGV to track pc.ram page access

[Qemu-devel] Capture SIGSEGV to track pc.ram page access

[Thomas Knauth]

Dear all,

I'm trying to use a signal handler to catch SIGSEGV's in qemu. I
want(ed) to use them to track which memory pages are accessed by the
guest (only accesses to the pc.ram). After some hours of fruitless mucking
around, I've come to the conclusion that it is not as straightforward
as with "normal" programs to do that.

I've swapped out the memory allocation part for the pc.ram part. I'm
using mmap() to allocate the memory with read/write/exec permissions,
and mprotect() with PROT_NONE to revoke all access permissions. I'm
also installing a SIGSEGV handler with sigaction(). But this is never
called for accesses to the mmap()ed region. This leads me to believe
that qemu is doing something behind my back to divert the SIGSEGV
signals from my handler.

My question is where do I have to touch qemu to call my code for
handling SIGSEGVs? Is this possible at all? Can anyone suggest
alternative ways of tracking which pages of pc.ram are accessed?

Thanks for your help,
Thomas.

Re: [Qemu-devel] Capture SIGSEGV to track pc.ram page access

[Stefan Hajnoczi]

On Sun, Sep 01, 2013 at 11:38:34AM +0200, Thomas Knauth wrote:
> My question is where do I have to touch qemu to call my code for
> handling SIGSEGVs? Is this possible at all? Can anyone suggest
> alternative ways of tracking which pages of pc.ram are accessed?

Maybe you can use the dirty page tracking infrastructure?
memory_global_dirty_log_start()

Stefan

Re: [Qemu-devel] Capture SIGSEGV to track pc.ram page access

[Thomas Knauth]

As far as I understand the dirty logging infrastructure will only
record writes. I want to track reads as well.

A better way to express what I would like to do is trace all guest
physical addresses that are accessed. Again, I am unsure whether qemu
supports this out-of-the box and where I would have to add/modify the
source to do so.

Thanks for your help,
Thomas.

Re: [Qemu-devel] Capture SIGSEGV to track pc.ram page access

[Stefan Hajnoczi]

On Thu, Sep 26, 2013 at 02:53:54PM +0200, Thomas Knauth wrote:
> As far as I understand the dirty logging infrastructure will only
> record writes. I want to track reads as well.
> 
> A better way to express what I would like to do is trace all guest
> physical addresses that are accessed. Again, I am unsure whether qemu
> supports this out-of-the box and where I would have to add/modify the
> source to do so.

If you want to continue with the original SIGSEGV handler approach,
check signals masks for the vcpu threads.  Make sure the signal actually
gets delivered to a thread that has the signal unblocked and a signal
handler installed.

Regarding dirty logging, you could try modifying the KVM dirty logging
code to also trap reads.

Also take a look at /proc/PID/pagemap and documentation on accessing
this page table info.  It can be used for tracking dirty pages
("soft-dirty") but I'm not sure if it reports accessed pages.

Stefan

Re: [Qemu-devel] Capture SIGSEGV to track pc.ram page access

[Thomas Knauth]

On Fri, Sep 27, 2013 at 12:50 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> If you want to continue with the original SIGSEGV handler approach,
> check signals masks for the vcpu threads.  Make sure the signal actually
> gets delivered to a thread that has the signal unblocked and a signal
> handler installed.

I've been making some progress going the SIGSEGV handler route. I
succeeded in installing a signal handler, allocating memory with
mmap() and PROT_NONE for the pc.ram memory region. The signal handler
gets called, and I remove the protection one page at a time. So far so
good.

However, after handling about 50-60 SIGSEGV's the guest gets stuck in
a busy loop (100% CPU usage). Using gdb and a core dump I get the
below stack trace

#0  0x00007fcc0d6d8ea5 in fw_cfg_read (s=0x7fcc0f37cf00) at hw/fw_cfg.c:238
#1  0x00007fcc0d6d9049 in fw_cfg_comb_read (opaque=0x7fcc0f37cf00,
addr=1, size=1) at hw/fw_cfg.c:279
#2  0x00007fcc0d84e9ca in memory_region_read_accessor
(opaque=0x7fcc0f37f388, addr=1, value=0x7fcc07800d00, size=1, shift=0,
mask=255)
    at /mnt/myvg-data/home/thomas/phd/dreamserver/code/qemu/memory.c:316
#3  0x00007fcc0d84eb2f in access_with_adjusted_size (addr=1,
value=0x7fcc07800d00, size=1, access_size_min=1, access_size_max=4,
    access=0x7fcc0d84e970 <memory_region_read_accessor>, opaque=0x7fcc0f37f388)
    at /mnt/myvg-data/home/thomas/phd/dreamserver/code/qemu/memory.c:364
#4  0x00007fcc0d84eda7 in memory_region_iorange_read
(iorange=0x7fcc0f382af0, offset=1, width=1, data=0x7fcc07800d00)
    at /mnt/myvg-data/home/thomas/phd/dreamserver/code/qemu/memory.c:409
#5  0x00007fcc0d84875f in ioport_readb_thunk (opaque=0x7fcc0f382af0, addr=1297)
    at /mnt/myvg-data/home/thomas/phd/dreamserver/code/qemu/ioport.c:186
#6  0x00007fcc0d848361 in ioport_read (index=0, address=1297) at
/mnt/myvg-data/home/thomas/phd/dreamserver/code/qemu/ioport.c:70
#7  0x00007fcc0d848d9d in cpu_inb (addr=1297) at
/mnt/myvg-data/home/thomas/phd/dreamserver/code/qemu/ioport.c:309
#8  0x00007fcc0d84bf87 in kvm_handle_io (port=1297,
data=0x7fcc0d5bd000, direction=0, size=1, count=2832)

I only have very little knowledge of the lower level system internals
to see what could be an issue here. If I allocate the mmap()'ed region
with RWX permissions, everything works fine. So somehow the PROT_NONE
must be interfering with something else. Any hints what that something
could be?