Re: [Xen-devel] frequently ballooning results in qemu exit

[Tim Deegan <tim@xxxxxxx>]

At 14:10 +0000 on 14 Mar (1363270234), Hanweidong wrote:
> > >> The call trace:
> > >> Program received signal SIGBUS, Bus error.
> > >> 0x00007f94f74773d7 in memcpy () from /lib64/libc.so.6
> > >> (gdb) bt
> > >> #0  0x00007f94f74773d7 in memcpy () from /lib64/libc.so.6
> > >> #1  0x00007f94fa67016d in address_space_rw (as=<optimized out>,
> > addr=2042531840, buf=0x7fffa36accf8 "", len=4, is_write=true) at
> > /usr/include/bits/string3.h:52
> > >> #2  0x00007f94fa747cf0 in rw_phys_req_item (rw=<optimized out>,
> > val=<optimized out>, i=<optimized out>, req=<optimized out>,
> > addr=<optimized out>)
> > >>     at /opt/new/tools/qemu-xen-dir/xen-all.c:709
> > >> #3  write_phys_req_item (val=<optimized out>, i=<optimized out>,
> > req=<optimized out>, addr=<optimized out>) at /opt/new/tools/qemu-xen-
> > dir/xen-all.c:720
> > >> #4  cpu_ioreq_pio (req=<optimized out>) at /opt/new/tools/qemu-xen-
> > dir/xen-all.c:736
> > >> #5  handle_ioreq (req=0x7f94fa464000) at /opt/new/tools/qemu-xen-
> > dir/xen-all.c:793
> > >> #6  0x00007f94fa748abe in cpu_handle_ioreq (opaque=0x7f94fb39d3f0)
> > at /opt/new/tools/qemu-xen-dir/xen-all.c:868
> > >> #7  0x00007f94fa5e3262 in qemu_iohandler_poll
> > (readfds=0x7f94faeea7a0 <rfds>, writefds=0x7f94faeea820 <wfds>,
> > xfds=<optimized out>, ret=<optimized out>) at iohandler.c:125
> > >> #8  0x00007f94fa5ec51d in main_loop_wait (nonblocking=<optimized
> > out>) at main-loop.c:418
> > >> #9  0x00007f94fa6616dc in main_loop () at vl.c:1770
> > >> #10 main (argc=<optimized out>, argv=<optimized out>,
> > envp=<optimized out>) at vl.c:3999
> > >>
> > >> It looks mapcache has something wrong because memcpy failed with the
> > address from mapcache. Any ideas about this issue? Thanks!
> > >
> > > Which version of Xen and qemu are you using?  In particular,
> > > qemu-upstream (aka qemu-xen) or qemu-traditional?  And what guest are
> > > you using?  Is there anything on the xen console (either via the
> > > serial port or 'xl dmesg')?
> > >
> > > At first glance it looks like maybe qemu is trying to access, via the
> > > mapcache, pages which have been ballooned out.  But it seems like it
> > > should only be doing so in response to a guest request -- is this
> > > correct, Anthony?
> > 
> > Yes, this look like a guest IO request. One things I don't know is what
> > happen if there is guest addresses present in the mapcache that have
> > been balloon out, then but back in the guest, are those addresses in
> > mapcache still correct?
> > 
> 
> I'm also curious about this. There is a window between memory balloon out 
> and QEMU invalidate mapcache. 

That by itself is OK; I don't think we need to provide any meaningful
semantics if the guest is accessing memory that it's ballooned out. 

The question is where the SIGBUS comes from: either qemu has a mapping
of the old memory, in which case it can write to it safely, or it
doesn't, in which case it shouldn't try.

Is this running on a linux kernel?  ISTR some BSD kernels would
demand-populate foreign mappings, which might fail like this.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel