From: Daniel Kiper <daniel.kiper@oracle.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, boris.ostrovsky@oracle.com, david.vrabel@citrix.com, eshelton@pobox.com, hpa@zytor.com, ian.campbell@citrix.com, jbeulich@suse.com, jeremy@goop.org, konrad.wilk@oracle.com, matt.fleming@intel.com, mingo@redhat.com, mjg59@srcf.ucam.org, tglx@linutronix.de Subject: Re: [PATCH v5 4/7] xen: Put EFI machinery in place Date: Mon, 16 Jun 2014 20:45:27 +0200 [thread overview] Message-ID: <20140616184527.GH3463@olila.local.net-space.pl> (raw) In-Reply-To: <alpine.DEB.2.02.1406161245490.13771@kaball.uk.xensource.com> On Mon, Jun 16, 2014 at 12:55:35PM +0100, Stefano Stabellini wrote: > On Fri, 13 Jun 2014, Daniel Kiper wrote: > > This patch enables EFI usage under Xen dom0. Standard EFI Linux > > Kernel infrastructure cannot be used because it requires direct > > access to EFI data and code. However, in dom0 case it is not possible > > because above mentioned EFI stuff is fully owned and controlled > > by Xen hypervisor. In this case all calls from dom0 to EFI must > > be requested via special hypercall which in turn executes relevant > > EFI code in behalf of dom0. > > > > When dom0 kernel boots it checks for EFI availability on a machine. > > If it is detected then artificial EFI system table is filled. > > Native EFI callas are replaced by functions which mimics them > > by calling relevant hypercall. Later pointer to EFI system table > > is passed to standard EFI machinery and it continues EFI subsystem > > initialization taking into account that there is no direct access > > to EFI boot services, runtime, tables, structures, etc. After that > > system runs as usual. > > > > This patch is based on Jan Beulich and Tang Liang work. > > > > v5 - suggestions/fixes: > > - improve macro usage readability > > (suggested by Andrew Cooper and David Vrabel), > > - conditions cleanup > > (suggested by David Vrabel), > > - use -fshort-wchar option > > (suggested by Jan Beulich), > > - Kconfig rule cleanup > > (suggested by Jan Beulich), > > - forward port fixes from SUSE kernel > > (suggested by Jan Beulich), > > - improve commit message > > (suggested by David Vrabel). > > > > v4 - suggestions/fixes: > > - "just populate an efi_system_table_t object" > > (suggested by Matt Fleming). > > > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Signed-off-by: Tang Liang <liang.tang@oracle.com> > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> > > Sorry for commenting on your patches so late in the review cycle. No problem. [...] > > +efi_system_table_t __init *xen_efi_probe(void) > > +{ > > + struct xen_platform_op op = { > > + .cmd = XENPF_firmware_info, > > + .u.firmware_info = { > > + .type = XEN_FW_EFI_INFO, > > + .index = XEN_FW_EFI_CONFIG_TABLE > > + } > > + }; > > + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; > > + > > + if (!xen_initial_domain() || HYPERVISOR_dom0_op(&op) < 0) > > + return NULL; > > + > > + /* Here we know that Xen runs on EFI platform. */ > > + > > + efi = efi_xen; > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_VENDOR; > > + info->vendor.bufsz = sizeof(vendor); > > + set_xen_guest_handle(info->vendor.name, vendor); > > + > > + if (HYPERVISOR_dom0_op(&op) == 0) { > > + efi_systab_xen.fw_vendor = __pa_symbol(vendor); > > + efi_systab_xen.fw_revision = info->vendor.revision; > > + } else > > + efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN"); > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_VERSION; > > + > > + if (HYPERVISOR_dom0_op(&op) == 0) > > + efi_systab_xen.hdr.revision = info->version; > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION; > > + > > + if (HYPERVISOR_dom0_op(&op) == 0) > > + efi.runtime_version = info->version; > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE; > > + > > + if (HYPERVISOR_dom0_op(&op) < 0) > > + BUG(); > > Is it really worth of a BUG()? Can't we just print a warning and return > NULL? We could still boot without EFI support. Earlier the same hypercall function succeeded so if here it failed it means that something is really broken. However, I will try remove this call and get all data from earlier one. This way we avoid this BUG() call. Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> To: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org> Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org, andrew.cooper3-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org, boris.ostrovsky-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org, eshelton-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org, jbeulich-IBi9RG/b67k@public.gmane.org, jeremy-TSDbQ3PG+2Y@public.gmane.org, konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org Subject: Re: [PATCH v5 4/7] xen: Put EFI machinery in place Date: Mon, 16 Jun 2014 20:45:27 +0200 [thread overview] Message-ID: <20140616184527.GH3463@olila.local.net-space.pl> (raw) In-Reply-To: <alpine.DEB.2.02.1406161245490.13771-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org> On Mon, Jun 16, 2014 at 12:55:35PM +0100, Stefano Stabellini wrote: > On Fri, 13 Jun 2014, Daniel Kiper wrote: > > This patch enables EFI usage under Xen dom0. Standard EFI Linux > > Kernel infrastructure cannot be used because it requires direct > > access to EFI data and code. However, in dom0 case it is not possible > > because above mentioned EFI stuff is fully owned and controlled > > by Xen hypervisor. In this case all calls from dom0 to EFI must > > be requested via special hypercall which in turn executes relevant > > EFI code in behalf of dom0. > > > > When dom0 kernel boots it checks for EFI availability on a machine. > > If it is detected then artificial EFI system table is filled. > > Native EFI callas are replaced by functions which mimics them > > by calling relevant hypercall. Later pointer to EFI system table > > is passed to standard EFI machinery and it continues EFI subsystem > > initialization taking into account that there is no direct access > > to EFI boot services, runtime, tables, structures, etc. After that > > system runs as usual. > > > > This patch is based on Jan Beulich and Tang Liang work. > > > > v5 - suggestions/fixes: > > - improve macro usage readability > > (suggested by Andrew Cooper and David Vrabel), > > - conditions cleanup > > (suggested by David Vrabel), > > - use -fshort-wchar option > > (suggested by Jan Beulich), > > - Kconfig rule cleanup > > (suggested by Jan Beulich), > > - forward port fixes from SUSE kernel > > (suggested by Jan Beulich), > > - improve commit message > > (suggested by David Vrabel). > > > > v4 - suggestions/fixes: > > - "just populate an efi_system_table_t object" > > (suggested by Matt Fleming). > > > > Signed-off-by: Jan Beulich <jbeulich-IBi9RG/b67k@public.gmane.org> > > Signed-off-by: Tang Liang <liang.tang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> > > Signed-off-by: Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> > > Sorry for commenting on your patches so late in the review cycle. No problem. [...] > > +efi_system_table_t __init *xen_efi_probe(void) > > +{ > > + struct xen_platform_op op = { > > + .cmd = XENPF_firmware_info, > > + .u.firmware_info = { > > + .type = XEN_FW_EFI_INFO, > > + .index = XEN_FW_EFI_CONFIG_TABLE > > + } > > + }; > > + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; > > + > > + if (!xen_initial_domain() || HYPERVISOR_dom0_op(&op) < 0) > > + return NULL; > > + > > + /* Here we know that Xen runs on EFI platform. */ > > + > > + efi = efi_xen; > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_VENDOR; > > + info->vendor.bufsz = sizeof(vendor); > > + set_xen_guest_handle(info->vendor.name, vendor); > > + > > + if (HYPERVISOR_dom0_op(&op) == 0) { > > + efi_systab_xen.fw_vendor = __pa_symbol(vendor); > > + efi_systab_xen.fw_revision = info->vendor.revision; > > + } else > > + efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN"); > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_VERSION; > > + > > + if (HYPERVISOR_dom0_op(&op) == 0) > > + efi_systab_xen.hdr.revision = info->version; > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION; > > + > > + if (HYPERVISOR_dom0_op(&op) == 0) > > + efi.runtime_version = info->version; > > + > > + op.cmd = XENPF_firmware_info; > > + op.u.firmware_info.type = XEN_FW_EFI_INFO; > > + op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE; > > + > > + if (HYPERVISOR_dom0_op(&op) < 0) > > + BUG(); > > Is it really worth of a BUG()? Can't we just print a warning and return > NULL? We could still boot without EFI support. Earlier the same hypercall function succeeded so if here it failed it means that something is really broken. However, I will try remove this call and get all data from earlier one. This way we avoid this BUG() call. Daniel
next prev parent reply other threads:[~2014-06-16 18:46 UTC|newest] Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-13 17:00 [PATCH v5 0/7] xen: Add EFI support Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-13 17:00 ` [PATCH v5 1/7] efi: Use early_mem*() instead of early_io*() Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-16 1:19 ` Matthew Garrett 2014-06-16 1:19 ` Matthew Garrett 2014-06-16 1:19 ` Matthew Garrett 2014-06-18 12:17 ` Matt Fleming 2014-06-18 12:31 ` David Vrabel 2014-06-18 12:31 ` David Vrabel 2014-06-18 12:31 ` David Vrabel 2014-06-18 12:59 ` Daniel Kiper 2014-06-18 12:59 ` Daniel Kiper 2014-06-18 14:56 ` Matt Fleming 2014-06-18 14:56 ` Matt Fleming 2014-06-18 14:56 ` Matt Fleming 2014-06-18 13:59 ` Mark Salter 2014-06-18 13:59 ` Mark Salter 2014-06-18 13:59 ` Mark Salter 2014-06-18 12:17 ` Matt Fleming 2014-06-13 17:00 ` [PATCH v5 2/7] efi: Introduce EFI_NO_DIRECT flag Daniel Kiper 2014-06-16 10:52 ` [Xen-devel] " David Vrabel 2014-06-16 10:52 ` David Vrabel 2014-06-16 10:52 ` David Vrabel 2014-06-18 13:52 ` Matt Fleming 2014-06-18 13:52 ` Matt Fleming 2014-06-18 13:52 ` Matt Fleming 2014-06-18 13:58 ` Jan Beulich 2014-06-18 13:58 ` Jan Beulich 2014-06-18 13:58 ` Jan Beulich 2014-06-18 14:30 ` Stefano Stabellini 2014-06-18 14:30 ` Stefano Stabellini 2014-06-18 15:08 ` Daniel Kiper 2014-06-18 15:08 ` Daniel Kiper 2014-06-18 15:08 ` Daniel Kiper 2014-06-18 15:12 ` Matt Fleming 2014-06-18 15:12 ` Matt Fleming 2014-06-18 15:12 ` Matt Fleming 2014-06-18 14:30 ` Stefano Stabellini 2014-06-18 16:48 ` Daniel Kiper 2014-06-18 16:48 ` Daniel Kiper 2014-06-18 16:48 ` Daniel Kiper 2014-06-19 14:41 ` Matt Fleming 2014-06-19 14:41 ` Matt Fleming 2014-06-19 14:41 ` Matt Fleming 2014-06-20 14:36 ` Daniel Kiper 2014-06-20 14:36 ` Daniel Kiper 2014-06-20 14:36 ` Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-13 17:00 ` [PATCH v5 3/7] xen: Define EFI related stuff Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-16 10:54 ` David Vrabel 2014-06-16 10:54 ` [Xen-devel] " David Vrabel 2014-06-16 10:54 ` David Vrabel 2014-06-13 17:00 ` [PATCH v5 4/7] xen: Put EFI machinery in place Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-16 11:55 ` Stefano Stabellini 2014-06-16 11:55 ` Stefano Stabellini 2014-06-16 11:55 ` Stefano Stabellini 2014-06-16 18:45 ` Daniel Kiper 2014-06-16 18:45 ` Daniel Kiper [this message] 2014-06-16 18:45 ` Daniel Kiper 2014-06-16 12:00 ` David Vrabel 2014-06-16 12:00 ` David Vrabel 2014-06-16 12:00 ` David Vrabel 2014-06-16 19:06 ` Daniel Kiper 2014-06-16 19:06 ` Daniel Kiper 2014-06-16 19:06 ` Daniel Kiper 2014-06-13 17:00 ` [PATCH v5 5/7] arch/x86: Replace plain strings with constants Daniel Kiper 2014-06-18 13:56 ` Matt Fleming 2014-06-18 13:56 ` Matt Fleming 2014-06-18 13:56 ` Matt Fleming 2014-06-13 17:00 ` Daniel Kiper 2014-06-13 17:00 ` [PATCH v5 6/7] arch/x86: Remove redundant set_bit() call Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-18 13:56 ` Matt Fleming 2014-06-18 13:56 ` Matt Fleming 2014-06-18 13:56 ` Matt Fleming 2014-06-18 14:01 ` Konrad Rzeszutek Wilk 2014-06-18 14:01 ` Konrad Rzeszutek Wilk 2014-06-18 14:09 ` Matt Fleming 2014-06-18 14:09 ` Matt Fleming 2014-06-18 14:09 ` Matt Fleming 2014-06-18 14:01 ` Konrad Rzeszutek Wilk 2014-06-13 17:00 ` [PATCH v5 7/7] arch/x86: Comment out efi_set_rtc_mmss() Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-13 17:00 ` Daniel Kiper 2014-06-16 11:43 ` Stefano Stabellini 2014-06-16 11:43 ` Stefano Stabellini 2014-06-16 11:43 ` Stefano Stabellini 2014-06-16 11:54 ` Juergen Gross 2014-06-16 11:54 ` [Xen-devel] " Juergen Gross 2014-06-16 18:59 ` H. Peter Anvin 2014-06-16 18:59 ` H. Peter Anvin 2014-06-16 18:59 ` H. Peter Anvin 2014-06-18 14:08 ` Matt Fleming 2014-06-18 14:08 ` Matt Fleming 2014-06-18 14:08 ` Matt Fleming 2014-06-18 14:15 ` [PATCH v5 0/7] xen: Add EFI support Matt Fleming 2014-06-18 14:15 ` Matt Fleming 2014-06-18 14:15 ` Matt Fleming 2014-06-18 14:31 ` Konrad Rzeszutek Wilk 2014-06-18 14:31 ` Konrad Rzeszutek Wilk 2014-06-18 14:31 ` Konrad Rzeszutek Wilk 2014-06-18 14:48 ` Matt Fleming 2014-06-18 14:48 ` Matt Fleming 2014-06-18 14:48 ` Matt Fleming
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140616184527.GH3463@olila.local.net-space.pl \ --to=daniel.kiper@oracle.com \ --cc=andrew.cooper3@citrix.com \ --cc=boris.ostrovsky@oracle.com \ --cc=david.vrabel@citrix.com \ --cc=eshelton@pobox.com \ --cc=hpa@zytor.com \ --cc=ian.campbell@citrix.com \ --cc=jbeulich@suse.com \ --cc=jeremy@goop.org \ --cc=konrad.wilk@oracle.com \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=matt.fleming@intel.com \ --cc=mingo@redhat.com \ --cc=mjg59@srcf.ucam.org \ --cc=stefano.stabellini@eu.citrix.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.