[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/hvm: Fix boot on systems where HVM isn't available
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Sat, 5 Feb 2022 10:47:19 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZcG19WZEEaInoxE72n0JRMdTZ489sXc4DheM9r8Lovs=; b=FDLOJxd8w+eEttvIMYc+cQkcO5Fkl13n7a+q6haA1bWvQ/DfG9BKz5j/t75tk2HTx2SfwtI40kcbjCU7evyRynLGwwl08EkdyiVAuLXyp8S3nzp7S5nKaM7ckiReS8D+9kRNyBeeKAHlTkp0u6X9qm9Y5LfA7r/J3Ifw/oOLlYVca6m7+OfBAyOP9rud/nbNgkvog2MJNlrLYYBiVR6HzjVTsIfZBYCavCbbgYygW7m3gpZNp4UkJBymG12gMBGdyrvl5zx1QYtTGKuP0gGCRdBzJO1a4Ltgg3p7IVVbYAQpMJTl8EWcI/7aGMxV4AAaTleUmGlRA7j9vmBJYdMDUg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NDcv2xeNMntv10hFgxNp/TLCX8OthqM/HyXK0ukVaPlSzJenVcExj058dIODcQKMNRlZdTIHj7Pb/AA3omuON4oC0cUXYfFjAiR6epcYtipzJgHqQQHhfqvD49fc02YKUlqG9Yjyw1tWRwLetrfSmmcCLom7jFIRkKNoUvs2kicrk7csASIbpImg8/4y6Y17pONjAq7sUbxwd4q/bBJdSblXp3qj4RAiaOZInDZJqg34Loso8sK/TdsNK1kdsW+EIzWCmdzvqrzvqck6Lq5qntn9FrnOBVkJ9TYewxTKLzGOGvaUdnpPQwc5fG58GtYazwfZ5vdowwPctD8IjlNh5A==
- Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Sat, 05 Feb 2022 09:47:46 +0000
- Ironport-data: A9a23:Ky8Qga6sbIMvvP+rSi3z+QxRtN7AchMFZxGqfqrLsTDasY5as4F+v jEeWGHVOq3YYWSmfNp3aNi3pBgP75OEnIRnTFA4pSE2Hi5G8cbLO4+Ufxz6V8+wwmwvb67FA +E2MISowBUcFyeEzvuV3zyIQUBUjclkfJKlYAL/En03FV8MpBsJ00o5wbZj2tMw2LBVPivW0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pGTU2FFFPqQ5E8IwKPb 72rIIdVXI/u10xF5tuNyt4Xe6CRK1LYFVDmZnF+A8BOjvXez8CbP2lS2Pc0MC9qZzu1c99Z7 /trpMC6WSYSB7TTntkPUBlbPCBYBPgTkFPHCSDXXc27ykTHdz3nwul0DVFwNoodkgp1KTgQr 7pCcmlLN03dwbLtqF64YrAEasALNs7kMZlZonh95TrYEewnUdbIRKCiCdpwgmxs2ZoRQK+2i 8wxNDpNNwTRckV2YkoHKosdvtaNh3P9fGgNwL6SjfVuuDWCpOBr65DyNPLFd9rMQt9a9m66j G/b+2XyAjkBKceSjzGC9xqEluLJ2C/2Ro8WPLm57eJxxk2ewHQJDx8bXkf9puO24nNSQPoGd RZSoHB36/Fvqgr7FbERQiFUvlajkDgNB9BAMtYD8R6L97jX4wW2B049G2sphMMdiOc6Qjkj1 1msltzvBCByvLD9dU9x5ot4vhvpZ3FLcDZqiTssCFJcvoK9+N1bYgfnE447eJNZmOEZDt0ZL 9qiiCElz4segscQv0lQ1QCW2mn8znQlo+Nc2+k2Yo5Hxl4hDGJGT9bxgbQ+0RqmBNzEJrVml CNc8/VyFMhUUfmweNWlGY3h5o2B6fefKyH7ilVyBZQn/DnF0yf9IdwIuGkhexkxbpZsldrVj Kn74145CHh7ZyPCUEOKS9jpV5RCIVbISbwJqcw4nvIRO8MsJWdrDQllZFKK3nCFraTfufpXB HtvSu71VSxyIf0+lFKeHr5BuZd2lnFW7T6CHvjTkkX4uZLAPyT9YelebzOzghURsfrsTPP9q I0EaaNnCnx3DYXDX8Ug2dRPdABRcylnWsyeRg4+XrfrHzeK0VoJUpf56bggZ5Zkj+JSkOLJ9 Wu6QUhW1Bz0gnivFOlAQikLhGrHUcktoHQlEzYrOFr0iXEvbZz2tPUUdoctfKlh/+tmlKYmQ /4AcsSGI/JOVjWYpGhNMcij9NRvJEaxmAaDHyu5ezxjLZRucBPEp43/dQz1+ShQUifu7Zkio 6et3x/wSIYYQ1gwF97fbf+ilgvjvXUUlO9ocVHPJ91fJBfl/IRwcnSjhf4rOcAcbx7Ew2LCh QqRBB4Zo8jLopM0r4aV1fzV8d/xHrInTERAHmTd4bKnDgXg/zKukd1aTeKFXTHBT2eoqq+sU vpYkqPnO/odkVcU74clS+R3zbgz7sfErqNBylg2B23CalmmB+8yInSC2sUT5KRByqUA5FmzU 0OLvNJbJa+IKIXuF1tIfFgpaeGK1Pc1nDjO7KtqfBWmtXEvpLfXA19POxSsiTBGKOonOYwo9 u4tpcoK5lHtkREtKNuH0nhZ+mnkwqbsiEn7WkX22LPWtzc=
- Ironport-hdrordr: A9a23:SwjlzqOFxF3Bh8BcTv+jsMiBIKoaSvp037BN7TEXdfU1SL39qy nApoV46faZslYssRIb+OxoWpPwJ080nKQdieN9UYtKNDOWwVdAR7sSiLcKrQeQeBEW39QtrZ uJLMNFY+EYd2IVsS9R2njCLz9a+ra6zJw=
- Ironport-sdr: rVg03h7mJbN6QyslJ+L5yjrufcTDfVFPflsaGWqCf5VxhTHRR3YochAhypqwMRFexDhzINSmWG 2TykpVVegeJf42tM0KYrVdvStiB7gSQi/2rAUzxBq1wYrLcqTIEHX7KGhF+T3NMAXXpI5uGZ3j 8TUnTDbqZCngpH2XL6h8hvYLrlPsTJFXU4JZwbmyYT10LWkvyYjC/XXEUGN5TeM6UIZoI/kFhz qGJeJGAPMmnyfMQC4ntbNvHBj7P3cZMv6zA4DOlJpYJELvwmBuMMGxapito6SjYbTJ6Gr4Afu/ STVJj09IcLA9ORn+3pTiM7LG
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, Feb 04, 2022 at 05:34:05PM +0000, Andrew Cooper wrote:
> c/s 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations to
> alt-call") went too far with dropping NULL function pointer checks.
>
> smp_callin() calls hvm_cpu_up() unconditionally. When the platform doesn't
> support HVM, hvm_enable() exits without filling in hvm_funcs, after which the
> altcall pass nukes the (now unconditional) indirect call, causing:
>
> (XEN) ----[ Xen-4.17.0-10.18-d x86_64 debug=y Not tainted ]----
> (XEN) CPU: 1
> (XEN) RIP: e008:[<ffff82d04034bef5>] start_secondary+0x393/0x3b7
> (XEN) RFLAGS: 0000000000010086 CONTEXT: hypervisor
> ...
> (XEN) Xen code around <ffff82d04034bef5> (start_secondary+0x393/0x3b7):
> (XEN) ff ff 8b 05 1b 84 17 00 <0f> 0b 0f ff ff 90 89 c3 85 c0 0f 84 db fe
> ff ff
> ...
> (XEN) Xen call trace:
> (XEN) [<ffff82d04034bef5>] R start_secondary+0x393/0x3b7
> (XEN) [<ffff82d0402000e2>] F __high_start+0x42/0x60
>
> To make matters worse, __stop_this_cpu() calls hvm_cpu_down() unconditionally
> too, so what happen next is:
>
> (XEN) ----[ Xen-4.17.0-10.18-d x86_64 debug=y Not tainted ]----
> (XEN) CPU: 0
> (XEN) RIP: e008:[<ffff82d04034ab02>] __stop_this_cpu+0x12/0x3c
> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor
> ...
> (XEN) Xen code around <ffff82d04034ab02> (__stop_this_cpu+0x12/0x3c):
> (XEN) 48 89 e5 e8 8a 1d fd ff <0f> 0b 0f ff ff 90 0f 06 db e3 48 89 e0 48
> 0d ff
> ...
> (XEN) Xen call trace:
> (XEN) [<ffff82d04034ab02>] R __stop_this_cpu+0x12/0x3c
> (XEN) [<ffff82d04034ac15>] F smp_send_stop+0xdd/0xf8
> (XEN) [<ffff82d04034a229>] F machine_restart+0xa2/0x298
> (XEN) [<ffff82d04034a42a>] F
> arch/x86/shutdown.c#__machine_restart+0xb/0x11
> (XEN) [<ffff82d04022fd15>] F smp_call_function_interrupt+0xbf/0xea
> (XEN) [<ffff82d04034acc6>] F call_function_interrupt+0x35/0x37
> (XEN) [<ffff82d040331a70>] F do_IRQ+0xa3/0x6b5
> (XEN) [<ffff82d04039482a>] F common_interrupt+0x10a/0x120
> (XEN) [<ffff82d04031f649>] F __udelay+0x3a/0x51
> (XEN) [<ffff82d04034d5fb>] F __cpu_up+0x48f/0x734
> (XEN) [<ffff82d040203c2b>] F cpu_up+0x7d/0xde
> (XEN) [<ffff82d0404543d3>] F __start_xen+0x200b/0x2618
> (XEN) [<ffff82d0402000ef>] F __high_start+0x4f/0x60
>
> which recurses until hitting a stack overflow. The #DF handler, which resets
> its stack on each invocation, loops indefinitely.
>
> Reinstate the NULL function pointer checks for hvm_cpu_{up,down}().
>
> Fixes: 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations
> to alt-call")
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
>
> RFC. Not tested yet on the imacted hardware. It's a Xeon PHI with another
> werid thing in need of debugging. First boot is fine, while second
> boot (loading microcode this time) has a problem with vmx.
>
> I wonder if we want to modify the callers to check for HVM being enabled,
> rather than leaving the NULL pointer checks in a position where they're liable
> to be reaped again.
What about adding a couple of comments to hvm_cpu_{up,down} to note
they are called unconditionally regardless of whether HVM is present
or not?
Thanks, Roger.
|