All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: PGNet Dev <pgnet.dev@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware
Date: Mon, 7 Dec 2015 09:20:50 -0500	[thread overview]
Message-ID: <20151207142050.GA24671@char.us.oracle.com> (raw)
In-Reply-To: <20151207142012.GB22814@char.us.oracle.com>

[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]

On Mon, Dec 07, 2015 at 09:20:12AM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 05, 2015 at 12:54:56PM -0800, PGNet Dev wrote:
> > On 12/05/2015 11:44 AM, Konrad Rzeszutek Wilk wrote:
> > >>Two issues exist with the SuperMicro EFI
> > >>
> > >>	(1) firmware EFI mis-mapping causing Xen PANIC on restart
> > >
> > >Can you try 'reboot=acpi' ?
> > >
> > ...
> > >>I.e., what combination of
> > >>
> > >>/mapbs
> > >>efi=no-rs
> > >>reboot=acpi
> > >>
> > >All? It should be on the Xen command line.
> > 
> > with /mapbs on the EFI exec line,
> > 
> > 	grep mapbs /boot/grub2/grub.cfg
> > 		chainloader $cmdpath/xen-4.6.0_04-398.efi xen-4.6.0_04-398.efi config.1
> > /mapbs
> > 
> > and on the Xen Cmd Line,
> > 
> > 	grep efi= /boot/efi/EFI/opensuse/xen-4.6.0_04-398.cfg
> > 		options= dom0_mem=3072M,max:3072M ... loglvl=all guest_loglvl=all
> > efi=no-rs reboot=acpi
> 
> > 
> > not clear to me what effect, if any, the addition of 'reboot=acpi' and
> > '/mapbs' has, relative to just 'efi=no-rs' has.
> 
> 
> Are you by chance an lawyer? :-)
> 
> Try without /mapbs, efi=nr-rs and with reboot=acpi. That should use EFI routines
> for everything (including reboot). Doing the 'reboot=acpi' will override
> the reboot routine to only use the ACPI method.
> 
> Granted if you did 'efi=nr-rs' we bypass EFI altogether and use 'acpi' method.
> 
> My theory was that if use some EFI routines it inits the firmware enough
> that ACPI reboot should work. But it may be that it is just not happy.
> 
> There is an extra patch you can try to determine if the failure is
> due to us doing ExitBootServices and not using virtual addresses (which
> for example is the reason that under Lenovo it goes haywire).
> 
> See attached patch (against staging). With that you would do:

Now attached.
> 
> xen.efi /noexitboot /mapbs
> 
> And you can try without 'efi=no-rs'.
> 
> However I am wondering - why are you using '/mapbs' ? What did it
> help? (The combination of 'efi=no-rs' means you are in effect not
> using _any_ EFI operations - so doing /mapbs is not needed).

[-- Attachment #2: 0001-EFI-early-Implement-GetNextVariableName-and-query-an.patch --]
[-- Type: text/plain, Size: 6135 bytes --]

>From 04c94fa6cb783ecbc8ce620222c91599b8d95777 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 17 Nov 2015 10:14:57 -0500
Subject: [PATCH] EFI/early: Implement GetNextVariableName and /query and
 /noexitboot parameters

In the early EFI boot we will enumerate up to five EFI variables
to make sure it works.

The /query will just enumerate them and then quit. Helps in
troubleshooting and redirecting the output to a file (xen.efi /query > q).

The /noexitboot will inhibit Xen from calling ExitBootServices.
This allows on Lenovo ThinkPad x230, T420 to use GetNextVariableName
in 1-1 mapping mode.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 xen/common/efi/boot.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 89 insertions(+), 5 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 53c7452..2e0d4c2 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -836,6 +836,75 @@ static void __init setup_efi_pci(void)
     efi_bs->FreePool(handles);
 }
 
