[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] x86/shutdown: change default reboot method preference


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 27 Sep 2023 10:21:44 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; 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=nWCqfDehM3YUSBk0KmVd4+CDG+IAxqCox5qWG6PRgl8=; b=UHuj+tvIfMrw55jYa9JPZE2GwUj5s3Uubp02oEtMNTidKGnx9thbsWhP/RSB19joETpJop+ehix9ufDUaNgpf8dgnnyweK9AisHUVN5zT4L3mAByL5p0KubVzPekQUj7pOyJJX9iDu+AhQVvqGQazEUb7ELQu52Hmirmtj3Z7OjCuqFHNYBcPUeXO1/jYglw7aVLTM83ttrJao7eCGkvlkshXesnTqiidV4OTz0e8c3GXcqWLq0jQE615EVMa7bQX2fsapiyTFPl4BozndvNqnKaLZgQgcp7wKozS5Z2xRaknt3KWCjaKL7C+MO9YsAZv6zm0oeMbNhsPVaOK96Wdw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eOMcSj4aJAnWbxXD79EjBwc3wArn22rO3A67btnyOg377885mvgKMicy8EDZF67zpbvpI/ydAxDyIJ9B+zqtJLitd1P5rbTOaMzXSvYm9xZ2h1yings9uYZ6U6xkaqGSnDV2NDPyMVM8WMBXWJ59pZkPVGCmks7Vbd53znA/l25+C9p9U+QwsPjIJQpKgoKVES7HBU/hNVfVoXKa13Vw8Y7fHsoCBK4GeKWnp+5nWV7uR2IHgccTpPKrATq/u5nwozPBaVVZtzr62nquCkxBfq+WBTtMNEKickFra8yCIK0UI8MkFgmmsSn2zj+L4DhtwakR0uBG4ploOQWrgkbHgw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 27 Sep 2023 08:22:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15.09.2023 09:43, 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.
> 
> Change the default reboot preference to prefer ACPI over UEFI if available and
> not in reduced hardware mode.
> 
> This is in line to what Linux does, so it's unlikely to cause issues on 
> current
> and future hardware, since there's a much higher chance of vendors testing
> hardware with Linux rather than Xen.
> 
> Add a special case for one Acer model that does require being rebooted using
> ResetSystem().  See Linux commit 0082517fa4bce for rationale.
> 
> I'm not aware of using ACPI reboot causing issues on boxes that do have
> properly implemented ResetSystem() methods.

A data point from a new system I'm still in the process of setting up: The
ACPI reboot method, as used by Linux, unconditionally means a warm reboot.
The EFI method, otoh, properly distinguishes "reboot=warm" from our default
of explicitly requesting cold reboot. (Without taking the EFI path, I
assume our write to the relevant BDA location simply has no effect, for
this being a legacy BIOS thing, and the system apparently defaults to warm
reboot when using the ACPI method.)

Clearly, as a secondary effect, this system adds to my personal experience
of so far EFI reboot consistently working on all x86 hardware I have (had)
direct access to. (That said, this is the first non-Intel system, which
likely biases my overall experience.)

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.