From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] x86/xen: populate boot_params with EDD data Date: Wed, 3 Apr 2013 10:53:52 -0400 Message-ID: <20130403145352.GE6044@phenom.dumpdata.com> References: <1364987449-10076-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1364987449-10076-1-git-send-email-david.vrabel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Wed, Apr 03, 2013 at 12:10:49PM +0100, David Vrabel wrote: > From: David Vrabel > > 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 > --- > 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 > #include > #include > +#include > > #include > #include > @@ -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 >