Bug 1424722

Gerd, I'm looking at your jenkins edk2 packaging but it's a bit different in this area. One thing I'm confused by: I see for the fedora .secboot.fd build there's  lines like:

  build ${OVMF_SB_FLAGS} -a IA32 -a X64 ...

and references to Build/Ovmf3264/... dir. Is the .secboot build for both ia32 and x64? (sorry the edk2 build system is a mystery to me)

(In reply to Cole Robinson from comment #1)
> Gerd, I'm looking at your jenkins edk2 packaging but it's a bit different in
> this area. One thing I'm confused by: I see for the fedora .secboot.fd build
> there's  lines like:
> 
>   build ${OVMF_SB_FLAGS} -a IA32 -a X64 ...
> 
> and references to Build/Ovmf3264/... dir. Is the .secboot build for both
> ia32 and x64? (sorry the edk2 build system is a mystery to me)

It's a 64bit build, but some parts of the code are 32bit for reasons Laszlo can explain better.

The .secboot build uses IA32 for early boot and X64 for late boot.  The regular build uses X64 only.  What the bug requests is a pure IA32 build.

The Ia32X64 build uses a 32-bit PEI phase and a 64-bit DXE phase. To guest OSes this appears as 64-bit UEFI. This configuration has the best general support in edk2, for example, it supports S3 resume together with the SMM toolstack. The pure X64 build doesn't support S3 resume together with the SMM toolstack (so for that, you have to set disable_s3=1 on the command line or in the domain XML -- or else, use a build that does not include the SMM toolstack).

The X64 build uses 64-bit PEI and DXE phases. To guest OSes this also appears as 64-bit UEFI. It is quite unorthodox as far as edk2 x86 platforms go (it comes with some unique challenges -- the PEI phase is 64-bit, but only has page tables for the first 4GB or RAM, and looking forward that tends to upset some assumptions elsewhere in the codebase). Nonetheless, for most Fedora end-users, this build is likely the most suitable (as long as they don't want to mix S3 and SMM).

The Ia32 build uses 32-bit PEI and DXE phases. To guest OSes this appears as 32-bit UEFI. The utility of this build is great for firmware and OS development purposes (Ia32 tends to tickle different bugs from the other builds!), but for end users, its utility is quite limited, for the following reasons:

* GNU/Linux distributions are encouraged not to ship 32-bit UEFI installers:
  <http://mjg59.dreamwidth.org/26734.html>, and indeed most don't.

* There are a number of Windows OS-es (all Client) that support 32-bit UEFI
  (Windows 8.1, Windows 10), but they don't boot on Ia32 OVMF. I used to have
  an on-and-off correspondence with a Microsoft developer about this, but
  ultimately I didn't get sufficient help. My attempts with WinDbg from across
  another Windows VM produced some results (again with the help of said
  Microsoft developer), but not enough -- the crash occurs in winload.efi
  very-very early, soon after bootmgfw.efi launches it, but before the debug
  agent within winload.efi would activate and become available to WinDbg on
  the other machine. So bootmgfw.efi reports a failure and that's it (BSOD).
  If Microsoft want to help us with this, they can; the debug/checked build
  of Windows 8.1, 32-bit, UEFI, produces a filename and a line number on the
  BSOD.

So, from an end-user perspective, a pure Ia32 build is quite useless -- I don't know what OS you'd boot on top in practice.

For development & testing of 32-bit UEFI applications (perhaps with the end-goal of shipping them on independent 32-bit UEFI platforms like tablets?), the Ia32 build of OVMF is helpful. (BTW I'd classify this as "firmware development", see above.) If I was doing such UEFI app development, I'd certainly work against an upstream edk2 checkout, but other developers might prefer a different environment.

Upcoming Debian stretch includes a 32 bit uefi bootable CDROM that can't be booted on 64 bit uefi platform. However, the CDROM image is bootable with 32 bit uefi.

http://cdimage.debian.org/cdimage/stretch_di_rc2/i386/iso-cd/debian-stretch-DI-rc2-i386-netinst.iso

$ printf "%s\n" "$UEFI64"
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd

$ qemu-system-x86_64 -bios $UEFI64 -drive file=/tmp/debian.iso,media=cdrom -net none -serial mon:stdio -vnc :1 -m 512M
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):CD1a1:;BLK4:
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/CDROM(0x1)
     BLK2: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
     BLK3: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/CDROM(0x0)
     BLK6: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
     BLK1: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
     BLK5: Alias(s):
          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(2,MBR,0x7115E1E2,0xF2C,0x260)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:
FS0:\> dir efi\boot\
Directory of: FS0:\efi\boot\
02/01/2017  10:36 <DIR>         2,048  .
02/01/2017  10:36 <DIR>         2,048  ..
02/01/2017  10:36             278,528  bootia32.efi
          1 File(s)     278,528 bytes
          2 Dir(s)
FS0:\> reset -s

> 
> For development & testing of 32-bit UEFI applications (perhaps with the
> end-goal of shipping them on independent 32-bit UEFI platforms like
> tablets?), the Ia32 build of OVMF is helpful. (BTW I'd classify this as
> "firmware development", see above.) If I was doing such UEFI app
> development, I'd certainly work against an upstream edk2 checkout, but other
> developers might prefer a different environment.

At least just make 32 bit OVMF binary packaged, so that potential users (myself included) don't have to go through hassle of adding Kraxel's repo or compiling EDK II from source.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

edk2-20170209git296153c5-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-efd454a960

edk2-20170209git296153c5-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-efd454a960

OK. The package edk2-ovmf-20170209git296153c5-3 and edk2-ovmf-ia32-20170209git296153c5-3 has been available in the testing repository.

So far so great. The edk2-ovmf OVMF_CODE.fd firmware can boot Windows 10 Creators Update (1703).

The edk2-ovmf-ia32 OVMF_CODE.fd firmware can boot Debian Stretch 32 bit netinstall iso.

I think the update is good and can leave testing repository.

edk2-20170209git296153c5-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.