Re: [PATCH v3 1/5] efi: Add efi_init_ops variable
On Tue, 25 Mar, at 09:57:52PM, Daniel Kiper wrote: Add efi_init_ops variable which allows us to replace EFI init functions on Xen with its specific stuff. This patch is based on Jan Beulich and Tang Liang work. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com Signed-off-by: Tang Liang liang.t...@oracle.com --- arch/ia64/kernel/efi.c | 30 +- arch/x86/platform/efi/efi.c | 18 +- drivers/firmware/efi/efi.c | 26 ++ include/linux/efi.h |8 4 files changed, 68 insertions(+), 14 deletions(-) [...] @@ -1118,6 +1118,14 @@ u64 efi_mem_attributes(unsigned long phys_addr) return 0; } +struct efi_init_ops efi_init_ops = { + .efi_init = efi_init_generic, + .efi_reserve_boot_services = efi_reserve_boot_services_generic, + .efi_enter_virtual_mode = efi_enter_virtual_mode_generic, + .efi_mem_type = efi_mem_type_generic, + .efi_mem_attributes = efi_mem_attributes_generic +}; Please don't create another struct of EFI function pointers. After this we'll have 3 global efi structures defintions and 4 global efi objects on x86, - struct efi_early [in the boot stub] - struct efi ['efi_phys' before/'efi' after SetVirtualAddressMap()] - struct efi_init_ops [for the benefit of xen] I have a big problem with exposing .efi_reserve_boot_services as an API. Also, the fact that in later patches you're copying chunks of the x86 virt_*() funtions suggests to me that this has been implemented at the wrong layer, because it actively discourages sharing code between x86 and Xen. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] efi: Add efi_init_ops variable
On Wed, Mar 26, 2014 at 12:56:23PM +, Matt Fleming wrote: On Tue, 25 Mar, at 09:57:52PM, Daniel Kiper wrote: Add efi_init_ops variable which allows us to replace EFI init functions on Xen with its specific stuff. This patch is based on Jan Beulich and Tang Liang work. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com Signed-off-by: Tang Liang liang.t...@oracle.com --- arch/ia64/kernel/efi.c | 30 +- arch/x86/platform/efi/efi.c | 18 +- drivers/firmware/efi/efi.c | 26 ++ include/linux/efi.h |8 4 files changed, 68 insertions(+), 14 deletions(-) [...] @@ -1118,6 +1118,14 @@ u64 efi_mem_attributes(unsigned long phys_addr) return 0; } +struct efi_init_ops efi_init_ops = { + .efi_init = efi_init_generic, + .efi_reserve_boot_services = efi_reserve_boot_services_generic, + .efi_enter_virtual_mode = efi_enter_virtual_mode_generic, + .efi_mem_type = efi_mem_type_generic, + .efi_mem_attributes = efi_mem_attributes_generic +}; Please don't create another struct of EFI function pointers. After this we'll have 3 global efi structures defintions and 4 global efi objects on x86, - struct efi_early [in the boot stub] - struct efi ['efi_phys' before/'efi' after SetVirtualAddressMap()] - struct efi_init_ops [for the benefit of xen] What do you suggest? Should we fill all EFI related structures in xen_efi_probe() (called from xen_start_kernel()) and later they should be parsed by generic/x86 EFI initialization code? I suppose that many variables will have NULL (or something relevant) in Xen dom0 and it will require some changes in EFI initialization code. I have a big problem with exposing .efi_reserve_boot_services as an API. Why? efi_reserve_boot_services() is public right now. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] efi: Add efi_init_ops variable
On Wed, 26 Mar, at 03:02:17PM, Daniel Kiper wrote: On Wed, Mar 26, 2014 at 12:56:23PM +, Matt Fleming wrote: Please don't create another struct of EFI function pointers. After this we'll have 3 global efi structures defintions and 4 global efi objects on x86, - struct efi_early [in the boot stub] - struct efi ['efi_phys' before/'efi' after SetVirtualAddressMap()] - struct efi_init_ops [for the benefit of xen] What do you suggest? Should we fill all EFI related structures in xen_efi_probe() (called from xen_start_kernel()) and later they should be parsed by generic/x86 EFI initialization code? I suppose that many variables will have NULL (or something relevant) in Xen dom0 and it will require some changes in EFI initialization code. Yeah, that is what I was thinking. And if we have to make some changes to the generic code to accomodate NULL fields, etc, I don't think it's a big deal. I have a big problem with exposing .efi_reserve_boot_services as an API. Why? efi_reserve_boot_services() is public right now. Sure it's public, but it isn't implemented on ia64 at all, not even as a stub function, and it's only called inside x86 code (the fact that the prototype is in include/linux/efi.h is a bit of a bug). My concern is that if in we bake into our APIs it's going to be difficult in the future to get rid of it or disable it, or at least allow people to write code for EFI without caring about it. Afterall, it's a workaround for buggy firmware. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html