On Wed, 2015-09-23 at 00:37 +0200, Samuel Thibault wrote: > Andreas Sundstrom, le Mon 21 Sep 2015 22:03:22 +0200, a écrit : > > Note that my original thought was that this bug probably is within > > GRUB. > > It's probably in the GRUB implementation of loading the domU GRUB, since > you say that pvgrub1 loads it fine. > > > (XEN) domain_crash_sync called from entry.S: fault at ffff82d08021feb0 > > compat_create_bounce_frame+0xc6/0xde > > So it's inside xen entry code... > > > (XEN) Guest stack trace from esp=005a5ff0: > > This looks like the end of the stack > > > (XEN) 00000010 00000000 0001e019 00010046 0016b38b 0016b38a 0016b389 > > 0016b388 > > (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381 > > 0016b380 > [...] > > and this looks like a lot of consecutive numbers. Perhaps we simply > somehow overflow? Did you try giving less memory to the domU?
Along those lines, if the _host_ has buckets of RAM then might it be worth restricting it in case the issue is with getting MFNs which are not representably by the 32-bit PV interfaces? (IIRC the limit is ~160G due to the size of the m2p hole, a 32-bit MFN spans 16TB so it's unlikely to be that). Likewise maybe the issue is with full addresses which don't fit in a 32-bit number (which is maybe more likely to happen if grub uses a 1:1 mapping like I would guess it does), so limiting the host to <4GB might also be interesting? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel