On Fri, Sep 27, 2013 at 12:50 PM, Stefan Hajnoczi <stefa...@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?
