From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932789AbcEQML3 (ORCPT ); Tue, 17 May 2016 08:11:29 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:35631 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932757AbcEQMLZ (ORCPT ); Tue, 17 May 2016 08:11:25 -0400 Date: Tue, 17 May 2016 13:11:22 +0100 From: Matt Fleming To: Alex Thorlton Cc: linux-kernel@vger.kernel.org, Dimitri Sivanich , Russ Anderson , Mike Travis , Borislav Petkov , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-efi@vger.kernel.org, Mark Rutland Subject: Re: [PATCH 1/2] Create UV efi_call macros Message-ID: <20160517121122.GC21993@codeblueprint.co.uk> References: <1462996545-98387-1-git-send-email-athorlton@sgi.com> <1462996545-98387-2-git-send-email-athorlton@sgi.com> <20160512120600.GF2728@codeblueprint.co.uk> <20160516225840.GL98477@stormcage.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160516225840.GL98477@stormcage.americas.sgi.com> 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 Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote: > > I was simply re-using the efi_call implementation. Boris suggested that > I re-write this using the efi_call_virt macro, so I just went with that. > It all seems to work just fine, so I don't see much reason to stray away > from that implementation. That being said, I'm obviously not a huge fun > of the code duplication across the macros. I think there's probably a > way to minimize this, though I haven't quite worked out the best method > yet (ideas are welcome :) The reason I'm pressing for details is that we have a related issue with the EFI thunking code (CONFIG_EFI_MIXED), where the function pointer we want to call isn't accessible via the EFI System Table, see efi_thunk(). Well, technically it *is* accessible, you just can't dereference the services at runtime because the pointers in the tables are not 64-bit. But the same constraints exist for EFI thunk and UV code; given a function pointer to execute that isn't in efi.systab, setup the EFI runtime environment and call a custom ABI function. I haven't tested this (or thought through all the implications), but could you look at providing a table (or something) for mapping a function name to a ptr,func pair, e.g. thunk_get_time: runtime_services32(get_time), efi64_thunk thunk_set_time: runtime_services32(set_time), efi64_thunk ... uv_call_func: efi.uv_systab->function, uv_efi_call_virt which we could use in arch_efi_call_virt()? That should give us much less code duplication and hide all this inside arch/x86.