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 X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72FF0C433EF for ; Mon, 13 Sep 2021 12:50:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4CCFA60FBF for ; Mon, 13 Sep 2021 12:50:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235538AbhIMMvZ (ORCPT ); Mon, 13 Sep 2021 08:51:25 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:55959 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234945AbhIMMvX (ORCPT ); Mon, 13 Sep 2021 08:51:23 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 53C05320089C; Mon, 13 Sep 2021 08:50:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 13 Sep 2021 08:50:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=+ThLjayzZvSuiYey9xMndGiL316IC WP/XAzfhhK/XQ4=; b=QST6alfCdjmOCJeMGPiFrbgPY5XjwFUFGqt7uplIpJaKM eOo5VPdGZNeqchyNdUioX5D59OJCHQqjuJCpn2yZfUjxMNzZqYGD7oXSBKnRlcjE +/gBKlFfB7clEc1X4X896LpSW/ZoR4FZo6+ZIEP9esVsj2Qq+gb+T8IoxBfdT04P X2jATdlr+XyVZ8O8jnV7F7Uc7jsdp2zzPvBBMDH10d1WtW/EkERxHxOB0wKokST/ 9ONDWkrRpMjK6EHU8xe6DkOtmwcq6+WkrTki4K8XG8VLVZR6wlzcA7pA6vhnFAL7 gDgFNGUrdNlU1rCoW3NxnbG8NlC5AxEv/yKdGmB9g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegjedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggusehgtderredttdejnecuhfhrohhmpeforghrvghkucfo rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeklefhveej teeghfeiteevtddtueffieehgfelgfevffejveeuffdvgeffgeevkeenucffohhmrghinh epghhithhhuhgsuhhsvghrtghonhhtvghnthdrtghomhdpkhgvrhhnvghlrdhorhhgnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrg hrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Sep 2021 08:50:04 -0400 (EDT) Date: Mon, 13 Sep 2021 14:50:00 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Mike Rapoport Cc: Ingo Molnar , Borislav Petkov , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org, xen-devel Subject: Linux 5.13+ as Xen dom0 crashes on Ryzen CPU (ucode loading related?) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5CWEI5nLGyVosQus" Content-Disposition: inline Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --5CWEI5nLGyVosQus Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Sep 2021 14:50:00 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Mike Rapoport Cc: Ingo Molnar , Borislav Petkov , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org, xen-devel Subject: Linux 5.13+ as Xen dom0 crashes on Ryzen CPU (ucode loading related?) Hi, Since 5.13, the Xen (PV) dom0 crashes on boot, before even printing the kernel version. Test environment: - Xen 4.14.2 - AMD Ryzen 5 4500U (reported also on AMD Ryzen 7 4750U) - Linux 5.13.13, confirmed also on 5.14 The crash happens only if the initramfs has earlycpio with microcode. I don't have a serial console, but I've got a photo with crash message (from Xen, Linux doesn't managed to print anything): https://user-images.githubusercontent.com/726704/133084966-5038f37e-001b-46= 88-9f90-83d09be3dc2d.jpg Transcription of some of it: mapping kernel into physical memory about to get started (XEN) Pagetable walk from ffffffff82810888: (XEN) L4[0x1ff] =3D 0000000332815067 0000000000002815 (XEN) L3[0x1fe] =3D 0000000332816067 0000000000002816 (XEN) L2[0x014] =3D 0000000334018067 0000000000004018 (XEN) L1[0x010] =3D 0000000332810067 0000000000002810 (XEN) domain_crash_sync called from entry.S: fault at ffff82d04033e790 = x86_64/entry.S#domain_crash_page_fault (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-4.14.2 x86_64 debug=3Dn Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e033:[<0000000000000000>] I've bisected it down to the commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d x86/setup: Consolidate early memory reservations The early reservations of memory areas used by the firmware, bootloader, kernel text and data are spread over setup_arch(). Moreover, some of th= em happen *after* memblock allocations, e.g trim_platform_memory_ranges() = and trim_low_memory_range() are called after reserve_real_mode() that alloc= ates memory. There was no corruption of these memory regions because memblock always allocates memory either from the end of memory (in top-down mode) or ab= ove the kernel image (in bottom-up mode). However, the bottom up mode is go= ing to be updated to span the entire memory [1] to avoid limitations caused= by KASLR. Consolidate early memory reservations in a dedicated function to improve robustness against future changes. Having the early reservations in one place also makes it clearer what memory must be reserved before memblock allocations are allowed. Signed-off-by: Mike Rapoport Signed-off-by: Borislav Petkov Reviewed-by: Baoquan He Acked-by: Borislav Petkov Acked-by: David Hildenbrand Link: [1] https://lore.kernel.org/lkml/20201217201214.3414100-2-guro@fb= =2Ecom Link: https://lkml.kernel.org/r/20210302100406.22059-2-rppt@kernel.org Since this seems to affect Xen boot only, I'm copying xen-devel too. Any ideas? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --5CWEI5nLGyVosQus Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmE/SPgACgkQ24/THMrX 1yyKTAf/RFLXnOX6sQx74ErcNKHowyeAVTrcIbactKB5dIcODunG+9eHXFR/HSk/ 7ywnpCcFHZCjha5xx+ShTaskQ89yDEiE9jLIFwR7sQKxucRXoCcAAkJufYYxRbbQ qYHUrOFFXeNFtEc73mZrbfqguc3y8Xm6BYBdzcHcgVk+bZCD5BY8A+A0FdKbm0rM 1E+AfbfIdN5avDDxBgy3xa+DVF1ksmZwZ4tbKDizZ2azkK+WMgPL6h+Hk718OA86 9TAXsPlotdMBsYFcFDvXBkKDQYN42+y/A6DOFmasUTsGw0xFroU/YpfarKnWq9OZ w7lWKDBmRMV8wH25LAIXltai+6G1tA== =GguL -----END PGP SIGNATURE----- --5CWEI5nLGyVosQus--