From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 16AFDFD006A for ; Sun, 1 Mar 2026 15:04:57 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1243903.1543442 (Exim 4.92) (envelope-from ) id 1vwiLQ-0003VP-1f; Sun, 01 Mar 2026 15:04:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243903.1543442; Sun, 01 Mar 2026 15:04:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwiLP-0003VI-Tc; Sun, 01 Mar 2026 15:04:31 +0000 Received: by outflank-mailman (input) for mailman id 1243903; Sun, 01 Mar 2026 15:04:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwiLO-0003VC-1t for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 15:04:30 +0000 Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ee1dcc03-157f-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 16:04:23 +0100 (CET) Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id EF5351400041; Sun, 1 Mar 2026 10:04:21 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Sun, 01 Mar 2026 10:04:21 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 1 Mar 2026 10:04:20 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ee1dcc03-157f-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm3; t=1772377461; x=1772463861; bh=WE DyKPtzrdTYeQrs6sXaKHMHgxci7AQYZmlLMmwrR0c=; b=MOZckj4blRe6GpBJ9K mrFLHjWzhvxV6IfWrMeYsZv94I73ac4DisWR9mr4KIfWY6qe9MruhZm5BfVk8DlI qrGswbo6ttGYzCIYr8HJWwjj5a0XfLruQebDPGlt1JmAaLnDpu30jYeaoxzbASyz gpCPiho2r9CAO+QI4recP3De4mNH3V1/fg7Y3w+hORWaohNdrYQW0DfCMwENkaJN lqJXhPmfV7focWMPJ1MMtyw2BPU2CyAg16i+IrlNwHqRo4zB0VEstzZT88MnvUBt Imz8PHxQY8c8SUtSc3EfiNLlhLPeM+QJ8KlvB64JDeJSq62PpUycsdv7s0DdvuQ5 tehA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1772377461; x= 1772463861; bh=WEDyKPtzrdTYeQrs6sXaKHMHgxci7AQYZmlLMmwrR0c=; b=f kG6+E2VoodApJN/EJ8l7DI2H1dhuidCPTWV00X9B2K4adlBSduICjvJOcD1U54mO JcZ1eZ6VsLEDOJinDsZihX1KIbUYIJbKzHeKbu0j0wUv+LN/gKnKObCzcW7HvXts wKp9SXyJ2Yp8mzUJSvFY4854RXzyJL+0rDc1Mw9szORGOpieneM4KiaZmZNGhvjX WlHn8xHK/IR4Yj9catvZYjrFPRfeF9xxwoHGlhuC0HEWlk5YDBPIr9Ms0osDBdkl z1KGPsEkTd+CvSAhv90h+MG6v9usy8QeSjqXj+tpzWx+HOOzSfnYinH+avlYPz9K /ozYPZPF1qroMkGmflHBw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvheehuddtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhephfetuefhiefg tddtlefggffggeevhedtvdefffeugfeiieeiheefteefgefggeejnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd gtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphhtthho peigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtph htthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtohepsghorhhishdrohhs thhrohhvshhkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtoheprghkphhmsehlihhnuh igqdhfohhunhgurghtihhonhdrohhrghdprhgtphhtthhopegurghvihgusehkvghrnhgv lhdrohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Sun, 1 Mar 2026 16:04:17 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Juergen Gross , Boris Ostrovsky , Andrew Morton , David Hildenbrand Subject: Excluding init_on_free for pages for initial balloon down (Xen) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TuuO5D0SW37++uJS" Content-Disposition: inline --TuuO5D0SW37++uJS Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Mar 2026 16:04:17 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Juergen Gross , Boris Ostrovsky , Andrew Morton , David Hildenbrand Subject: Excluding init_on_free for pages for initial balloon down (Xen) Hi, Some time ago I made a change to disable scrubbing pages that are ballooned out during system boot. I'll paste the whole commit message as it's relevant here: 197ecb3802c0 xen/balloon: add runtime control for scrubbing ballooned o= ut pages Scrubbing pages on initial balloon down can take some time, especially in nested virtualization case (nested EPT is slow). When HVM/PVH guest = is started with memory=3D significantly lower than maxmem=3D, all the extra pages will be scrubbed before returning to Xen. But since most of them weren't used at all at that point, Xen needs to populate them first (from populate-on-demand pool). In nested virt case (Xen inside KVM) this slows down the guest boot by 15-30s with just 1.5GB needed to be returned to Xen. =20 Add runtime parameter to enable/disable it, to allow initially disabling scrubbing, then enable it back during boot (for example in initramfs). Such usage relies on assumption that a) most pages ballooned out during initial boot weren't used at all, and b) even if they were, very few secrets are in the guest at that time (before any serious userspace kicks in). Convert CONFIG_XEN_SCRUB_PAGES to CONFIG_XEN_SCRUB_PAGES_DEFAULT (also enabled by default), controlling default value for the new runtime switch. Now, I face the same issue with init_on_free/init_on_alloc (not sure which one applies here, probably the latter one), which several distributions enable by default. The result is (see timestamps): [2026-02-24 01:12:55] [ 7.485151] xen:balloon: Waiting for initial b= allooning down having finished. [2026-02-24 01:14:14] [ 86.581510] xen:balloon: Initial ballooning do= wn finished. But here the situation is a bit more complicated: init_on_free/init_on_alloc applies to any pages, not just those for balloon driver. I see two approaches to solve the issue: 1. Similar to xen_scrub_pages=3D, add a runtime switch for init_on_free/init_on_alloc, then force them off during boot, and re-enable early in initramfs. 2. Somehow adjust balloon driver to bypass init_on_alloc when ballooning a page out. The first approach is likely easier to implement, but also has some drawbacks: it may result in some kernel structures that are allocated early to remain with garbage data in uninitialized places. While it may not matter during early boot, such structures may survive for quite some time, and maybe attacker can use them later on to exploit some other bug. This wasn't really a concern with xen_scrub_pages, as those pages were immediately ballooned out. The second approach sounds architecturally better, and maybe init_on_alloc could be always bypassed during balloon out? The balloon driver can scrub the page on its own already (which is enabled by default). That of course assumes the issue is only about init_on_alloc, not init_on_free (or both) - which I haven't really confirmed yet... If going this way, I see the balloon driver does basically alloc_page(GFP_BALLOON), where GFP_BALLOON is: /* When ballooning out (allocating memory to return to Xen) we don't re= ally want the kernel to try too hard since that can trigger the oom kille= r. */ #define GFP_BALLOON \ (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC) Would that be about adding some new flag here? Or maybe there is already one for this purpose? Any opinions? PS issue tracked at https://github.com/QubesOS/qubes-issues/issues/10723 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --TuuO5D0SW37++uJS Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmkVXEACgkQ24/THMrX 1ywhmgf/eZeGTjx6//+hTB2Qy9RqzuXOwOQ6AfyQquM85TNDY4pn/smySDi3d6PL fHo5sweOijroW7tFUMeUQPO+7IewuVJo9OlE9wq09nM3J5KwiamrKDrgedaDuqP5 1Trg1sd4LV+qLNXvlHHZ49EuSoNzbz76ZBcHZQwqnGWF5L8Y9ruqQXPKpoi1MplN 5A2uOLr9QWYIrpYkMxl+8bMzlGWS+nhASDy4V/0R2ba5z6QzPS/4RMI/p65SalHI ZfiER1PFuL+bIo+SWciATW+SJgC5XmmMXPW3NbTrKVyFW8+tcu3u31pvJKivC5qy zvseR3nvv808lqmg/ErE6FXP7nRWWg== =Uy3v -----END PGP SIGNATURE----- --TuuO5D0SW37++uJS--