From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938708AbdDSTht (ORCPT ); Wed, 19 Apr 2017 15:37:49 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:32859 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934788AbdDSThl (ORCPT ); Wed, 19 Apr 2017 15:37:41 -0400 Date: Wed, 19 Apr 2017 20:37:38 +0100 From: Matt Fleming To: Daniel Kiper Cc: Mark Rutland , Julien Grall , Juergen Gross , Boris Ostrovsky , sstabellini@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xen.org, Ard Biesheuvel , linux-efi@vger.kernel.org Subject: Re: [PATCH] arm64: xen: Implement EFI reset_system callback Message-ID: <20170419193738.GM24360@codeblueprint.co.uk> References: <3f6f5853-cd08-8afc-f71a-b0c1545c7564@arm.com> <20170406142710.GE4372@olila.local.net-space.pl> <20170406152040.GH4372@olila.local.net-space.pl> <20170406155453.GA3966@leverpostej> <20170418134650.GL24360@codeblueprint.co.uk> <20170419192906.GO16658@olila.local.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170419192906.GO16658@olila.local.net-space.pl> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote: > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > > rather than spreading it further. > > > > > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > > > should provide an implementation. > > > > > > I don't see why you can't implement a wrapper that calls the usual Xen > > > poweroff/reset functions. > > > > I realise I'm making a sweeping generalisation, but adding > > EFI_PARAVIRT is almost always the wrong thing to do. > > Why? Because it makes paravirt a special case, and there's usually very little reason to make it special in the EFI code. Special-casing means more branches, more code paths, a bigger testing matrix and more complex code. EFI_PARAVIRT does have its uses, like for those scenarios where we don't have a table of function pointers that can be overidden for paravirt. But we do have such a table for ->reset_system(). From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Fleming Subject: Re: [PATCH] arm64: xen: Implement EFI reset_system callback Date: Wed, 19 Apr 2017 20:37:38 +0100 Message-ID: <20170419193738.GM24360@codeblueprint.co.uk> References: <3f6f5853-cd08-8afc-f71a-b0c1545c7564@arm.com> <20170406142710.GE4372@olila.local.net-space.pl> <20170406152040.GH4372@olila.local.net-space.pl> <20170406155453.GA3966@leverpostej> <20170418134650.GL24360@codeblueprint.co.uk> <20170419192906.GO16658@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170419192906.GO16658-fJNZiO034lp9pOct4yEdx/3oZC3j2Omk@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Daniel Kiper Cc: Mark Rutland , Julien Grall , Juergen Gross , Boris Ostrovsky , sstabellini-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, xen-devel-GuqFBffKawuEi8DpZVb4nw@public.gmane.org, Ard Biesheuvel , linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-efi@vger.kernel.org On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote: > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > > rather than spreading it further. > > > > > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > > > should provide an implementation. > > > > > > I don't see why you can't implement a wrapper that calls the usual Xen > > > poweroff/reset functions. > > > > I realise I'm making a sweeping generalisation, but adding > > EFI_PARAVIRT is almost always the wrong thing to do. > > Why? Because it makes paravirt a special case, and there's usually very little reason to make it special in the EFI code. Special-casing means more branches, more code paths, a bigger testing matrix and more complex code. EFI_PARAVIRT does have its uses, like for those scenarios where we don't have a table of function pointers that can be overidden for paravirt. But we do have such a table for ->reset_system(). From mboxrd@z Thu Jan 1 00:00:00 1970 From: matt@codeblueprint.co.uk (Matt Fleming) Date: Wed, 19 Apr 2017 20:37:38 +0100 Subject: [PATCH] arm64: xen: Implement EFI reset_system callback In-Reply-To: <20170419192906.GO16658@olila.local.net-space.pl> References: <3f6f5853-cd08-8afc-f71a-b0c1545c7564@arm.com> <20170406142710.GE4372@olila.local.net-space.pl> <20170406152040.GH4372@olila.local.net-space.pl> <20170406155453.GA3966@leverpostej> <20170418134650.GL24360@codeblueprint.co.uk> <20170419192906.GO16658@olila.local.net-space.pl> Message-ID: <20170419193738.GM24360@codeblueprint.co.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote: > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > > rather than spreading it further. > > > > > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > > > should provide an implementation. > > > > > > I don't see why you can't implement a wrapper that calls the usual Xen > > > poweroff/reset functions. > > > > I realise I'm making a sweeping generalisation, but adding > > EFI_PARAVIRT is almost always the wrong thing to do. > > Why? Because it makes paravirt a special case, and there's usually very little reason to make it special in the EFI code. Special-casing means more branches, more code paths, a bigger testing matrix and more complex code. EFI_PARAVIRT does have its uses, like for those scenarios where we don't have a table of function pointers that can be overidden for paravirt. But we do have such a table for ->reset_system().