Re: frequently ballooning results in qemu exit

From: Hanweidong <hanweidong@huawei.com>
To: Anthony PERARD <anthony.perard@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	Yanqiangjun <yanqiangjun@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: frequently ballooning results in qemu exit
Date: Thu, 14 Mar 2013 14:10:34 +0000	[thread overview]
Message-ID: <FAB5C136CA8BEA4DBEA2F641E3F536384A8B089B@szxeml538-mbx.china.huawei.com> (raw)
In-Reply-To: <5141A8B0.4050305@citrix.com>

> -----Original Message-----
> From: Anthony PERARD [mailto:anthony.perard@citrix.com]
> Sent: 2013年3月14日 18:39
> To: George Dunlap
> Cc: Hanweidong; xen-devel@lists.xen.org; Gonglei (Arei); Yanqiangjun;
> Andrew Cooper
> Subject: Re: [Xen-devel] frequently ballooning results in qemu exit
> 
> On 14/03/13 10:17, George Dunlap wrote:
> > On Wed, Mar 13, 2013 at 1:50 PM, Hanweidong <hanweidong@huawei.com>
> 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=<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. 

We found the failed address was got from an existed mapcache entry, not 
generated by xen_remap_bucket(). 

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