lkml.org 
[lkml]   [2014]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 5/5] xen: Put EFI machinery in place
>>> On 26.03.14 at 14:12, <matt@console-pimps.org> wrote:
> On Tue, 25 Mar, at 09:57:56PM, Daniel Kiper wrote:
>> +static void __init efi_init_xen(void)
>> +{
>> + efi_char16_t vendor_c16[100];
>> + char vendor[ARRAY_SIZE(vendor_c16)];
>> + int ret, i;
>> + struct xen_platform_op op;
>> + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
>> +
>> + efi = efi_xen;
>> + op.cmd = XENPF_firmware_info;
>> + op.u.firmware_info.type = XEN_FW_EFI_INFO;
>> +
>> + /*
>> + * Show what we know for posterity
>> + */
>> + op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
>> + info->vendor.bufsz = sizeof(vendor_c16);
>> + set_xen_guest_handle(info->vendor.name, vendor_c16);
>> + ret = HYPERVISOR_dom0_op(&op);
>> + if (!ret) {
>> + for (i = 0; i < sizeof(vendor) - 1 && vendor_c16[i]; ++i)
>> + vendor[i] = vendor_c16[i];
>> + vendor[i] = '\0';
>> + } else
>> + pr_err("Could not get the firmware vendor!\n");
>> +
>
> Is there a reason that you can't just populate an efi_system_table_t
> object, which could be used by efi_init(), so that we can save you the
> trouble of duplicating all of this code?

Would the generic function cope with all other fields being NULL (or
equivalent)?

>> +/*
>> + * Convenience functions to obtain memory types and attributes
>> + */
>> +static u32 efi_mem_type_xen(unsigned long phys_addr)
>> +{
>> + struct xen_platform_op op;
>> + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
>> +
>> + op.cmd = XENPF_firmware_info;
>> + op.u.firmware_info.type = XEN_FW_EFI_INFO;
>> + op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
>> + info->mem.addr = phys_addr;
>> + info->mem.size = 0;
>> + return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type;
>> +}
>
> Same idea here. Unless you expect the EFI memory map to change at runtime
> (and it's not clear to me whether that wouldn't cause other things to
> explode) you'd be better off building a struct efi_memory_map and using
> the existing generic functions.

As said in another reply to this series - the memory map isn't being
(and shouldn't be) exposed to Dom0.

Jan



\
 
 \ /
  Last update: 2014-03-26 15:01    [W:0.153 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site