From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony PERARD Subject: Re: frequently ballooning results in qemu exit Date: Thu, 14 Mar 2013 10:38:40 +0000 Message-ID: <5141A8B0.4050305@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Andrew Cooper , "xen-devel@lists.xen.org" , "Gonglei (Arei)" , Yanqiangjun , Hanweidong List-Id: xen-devel@lists.xenproject.org On 14/03/13 10:17, George Dunlap wrote: > On Wed, Mar 13, 2013 at 1:50 PM, Hanweidong wrote: >> We created a 64bit SLES11 SP1 guest, and then used a script to change memory (using mem-set command) periodically (in 1 second): set 1G, set 2G, set 1G, set 2G, and so on. >> After a few minutes, we encountered QEMU exit due to SIGBUS error. Below is the call trace captured by gdb: >> >> 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=, addr=2042531840, buf=0x7fffa36accf8 "", len=4, is_write=true) at /usr/include/bits/string3.h:52 >> #2 0x00007f94fa747cf0 in rw_phys_req_item (rw=, val=, i=, req=, addr=) >> at /opt/new/tools/qemu-xen-dir/xen-all.c:709 >> #3 write_phys_req_item (val=, i=, req=, addr=) at /opt/new/tools/qemu-xen-dir/xen-all.c:720 >> #4 cpu_ioreq_pio (req=) 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 , writefds=0x7f94faeea820 , xfds=, ret=) at iohandler.c:125 >> #8 0x00007f94fa5ec51d in main_loop_wait (nonblocking=) at main-loop.c:418 >> #9 0x00007f94fa6616dc in main_loop () at vl.c:1770 >> #10 main (argc=, argv=, envp=) 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? -- Anthony PERARD