From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [xen-unstable test] 36728: regressions - FAIL Date: Thu, 26 Mar 2015 09:04:51 +0000 Message-ID: <5513D9C3020000780006DC8E@mail.emea.novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yb3ig-0003q2-FC for xen-devel@lists.xenproject.org; Thu, 26 Mar 2015 09:04:54 +0000 In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 26.03.15 at 05:36, wrote: > flight 36728 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/36728/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-credit2 12 guest-localmigrate fail REGR. vs. 36514 > test-amd64-amd64-xl 12 guest-localmigrate fail REGR. vs. 36514 > test-amd64-amd64-xl-multivcpu 12 guest-localmigrate fail REGR. vs. 36514 Considering (XEN) mm.c:759:d2v0 Bad L1 flags 400000 (XEN) mm.c:5028:d2v0 ptwr_emulate: could not get_page_from_l1e() (XEN) Pagetable walk from ffff88001e81afd8: (XEN) L4[0x110] = 00000000be59b067 ffffffffffffffff (XEN) L3[0x000] = 00000000be59a067 ffffffffffffffff (XEN) L2[0x0f4] = 00000000be590067 ffffffffffffffff (XEN) L1[0x01a] = 80000000bf915025 000000000001e81a (XEN) domain_crash_sync called from entry.S: fault at ffff82d080235094 create_bounce_frame+0x74/0x148 (XEN) Domain 2 (vcpu#0) crashed on cpu#3: these are almost certainly the result of d639e6a05a ("x86: allow 64-bit PV guest kernels to suppress user mode exposure of M2P"), unless this is a kernel side issue that somehow managed to pass the push gate there. However, the registers and stack dumped don't show anything that looks like a PTE with flag bit 22 (_PAGE_GNTTAB) set. Nor does said change have anything to do with that flag. (In each case there is one value on the stack that looks like a valid PTE one, but which doesn't have said flag set.) What's additionally odd is that the L4, L3, and L2 entries dumped don't have a valid physical address associated with them. IOW I'm a little lost for the moment, as I can't immediately see a connection, not even a remote one. I'll see that I can find time later today or tomorrow to think some more about his, but in the meantime unless others have a good idea I'll wait for the bisector to confirm the suspicion, or in the worst case revert tomorrow just in case (as I'll be gone for the coming two weeks). Jan