Bug 1424722 - Provide separate package containing i386 (ia32) and x86_64 (x64) ovmf binary
Summary: Provide separate package containing i386 (ia32) and x86_64 (x64) ovmf binary
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: edk2
Version: 26
Hardware: noarch
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paolo Bonzini
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-18 17:59 UTC by mydeardiary
Modified: 2017-04-09 05:59 UTC (History)
6 users (show)

Fixed In Version: edk2-20170209git296153c5-3.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-09 05:59:13 UTC
Type: Bug


Attachments (Terms of Use)

Description mydeardiary 2017-02-18 17:59:00 UTC
Description of problem:
There is only edk2-ovmf package which contains only x86_64 (x64) uefi image.
Since there is no 32 bit emulation for uefi, it's not possible to launch 32 bit (ia32) efi application on x86_64 uefi image.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install edk2-ovmf package (which only contains x64 uefi binary).
2. Attempt to launch ia32 efi image, such as Windows 10 x86 installer on UEFI (bootia32.efi).
3. Of course it's failed, since uefi doesn't have any kind of 32 bit emulation :(

Actual results:
Only x64 uefi OVMF binary are packaged, so one can't launch 32 bit uefi applications.

Expected results:
Both x64 and ia32 uefi OVMF image are present, or provided by separate noarch package.

Additional info:
Kraxel's daily build[1] has included separate package for x64 and ia32 UEFI binary: edk2.git-ovmf-x64 and edk2.git-ovmf-ia32. This can be used as packaging reference.

1: https://www.kraxel.org/repos/jenkins/edk2/

Comment 1 Cole Robinson 2017-02-22 00:10:54 UTC
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)

Comment 2 Gerd Hoffmann 2017-02-22 10:11:00 UTC
(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.

Comment 3 Paolo Bonzini 2017-02-22 10:11:12 UTC
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.

Comment 4 Laszlo Ersek 2017-02-25 15:41:24 UTC
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.

Comment 5 mydeardiary 2017-02-26 14:47:33 UTC
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.

Comment 6 Fedora End Of Life 2017-02-28 12:22:41 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 7 Fedora Update System 2017-04-03 23:54:51 UTC
edk2-20170209git296153c5-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-efd454a960

Comment 8 Fedora Update System 2017-04-04 23:52:20 UTC
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

Comment 9 mydeardiary 2017-04-07 03:24:59 UTC
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.

Comment 10 Fedora Update System 2017-04-09 05:59:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.