>>> On 26.03.14 at 14:12, <matt@xxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|