+static int __init efi_getnextvariable(bool_t query_only)
+{
+    EFI_GUID guid;
+    UINTN i, size, idx;
+    CHAR16 *name;
+    EFI_STATUS status;
+
+
+    status = efi_bs->AllocatePool(EfiLoaderData, 1024, (void *)&name);
+    if ( EFI_ERROR(status) )
+        return status;
+
+    guid.Data1 = 0;
+    guid.Data2 = 0;
+    guid.Data3 = 0;
+    for ( i = 0; i < 8; i++ )
+        guid.Data4[i] = 0;
+
+    for ( i = 0 ; i < 1024 / sizeof (CHAR16); i++ )
+        name[i] = 0;
+
+    PrintStr(L"GetNextVariableName: ");
+    PrintStr(name);
+    PrintStr(newline);
+    idx = 0;
+    do {
+        size = 1024;
+        efi_rs->GetNextVariableName(&size, name, &guid);
+        if ( EFI_ERROR(status) )
+        {
+            if ( query_only )
+            {
+                efi_bs->FreePool(name);
+                PrintErrMesg(L"Failed to GetNextVariableName", status);
+            }
+            else
+            {
+                PrintStr(L"Warning: GetNextVariableName: ");
+                DisplayUint(status, 0);
+                PrintStr(newline);
+            }
+        }
+        else
+        {
+            DisplayUint(guid.Data1, 4);
+            DisplayUint(guid.Data2, 2);
+            DisplayUint(guid.Data3, 2);
+            for ( i = 0; i < 8; i++ )
+                DisplayUint(guid.Data4[i], 1);
+
+            PrintStr(L":");
+            PrintStr(name);
+            PrintStr(L" ");
+            DisplayUint(status, 0);
+            PrintStr(newline);
+        }
+    } while ( !EFI_ERROR(status) && idx++ < 5 );
+
+    efi_bs->FreePool(name);
+
+    if ( query_only )
+        return -EINVAL;
+
+    if ( EFI_ERROR(EFI_NOT_FOUND) )
+        return 0;
+
+    return status;
+}
+
 static void __init efi_variables(void)
 {
     EFI_STATUS status;
@@ -875,7 +944,7 @@ static void __init efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop
         efi_arch_video_init(gop, info_size, mode_info);
 }
 
-static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
+static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable, bool_t exitbootservices)
 {
     EFI_STATUS status;
     UINTN info_size = 0, map_key;
@@ -903,9 +972,13 @@ static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *Syste
 
         efi_arch_pre_exit_boot();
 
-        status = SystemTable->BootServices->ExitBootServices(ImageHandle,
-                                                             map_key);
-        efi_bs = NULL;
+        status = 0;
+        if ( exitbootservices )
+        {
+            status = SystemTable->BootServices->ExitBootServices(ImageHandle,
+                                                                 map_key);
+            efi_bs = NULL;
+        }
         if ( status != EFI_INVALID_PARAMETER || retry )
             break;
     }
@@ -951,8 +1024,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
     union string section = { NULL }, name;
     bool_t base_video = 0;
+    bool_t query_only = 0;
     char *option_str;
     bool_t use_cfg_file;
+    bool_t exit_boot_services = 1;
 
     efi_init(ImageHandle, SystemTable);
 
@@ -990,6 +1065,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
                     base_video = 1;
                 else if ( wstrcmp(ptr + 1, L"mapbs") == 0 )
                     map_bs = 1;
+                else if ( wstrcmp(ptr + 1, L"query") == 0 )
+                    query_only = 1;
+                else if ( wstrcmp(ptr + 1, L"noexitboot") == 0 )
+                    exit_boot_services = 0;
                 else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 )
                     cfg_file_name = ptr + 5;
                 else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 )
@@ -1000,6 +1079,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
                     PrintStr(L"Xen EFI Loader options:\r\n");
                     PrintStr(L"-basevideo   retain current video mode\r\n");
                     PrintStr(L"-mapbs       map EfiBootServices{Code,Data}\r\n");
+                    PrintStr(L"-noexitboot  do not call ExitBootServices\r\n");
+                    PrintStr(L"-query       call GetNextVariableName for up to five times\r\n");
                     PrintStr(L"-cfg=<file>  specify configuration file\r\n");
                     PrintStr(L"-help, -?    display this help\r\n");
                     blexit(NULL);
@@ -1160,12 +1241,15 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     /* Get snapshot of variable store parameters. */
     efi_variables();
 
+    if ( efi_getnextvariable(query_only) )
+       blexit(L"Could not get next variable");
+
     efi_arch_memory_setup();
 
     if ( gop )
         efi_set_gop_mode(gop, gop_mode);
 
-    efi_exit_boot(ImageHandle, SystemTable);
+    efi_exit_boot(ImageHandle, SystemTable, exit_boot_services);
 
     efi_arch_post_exit_boot();
     for( ; ; ); /* not reached */
-- 
2.1.0


[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

  reply	other threads:[~2015-12-07 14:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 23:16 fyi, Xen's EFI workarounds (/mapbs & efi=no-rs) on SuperMicro hardware; fixes solve 1/2 problems & SM responds that can't/won't fix their firmware PGNet Dev
2015-12-05  2:49 ` Zir Blazer
2015-12-05 18:05 ` Konrad Rzeszutek Wilk
2015-12-05 18:32   ` PGNet Dev
2015-12-05 19:44     ` Konrad Rzeszutek Wilk
2015-12-05 20:54       ` PGNet Dev
2015-12-07 14:20         ` Konrad Rzeszutek Wilk
2015-12-07 14:20           ` Konrad Rzeszutek Wilk [this message]
2015-12-07 17:15             ` Doug Goldstein
2015-12-07 18:09               ` Konrad Rzeszutek Wilk
2015-12-07 14:48           ` PGNet Dev

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=20151207142050.GA24671@char.us.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=pgnet.dev@gmail.com \
    --cc=xen-devel@lists.xen.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: link
Be 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.