Re: [Xen-devel] [PATCH] x86/xen: populate boot_params with EDD data

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Apr 03, 2013 at 12:10:49PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@xxxxxxxxxx>
> 
> During early setup of a dom0 kernel, populate boot_params with the
> Enhanced Disk Drive (EDD) and MBR signature data.  This makes
> information on the BIOS boot device available in /sys/firmware/edd/.
> 
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> ---
>  arch/x86/xen/enlighten.c |   57 
> ++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 57 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index c8e1c7b..857d3bc 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -31,6 +31,7 @@
>  #include <linux/pci.h>
>  #include <linux/gfp.h>
>  #include <linux/memblock.h>
> +#include <linux/edd.h>
>  
>  #include <xen/xen.h>
>  #include <xen/events.h>
> @@ -1306,6 +1307,60 @@ static const struct machine_ops xen_machine_ops 
> __initconst = {
>       .emergency_restart = xen_emergency_restart,
>  };
>  
> +#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
> +static void __init load_edd(void)
> +{
> +     struct xen_platform_op op;
> +     struct edd_info *edd_info;
> +     u32 *mbr_signature;
> +     unsigned nr;
> +     int ret;
> +
> +     edd_info = boot_params.eddbuf;
> +     mbr_signature = boot_params.edd_mbr_sig_buffer;
> +
> +     op.cmd = XENPF_firmware_info;
> +
> +     op.u.firmware_info.type = XEN_FW_DISK_INFO;
> +     for (nr = 0; nr < EDDMAXNR; nr++) {
> +             struct edd_info *info = edd_info + nr;
> +
> +             op.u.firmware_info.index = nr;
> +             info->params.length = sizeof(info->params);
> +             set_xen_guest_handle(op.u.firmware_info.u.disk_info.edd_params,
> +                                  &info->params);
> +             ret = HYPERVISOR_dom0_op(&op);
> +             if (ret)
> +                     break;
> +
> +#define C(x) info->x = op.u.firmware_info.u.disk_info.x
> +             C(device);
> +             C(version);
> +             C(interface_support);
> +             C(legacy_max_cylinder);
> +             C(legacy_max_head);
> +             C(legacy_sectors_per_track);
> +#undef C
> +     }
> +     boot_params.eddbuf_entries = nr;
> +
> +     op.u.firmware_info.type = XEN_FW_DISK_MBR_SIGNATURE;
> +     for (nr = 0; nr < EDD_MBR_SIG_MAX; nr++) {
> +             op.u.firmware_info.index = nr;
> +             ret = HYPERVISOR_dom0_op(&op);
> +             if (ret)
> +                     break;
> +             mbr_signature[nr] = 
> op.u.firmware_info.u.disk_mbr_signature.mbr_signature;
> +     }
> +     boot_params.edd_mbr_sig_buf_entries = nr;

If those two loops end up terminating at different spots (say first
one ends at nr=1, and the second at nr=5), is that going to present
a problem?

Should we have some form of 'min(nr_earlier, nr)' to clamp down in
case of weird oddities?

> +}
> +#else
> +static inline void __init load_edd(void)
> +{
> +}
> +#endif
> +
> +
>  /*
>   * Set up the GDT and segment registers for -fstack-protector.  Until
>   * we do this, we have to be careful not to call any stack-protected
> @@ -1508,6 +1563,8 @@ asmlinkage void __init xen_start_kernel(void)
>               /* Avoid searching for BIOS MP tables */
>               x86_init.mpparse.find_smp_config = x86_init_noop;
>               x86_init.mpparse.get_smp_config = x86_init_uint_noop;
> +
> +             load_edd();
>       }
>  #ifdef CONFIG_PCI
>       /* PCI BIOS service won't work from a PV guest. */
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel