From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752700AbcASMEq (ORCPT ); Tue, 19 Jan 2016 07:04:46 -0500 Received: from smtp.citrix.com ([66.165.176.89]:49084 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbcASMEi (ORCPT ); Tue, 19 Jan 2016 07:04:38 -0500 X-IronPort-AV: E=Sophos;i="5.22,317,1449532800"; d="scan'208";a="326100913" Date: Tue, 19 Jan 2016 12:03:59 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mark Rutland CC: Stefano Stabellini , Shannon Zhao , , , , , , , , , , , , , , Jan Beulich , Ian Campbell Subject: Re: [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime services In-Reply-To: <20160118182747.GR21067@leverpostej> Message-ID: References: <1452840929-19612-1-git-send-email-zhaoshenglong@huawei.com> <1452840929-19612-17-git-send-email-zhaoshenglong@huawei.com> <20160118110854.GG21067@leverpostej> <20160118182747.GR21067@leverpostej> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Jan 2016, Mark Rutland wrote: > On Mon, Jan 18, 2016 at 05:45:24PM +0000, Stefano Stabellini wrote: > > On Mon, 18 Jan 2016, Mark Rutland wrote: > > > On Fri, Jan 15, 2016 at 02:55:29PM +0800, Shannon Zhao wrote: > > > > +void __init xen_efi_runtime_setup(void) > > > > +{ > > > > + efi.get_time = xen_efi_get_time; > > > > + efi.set_time = xen_efi_set_time; > > > > + efi.get_wakeup_time = xen_efi_get_wakeup_time; > > > > + efi.set_wakeup_time = xen_efi_set_wakeup_time; > > > > + efi.get_variable = xen_efi_get_variable; > > > > + efi.get_next_variable = xen_efi_get_next_variable; > > > > + efi.set_variable = xen_efi_set_variable; > > > > + efi.query_variable_info = xen_efi_query_variable_info; > > > > + efi.update_capsule = xen_efi_update_capsule; > > > > + efi.query_capsule_caps = xen_efi_query_capsule_caps; > > > > + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; > > > > + efi.reset_system = NULL; > > > > +} > > > > > > How do capsules work in the absence of an EFI system reset? > > > > Actually I don't think that capsules are available in Xen on ARM64 yet, > > see "TODO - disabled until implemented on ARM" in > > xen/common/efi/runtime.c. > > > > FYI system reset is available, but it is provided via a different > > mechanism (HYPERVISOR_sched_op(xen_restart...) > > Will that trigger Xen to do the right thing to trigger capsule updates > when implemented in Xen? Or do we need a xen_efi_reset_system? On ARM, to reboot the hardware, Xen calls the native PSCI system_reset method. On x86, Xen calls efi_reset_system on EFI systems, and has several fall backs if that doesn't work as expected (see xen/arch/x86/shutdown.c:machine_restart). But on a second look it doesn't look like that the capsule hypercalls are implemented correctly even on x86 (there is an "XXX fall through for now" comment in the code). I guess they are not available on Xen at all unfortunately. > Does that override PSCI? It does not, HYPERVISOR_sched_op(xen_restart,) is in addition to it. It ends up calling the same function within Xen as PSCI system_reset. > In machine_restart we try efi_reboot first specifically to allow for > capsule updates. Similarly drivers/firmware/efi/reboot.c registers > efi_power_off late in order to override anything else, though that's > best-effort at present. That's very interesting. I think that Xen on ARM should follow what Linux does and what Xen already does on x86 and try efi_reset_system first on efi systems.