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

[Hanweidong <hanweidong@xxxxxxxxxx>]

> -----Original Message-----
> From: Anthony PERARD [mailto:anthony.perard@xxxxxxxxxx]
> Sent: 2013å3æ14æ 18:39
> To: George Dunlap
> Cc: Hanweidong; xen-devel@xxxxxxxxxxxxx; 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@xxxxxxxxxx>
> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel