From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH v2] x86/shutdown: change default reboot method preference
Date: Fri, 13 Feb 2026 01:39:56 +0100 [thread overview]
Message-ID: <aY5y3GdZyd4j213N@mail-itl> (raw)
In-Reply-To: <20230915074347.94712-1-roger.pau@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 6390 bytes --]
On Fri, Sep 15, 2023 at 09:43:47AM +0200, Roger Pau Monne wrote:
> The current logic to chose the preferred reboot method is based on the mode Xen
> has been booted into, so if the box is booted from UEFI, the preferred reboot
> method will be to use the ResetSystem() run time service call.
>
> However, that method seems to be widely untested, and quite often leads to a
> result similar to:
>
> Hardware Dom0 shutdown: rebooting machine
> ----[ Xen-4.18-unstable x86_64 debug=y Tainted: C ]----
> CPU: 0
> RIP: e008:[<0000000000000017>] 0000000000000017
> RFLAGS: 0000000000010202 CONTEXT: hypervisor
> [...]
> Xen call trace:
> [<0000000000000017>] R 0000000000000017
> [<ffff83207eff7b50>] S ffff83207eff7b50
> [<ffff82d0403525aa>] F machine_restart+0x1da/0x261
> [<ffff82d04035263c>] F apic_wait_icr_idle+0/0x37
> [<ffff82d040233689>] F smp_call_function_interrupt+0xc7/0xcb
> [<ffff82d040352f05>] F call_function_interrupt+0x20/0x34
> [<ffff82d04033b0d5>] F do_IRQ+0x150/0x6f3
> [<ffff82d0402018c2>] F common_interrupt+0x132/0x140
> [<ffff82d040283d33>] F arch/x86/acpi/cpu_idle.c#acpi_idle_do_entry+0x113/0x129
> [<ffff82d04028436c>] F arch/x86/acpi/cpu_idle.c#acpi_processor_idle+0x3eb/0x5f7
> [<ffff82d04032a549>] F arch/x86/domain.c#idle_loop+0xec/0xee
>
> ****************************************
> Panic on CPU 0:
> FATAL TRAP: vector = 6 (invalid opcode)
> ****************************************
>
> Which in most cases does lead to a reboot, however that's unreliable.
It's not relevant anymore, but posting just for the posterity: I
just found yet another system where EFI ResetSystem() crashes. What's
interesting about it, it's rather new system - NUC 14 with Lunar Lake.
It crashes as follows:
(XEN) ----[ Xen-4.17.6 x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<0000000063907504>] 0000000063907504
(XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor
(XEN) rax: 000000006ff4da98 rbx: 000000006ff4dad0 rcx: 0000000000000001
(XEN) rdx: 000000000311100a rsi: 0000000000000000 rdi: 000000006ffb5080
(XEN) rbp: 0000000000000001 rsp: ffff82d0403ef958 r8: 0000000000000000
(XEN) r9: 000000006ffb5080 r10: 0000000000000836 r11: 0000000000000835
(XEN) r12: 0000000000000000 r13: 000000000311100a r14: 000000006ffb5080
(XEN) r15: 000000000000001f cr0: 0000000080050033 cr4: 0000000000d526e0
(XEN) cr3: 000000046d4e5000 cr2: 0000000063907504
(XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <0000000063907504> (0000000063907504):
(XEN) 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(XEN) Xen stack trace from rsp=ffff82d0403ef958:
(XEN) 000000006fff5b56 ffff82d04059c400 ffff83046f90eed0 0000000000000000
(XEN) 0000000000000014 0000000000000000 0000000000000002 0000000000000000
(XEN) 0000000000000086 0000000000000000 0000000000000001 0000000000000000
(XEN) ffff82d0403efb00 000000006ffb5080 000000006fff5bde ffff82d000000001
(XEN) 0000000000000000 000000000311100a 0000000000000000 0000000000000000
(XEN) ffff83046d500770 ffff83046d44d1f8 0000000000000000 0000000000000000
(XEN) 000000006ffb4844 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 000000006ffb4498 0000000000000001 0000000000000001 0000000000000046
(XEN) ffff83046f90ef84 0000000000000000 0000000000000000 0000000000000000
(XEN) 000000006ffad650 0000000000000000 0000000000000000 0000000000000000
(XEN) ffff82d0403efb00 0000000000000000 ffff82d0402884c9 ffff830000000000
(XEN) ffff82d0402888ac 0000000000000000 ffff82d0403efb40 0000000000000004
(XEN) 000000046d4e5000 000000005484f000 0000000000000004 ffff82d040444b20
(XEN) 0000000000000046 ffff82d040317b76 ffff82d040317c85 0000000000000000
(XEN) 0000000000000065 ffff83046d44d000 ffff82d0403172e7 00001388403efb58
(XEN) 000082d0403efb60 0000000000000000 0000000000000003 ffff83046d44d000
(XEN) 0000000000000003 ffff83046d44d1f8 0000000000000000 ffff82d0402277d5
(XEN) ffff82d040227851 ffff82d040206c27 ffff83046d44d000 0000000000054894
(XEN) 0000000000000000 0000000000054894 ffff82d0402d0a58 000000000046bb48
(XEN) Xen call trace:
(XEN) [<0000000063907504>] R 0000000063907504
(XEN) [<000000006fff5b56>] S 000000006fff5b56
(XEN) [<ffff82d0402884c9>] S runtime.c#efi_rs_enter.part.0+0xc9/0x120
(XEN) [<ffff82d0402888ac>] S efi_reset_system+0x4c/0x90
(XEN) [<ffff82d040317b76>] S __stop_this_cpu+0x16/0x40
(XEN) [<ffff82d040317c85>] S smp_send_stop+0xc5/0xe0
(XEN) [<ffff82d0403172e7>] S machine_restart+0x247/0x330
(XEN) [<ffff82d0402277d5>] S shutdown.c#maybe_reboot+0x35/0x40
(XEN) [<ffff82d040227851>] S hwdom_shutdown+0x71/0xc0
(XEN) [<ffff82d040206c27>] S domain_shutdown+0x47/0x100
(XEN) [<ffff82d0402d0a58>] S p2m_add_page+0x4f8/0x7d0
(XEN) [<ffff82d0403cb1a4>] S dom0_construct_pvh+0x3b4/0x1300
(XEN) [<ffff82d040250e00>] S xhci-dbc.c#dbc_uart_flush+0x50/0x60
(XEN) [<ffff82d04022974f>] S timer.c#add_entry+0x4f/0xc0
(XEN) [<ffff82d04031af7b>] S time.c#read_counter+0x1b/0x40
(XEN) [<ffff82d04031b10c>] S time.c#platform_time_calibration+0x1c/0x90
(XEN) [<ffff82d0403e5b23>] S construct_dom0+0x63/0xe0
(XEN) [<ffff82d0403dbd87>] S __start_xen+0x21a7/0x264a
(XEN) [<ffff82d040277284>] S __high_start+0x94/0xa0
(XEN)
(XEN) Pagetable walk from 0000000063907504:
(XEN) L4[0x000] = 000000046d4e4063 ffffffffffffffff
(XEN) L3[0x001] = 0000000054848063 ffffffffffffffff
(XEN) L2[0x11c] = 80000000638001e3 ffffffffffffffff (PSE)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0011]
(XEN) Faulting linear address: 0000000063907504
(XEN) ****************************************
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-02-13 0:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 7:43 [PATCH v2] x86/shutdown: change default reboot method preference Roger Pau Monne
2023-09-18 12:26 ` Jan Beulich
2023-09-18 15:09 ` Roger Pau Monné
2023-09-18 15:44 ` Jan Beulich
2023-09-18 16:00 ` Roger Pau Monné
2023-09-19 9:31 ` Jan Beulich
2023-09-19 10:29 ` Roger Pau Monné
2023-09-27 8:21 ` Jan Beulich
2023-10-03 11:35 ` Roger Pau Monné
2023-10-23 11:02 ` Roger Pau Monné
2024-07-29 22:08 ` Marek Marczykowski-Górecki
2026-02-13 0:39 ` Marek Marczykowski-Górecki [this message]
2026-02-13 7:54 ` Roger Pau Monné
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aY5y3GdZyd4j213N@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.