Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754030AbdDFIcq (ORCPT ); Thu, 6 Apr 2017 04:32:46 -0400 Received: from foss.arm.com ([217.140.101.70]:39016 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752241AbdDFIcf (ORCPT ); Thu, 6 Apr 2017 04:32:35 -0400 Subject: Re: [PATCH] arm64: xen: Implement EFI reset_system callback To: Juergen Gross , Boris Ostrovsky , xen-devel@lists.xen.org References: <20170405181417.15985-1-julien.grall@arm.com> Cc: sstabellini@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Daniel Kiper From: Julien Grall Message-ID: <3f6f5853-cd08-8afc-f71a-b0c1545c7564@arm.com> Date: Thu, 6 Apr 2017 09:32:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1084 Lines: 39 Hi Juergen, On 06/04/17 07:23, Juergen Gross wrote: > On 05/04/17 21:49, Boris Ostrovsky wrote: >> On 04/05/2017 02:14 PM, Julien Grall wrote: >>> The x86 code has theoritically a similar issue, altought EFI does not >>> seem to be the preferred method. I have left it unimplemented on x86 and >>> CCed Linux Xen x86 maintainers to know their view here. >> >> (+Daniel) >> >> This could be a problem for x86 as well, at least theoretically. >> xen_machine_power_off() may call pm_power_off(), which is efi.reset_system. >> >> So I think we should have a similar routine there. > > +1 > > I don't see any problem with such a routine added, in contrast to > potential "reboots" instead of power off without it. > > So I think this dummy xen_efi_reset_system() should be added to > drivers/xen/efi.c instead. I will resend the patch during day with xen_efi_reset_system moved to common code and implement the x86 counterpart (thought, I will not be able to test it). > >>> This should also probably be fixed in stable tree. > > Yes. I will CC stable. Thank you, -- Julien Grall