Re: [Xen-devel] 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

[Zir Blazer <zir_blazer@xxxxxxxxxxx>]

> Hardware is a SuperMicro X10SAT motherboard
> (http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm),
> with AMI v3 BIOS + "UEFI support"
>
> Two issues exist with the SuperMicro EFI
>
> (1) firmware EFI mis-mapping causing Xen PANIC on restart
> (2) EFI variables not persistent across reboot
>
> SuperMicro's development/support has been made aware of both issues;
> Their response is that they won't/can't fix the problem.



I'm a X10SAT owner, I'm using BIOS R2.0 (Don't recall the ZIP name with the 
release date, but I have it stored somewhere). There were also a R2.2 version 
before R3.0 came out (Which should include Broadwell support, since I asked 
Supermicro support about that back when R2.2 was the latest and they said that 
it didn't had it).

The efibootmgr issue you mentioned makes me remember that I found a ugly, 
freeze inducing bug in the BIOS itself. UEFI specification says that the 
Firmware must allow the user to edit NVRAM Boot entries from the Firmware 
itself (Or something along those lines), which the X10SAT, at least on paper, 
appears to do. If you go to the Boot menu, you can use "Add New Boot Option", 
which is supposedly the way you can do what efibootmgr does from inside Linux 
(Writing to Firmware NVRAM), but from the Motherboard Firmware itself. 
Everytime I recall having tried to manually add an option there so I can boot 
doing UEFI -> Xen -> Dom0 instead of UEFI -> Boot Loader/Manager  -> Xen -> 
Dom0 (Or just base Linux, without Xen), after properly setting up the option 
and Xen/Linux Kernel parameters, trying to switch to another menu freezes the 
BIOS. On rebooting, there was nothing at all.
I didn't tested that again before sending you this mail, nor reported the bug 
to Supermicro, but I recall it was that way - you may want to try it, chances 
are that you can reproduce the freeze in R3.0, as your mail seems to point that 
all is related to the same volatile NVRAM issue.

Also, while I don't recall any Xen panic, since I started to sucessfully use 
UEFI Boot (Back when Linux Kernel 3.17 was released, as that was the very first 
Kernel that I got UEFI Boot working with. 3.17 introduced official Xen Dom0 
support, some people got it working before that on other platforms, but I had 
to wait specifically for that Kernel), what I noticed is that using the reboot 
command may freeze at the very last step ("Restarting the system..." I think it 
was). It doesn't always happens, seems to do so more often if I use reboot soon 
after booting, don't recall it freezing when issuing reboot if left on for long 
periods (Days).
I'm using Arch Linux, Xen 4.5, and Kernel 4.0.1, but I recall the reboot issue 
being much older, chances are that I first encounter it with Xen 4.3 and Kernel 
3.17, and very possibily is Firmware related. I don't recall that it ever 
freezed when NOT using Xen, which is basically when launching standalone Arch 
Linux.

You can workaround your UEFI Boot issue if you use a Boot Manager like 
Gummiboot (Which has been deprecated, no idea what currently replaces it). If I 
recall correctly, even with a broken NVRAM, UEFI specification says that by 
default the Firmware should attempt to load \EFI\BOOT\BOOTX64.EFI from the ESP 
(EFI System Partition) of the selected unit if no specific EFI file is 
selected. A Boot Manager that works by replacing BOOTX64.EFI with its own 
(Gummiboot does), and creates a menu with entries that you can store in the 
ESP, which should be in a non-volatile HD/SSD, should allow you to fully 
workaround that issue. That's the same workaround that allow you to have a OVMF 
(UEFI) based VM in Xen with persistent settings, since Xen has no way currently 
to save OVMF NVRAM settings (Basically, X10SAT issue, VM side).
On a sidenote, I don't know why everyone wants to use GRUB to chainload the Xen 
EFI image. You can use a less bloated Boot Loader/Manager and achieve the same 
results, no idea what makes GRUB better than telling the Firmware to boot the 
Xen EFI image directly (And its one less step).


All in all, I'm extremely satisfied with my X10SAT, even would recommend and 
buy it again. Supermicro support was at least more helpful than the other 
consumer oriented vendors I know (Mainly ASUS, I dislike them), and their 
Firmware also seems a bit more polished - I can guarantee you, its more UEFI 
compliant that it looks since I didn't faced common issues when UEFI Booting 
that I hear other users had in other platforms.
I myself spend months researching on a Motherboard that got a working VT-d 
implementation since a truckload of Motherboards brands and models had broken 
implementations which no maker cared to fix, yet the X10SAT delivered 
flawlessly. Sadly, no Motherboard vendor that I know of has a perfect Firmware, 
what one got properly working, is totally broken on another one, as you can see 
that there are also those flaws in X10SAT, too. I don't know if there is a 
better Server Motherboard for LGA 1150 Haswell/Broadwell generation.            
                        
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel