From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738 Date: Wed, 13 Sep 2017 09:56:18 +0200 Message-ID: <1505289378.3642.4.camel@citrix.com> References: <20170911235520.GA30969@localhost.localdomain> <7b76a7a2-90fd-f016-53b0-a36ef68ba1a4@oracle.com> <20170913000147.GA6632@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4170191271716996276==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ds2X9-0002wu-Jv for xen-devel@lists.xenproject.org; Wed, 13 Sep 2017 07:56:31 +0000 In-Reply-To: <20170913000147.GA6632@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Konrad Rzeszutek Wilk , Boris Ostrovsky Cc: xen-devel@lists.xenproject.org, julien.grall@arm.com, sstabellini@kernel.org List-Id: xen-devel@lists.xenproject.org --===============4170191271716996276== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-GQcGAHh9QEHI7HM7fx6G" --=-GQcGAHh9QEHI7HM7fx6G Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-09-12 at 20:01 -0400, Konrad Rzeszutek Wilk wrote: > > On 09/11/2017 07:55 PM, Konrad Rzeszutek Wilk wrote: > > > I've only been able to reproduce this on ARM64 (trying right now > > > ARM32 > > > as well), and not on x86. > > >=20 > > > If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But > > > if > > > enable it and try to load a livepatch it blows up in > > > page_alloc.c:738 > > >=20 > I honestly think the issue is that on ARM64 the "sleep" loop does not > wake up as often as on x86 (CC-ing Dariof who I believe observed this > with Credit2 and the wakeup.. something) - maybe he remembers the > details. Anyhow my theory is that the pages are not scrubbed at all > when they go in the idle loop as once it goes to sleep - it stays > there. >=20 > Ah, see commit 05c52278a7c92bc753d9fe32017e4961012b9f23=C2=A0 >=20 > Maybe this is related? > As Boris is saying, it really should not. In fact, having pages that needs scrubbing _prevents_ the CPU from becoming idle (and stopping the tick, if any). What we observed is that x86 periodically wakes up, even on a totally idle system, while ARM doesn't. But this should not be a problem as, in both cases, if there's pages to scrub, the CPU just won't go to sleep. If frequent wakeups is what causes the scrubbing to work ok on the x86, and not on ARM, it IMO means that there's something like a race somewhere. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-GQcGAHh9QEHI7HM7fx6G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJZuOSjAAoJEBZCeImluHPu6+MQAOOgu/q7VjfB0eT7ZfG93+Io Ye++Jcfect9YT3ZWxDzTTnW27OroWGTh9fxqEFyDRiBISdXHVDKN4y7fe/8Ybs3c +PrVZnBLyFeWM3NcllAIFTU6ToIO9MwSYQEGVcnP3K9wdI6FtsVlxTsGMqOSEn1g 3uSnU7WulGmJUYb+ndR521F6F8CxWH/YvTwM2ESIiZTG3vICCdA8Sf/etAFQxh67 0qnpGBnBnhn2UxACeTdrLC5UANZpeK+VGbOvQaPDl+qzfSR8ZwnHAneszbc8VJMf nM5TbgLMlr8MNf9e9kw/i12zjCyTMWM2aZe1SnLo9pkeBGqQbvCt1Ep9rGJmr2LG 7TrNdsLLaMXqFUMfExPY0KCUEyaWawzl1Ncd5a9mhqrAarG8I3uExDtv9Xm3WHJ8 gJQd4dyBg8vcBa34KuLnPN7Rq79lqGsEk19qdEjGTpKS7AXpGy6MmndDshUo+m+6 78UIS4S09FTYIQhkaGwU/fOjbEhO0sSMohoESwzhMMsOezJQmSX/JXd/TlutpEY4 4cV2PJmJPzDA+c01OpGuWAV/st1buRFdk8RERes+ixpi/Xu6o21CLxNejpvJiwGg LgXlI6ThQcUjTZ9aHWbqvy9vu5F0l2gHBxLmnavpfzxOgMnFbZYznYMihuZcV8ss NoHmU+pV6EtydL4U1upd =esTh -----END PGP SIGNATURE----- --=-GQcGAHh9QEHI7HM7fx6G-- --===============4170191271716996276== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============4170191271716996276==--