[Bug: https://bugzilla.redhat.com/show_bug.cgi?id=866664]
Here's the situation, since the bug doesn't explain it well.
(1) qemu can run any architecture on any other architecture, using software emulation. eg. It can run x86_64 guest operating systems on top of ppc64 hosts (albeit not at full speed).
(2) In order to run guests, you have to provide a BIOS (or some sort of other boot ROM), since most guests wouldn't be able to boot without BIOS services. This applies for all guests, but of particular interest to us are i686/x86_64 guests.
(3) SeaBIOS is a free, open source PC BIOS implementation. It is what we use to provide services to i686/x86_64 PC guests.
(4) Although qemu itself bundles some binary BIOSes, in Fedora we have chosen to recompile these from source. We now (on i686/x86_64) compile or cross-compile all ROMs from source.
(5) 'seabios-bin' is the name of the RPM package that contains the SeaBIOS ROMs. I have no idea why (historical?) this package has '-bin' in the name, but the important point is that it is NOT a binary-only package. It is built from source.
(6) In order to compile SeaBIOS you need a program called 'iasl' (part of the ACPICA.org project). This program is needed to compile the ACPI tables which are an integral part of the ROM data that is needed for i686/x86_64 guests to boot.
(7) Unfortunately the iasl program, which runs fine on little-endian platforms, has endianness issues. Such that when you run it on a ppc64 host it produces big-endian ACPI tables, which are of course completely broken. 'iasl' itself is a very large program, and I do not know the scope of the fix for this issue -- it may be trivial, or it may require auditing every line of code.
Therefore:
We would like a packaging exception which would allow us to import the seabios-bin package (built on little-endian) into the ppc & ppc64 buildroots.
Rich.
Am 16.10.2012 16:19, schrieb Richard W.M. Jones:
[Bug: https://bugzilla.redhat.com/show_bug.cgi?id=866664]
Here's the situation, since the bug doesn't explain it well.
(1) qemu can run any architecture on any other architecture, using software emulation. eg. It can run x86_64 guest operating systems on top of ppc64 hosts (albeit not at full speed).
(2) In order to run guests, you have to provide a BIOS (or some sort of other boot ROM), since most guests wouldn't be able to boot without BIOS services. This applies for all guests, but of particular interest to us are i686/x86_64 guests.
(3) SeaBIOS is a free, open source PC BIOS implementation. It is what we use to provide services to i686/x86_64 PC guests.
(4) Although qemu itself bundles some binary BIOSes, in Fedora we have chosen to recompile these from source. We now (on i686/x86_64) compile or cross-compile all ROMs from source.
(5) 'seabios-bin' is the name of the RPM package that contains the SeaBIOS ROMs. I have no idea why (historical?) this package has '-bin' in the name, but the important point is that it is NOT a binary-only package. It is built from source.
(6) In order to compile SeaBIOS you need a program called 'iasl' (part of the ACPICA.org project). This program is needed to compile the ACPI tables which are an integral part of the ROM data that is needed for i686/x86_64 guests to boot.
(7) Unfortunately the iasl program, which runs fine on little-endian platforms, has endianness issues. Such that when you run it on a ppc64 host it produces big-endian ACPI tables, which are of course completely broken. 'iasl' itself is a very large program, and I do not know the scope of the fix for this issue -- it may be trivial, or it may require auditing every line of code.
Therefore:
We would like a packaging exception which would allow us to import the seabios-bin package (built on little-endian) into the ppc & ppc64 buildroots.
Rich.
I'm all for it. We wouldn't ship a binary without sources, just one that got compiled on a x86 Fedora builder and got repackaged for PPC. As you can see in bugzillas 866664, 856856 and 865013, fixing iasl might become a major effort and the other option of dropping x86 support in the PPC qemu doesn't seem the right thing to do here.
Karsten (PPC secondary arch maintainer)
Il 16/10/2012 18:27, Karsten Hopp ha scritto:
Am 16.10.2012 16:19, schrieb Richard W.M. Jones:
[Bug: https://bugzilla.redhat.com/show_bug.cgi?id=866664]
Here's the situation, since the bug doesn't explain it well.
(1) qemu can run any architecture on any other architecture, using software emulation. eg. It can run x86_64 guest operating systems on top of ppc64 hosts (albeit not at full speed).
(2) In order to run guests, you have to provide a BIOS (or some sort of other boot ROM), since most guests wouldn't be able to boot without BIOS services. This applies for all guests, but of particular interest to us are i686/x86_64 guests.
(3) SeaBIOS is a free, open source PC BIOS implementation. It is what we use to provide services to i686/x86_64 PC guests.
(4) Although qemu itself bundles some binary BIOSes, in Fedora we have chosen to recompile these from source. We now (on i686/x86_64) compile or cross-compile all ROMs from source.
(5) 'seabios-bin' is the name of the RPM package that contains the SeaBIOS ROMs. I have no idea why (historical?) this package has '-bin' in the name, but the important point is that it is NOT a binary-only package. It is built from source.
(6) In order to compile SeaBIOS you need a program called 'iasl' (part of the ACPICA.org project). This program is needed to compile the ACPI tables which are an integral part of the ROM data that is needed for i686/x86_64 guests to boot.
(7) Unfortunately the iasl program, which runs fine on little-endian platforms, has endianness issues. Such that when you run it on a ppc64 host it produces big-endian ACPI tables, which are of course completely broken. 'iasl' itself is a very large program, and I do not know the scope of the fix for this issue -- it may be trivial, or it may require auditing every line of code.
Therefore:
We would like a packaging exception which would allow us to import the seabios-bin package (built on little-endian) into the ppc & ppc64 buildroots.
I'm all for it. We wouldn't ship a binary without sources, just one that got compiled on a x86 Fedora builder and got repackaged for PPC. As you can see in bugzillas 866664, 856856 and 865013, fixing iasl might become a major effort and the other option of dropping x86 support in the PPC qemu doesn't seem the right thing to do here.
Alternatively, it would also be good to get a generic exception that would let us distribute pre-compiled .dsl files as RPM sources. I'll try to get ppc & ppc64 to use a cross-compiled SeaBIOS.
One advantage of this is that upstream we're going to move the iasl-compiled files from SeaBIOS to QEMU. Such a generic exception would cause less problems once this actually happens.
Paolo
On Tue, Oct 16, 2012 at 06:39:05PM +0200, Paolo Bonzini wrote:
Alternatively, it would also be good to get a generic exception that would let us distribute pre-compiled .dsl files as RPM sources. I'll try to get ppc & ppc64 to use a cross-compiled SeaBIOS.
I think it'd be good for the packaging committee (as well as for me) if you could explain what the pre-compiled .dsl files contain. Is it just tables of ACPI data, or code as well? I understand from the ACPICA website that ACPI has some sort of interpreter or VM?
Rich.
Il 16/10/2012 19:57, Richard W.M. Jones ha scritto:
Alternatively, it would also be good to get a generic exception that would let us distribute pre-compiled .dsl files as RPM sources. I'll try to get ppc & ppc64 to use a cross-compiled SeaBIOS.
I think it'd be good for the packaging committee (as well as for me) if you could explain what the pre-compiled .dsl files contain. Is it just tables of ACPI data, or code as well? I understand from the ACPICA website that ACPI has some sort of interpreter or VM?
Imdeed, the files contain bytecode. Here is a sample input:
============= ACPI_EXTRACT_ALL_CODE ssdp_susp_aml
DefinitionBlock ("ssdt-susp.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1) { Scope() { ACPI_EXTRACT_NAME_STRING acpi_s3_name Name (_S3, Package (0x04) { One, /* PM1a_CNT.SLP_TYP */ One, /* PM1b_CNT.SLP_TYP */ Zero, /* reserved */ Zero /* reserved */ }) ACPI_EXTRACT_NAME_STRING acpi_s4_name ACPI_EXTRACT_PKG_START acpi_s4_pkg Name (_S4, Package (0x04) { 0x2, /* PM1a_CNT.SLP_TYP */ 0x2, /* PM1b_CNT.SLP_TYP */ Zero, /* reserved */ Zero /* reserved */ }) Name (_S5, Package (0x04) { Zero, /* PM1a_CNT.SLP_TYP */ Zero, /* PM1b_CNT.SLP_TYP */ Zero, /* reserved */ Zero /* reserved */ }) } } =============
and the distributed file could be (depending on the details of the build process) either something like this:
============= static unsigned char ssdp_susp_aml[] = { 0x53, 0x53, 0x44, 0x54, 0x4e, 0x0, 0x0, 0x0, 0x1, 0x45, 0x42, 0x58, 0x50, 0x43, 0x0, 0x0, 0x42, 0x58, 0x53, 0x53, 0x44, 0x54, 0x53, 0x55, 0x1, 0x0, 0x0, 0x0, 0x49, 0x4e, 0x54, 0x4c, 0x28, 0x5, 0x10, 0x20, 0x10, 0x29, 0x5c, 0x0, 0x8, 0x5f, 0x53, 0x33, 0x5f, 0x12, 0x6, 0x4, 0x1, 0x1, 0x0, 0x0, 0x8, 0x5f, 0x53, 0x34, 0x5f, 0x12, 0x8, 0x4, 0xa, 0x2, 0xa, 0x2, 0x0, 0x0, 0x8, 0x5f, 0x53, 0x35, 0x5f, 0x12, 0x6, 0x4, 0x0, 0x0, 0x0, 0x0 }; =============
or something like this:
============= Intel ACPI Component Architecture ASL Optimizing Compiler version 20100528 [Jul 20 2012] Copyright (c) 2000 - 2010 Intel Corporation Supports ACPI Specification Revision 4.0a
Compilation of "out/ssdt-susp.dsl.i" - Tue Oct 16 13:16:52 2012
1.... 2..../* ACPI_EXTRACT_ALL_CODE ssdp_susp_aml */ 3.... 4....DefinitionBlock ("ssdt-susp.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
00000000....53 53 44 54 4E 00 00 00 "SSDTN..." 00000008....01 45 42 58 50 43 00 00 ".EBXPC.." 00000010....42 58 53 53 44 54 53 55 "BXSSDTSU" 00000018....01 00 00 00 49 4E 54 4C "....INTL" 00000020....28 05 10 20 ............ "(.. "
5....{ 6.... Scope() {
00000024....10 29 5C 00 ............ ".)."
7.... 8..../* ACPI_EXTRACT_NAME_STRING acpi_s3_name */ 9.... 10.... Name (_S3, Package (0x04) 11.... { 12.... One, 13.... One, 14.... Zero, 15.... Zero 16.... })
00000028....08 5F 53 33 5F ......... "._S3_" 0000002D....12 06 04 01 01 00 00 ... "......."
17.... 18..../* ACPI_EXTRACT_NAME_STRING acpi_s4_name */ 19.... 20.... 21..../* ACPI_EXTRACT_PKG_START acpi_s4_pkg */ 22.... 23.... Name (_S4, Package (0x04) 24.... { 25.... 0x2, 26.... 0x2, 27.... Zero, 28.... Zero 29.... })
00000042....08 5F 53 35 5F ......... "._S5_" 00000047....12 06 04 00 00 00 00 ... "......." 37.... } 38....} 39....
Summary of errors and warnings
ASL Optimizing Compiler version 20100528 [Jul 20 2012] ASL Input: out/ssdt-susp.dsl.i - 40 lines, 677 bytes, 4 keywords AML Output: out/ssdt-susp.aml - 78 bytes, 4 named objects, 0 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations =============
Paolo
Il 16/10/2012 18:27, Karsten Hopp ha scritto:
We would like a packaging exception which would allow us to import the seabios-bin package (built on little-endian) into the ppc & ppc64 buildroots.
I'm all for it. We wouldn't ship a binary without sources, just one that got compiled on a x86 Fedora builder and got repackaged for PPC. As you can see in bugzillas 866664, 856856 and 865013, fixing iasl might become a major effort and the other option of dropping x86 support in the PPC qemu doesn't seem the right thing to do here.
Quick googling revealed Debian patches that fix all the endianness issues and let SeaBIOS be built with a cross-compiler.
The only snag is that the Debian patches are against an older version of iasl than what is now in rawhide. But the new version was imported in rawhide just last week by Richard, presumably in an attempt to fix this problem, and IMO can be reverted to the older one. I'm not sure if it requires bumping the epoch of the iasl package, but that's a minor evil.
Paolo
On Wed, Oct 17, 2012 at 09:44:08AM +0200, Paolo Bonzini wrote:
Il 16/10/2012 18:27, Karsten Hopp ha scritto:
We would like a packaging exception which would allow us to import the seabios-bin package (built on little-endian) into the ppc & ppc64 buildroots.
I'm all for it. We wouldn't ship a binary without sources, just one that got compiled on a x86 Fedora builder and got repackaged for PPC. As you can see in bugzillas 866664, 856856 and 865013, fixing iasl might become a major effort and the other option of dropping x86 support in the PPC qemu doesn't seem the right thing to do here.
Quick googling revealed Debian patches that fix all the endianness issues and let SeaBIOS be built with a cross-compiler.
The only snag is that the Debian patches are against an older version of iasl than what is now in rawhide. But the new version was imported in rawhide just last week by Richard, presumably in an attempt to fix this problem, and IMO can be reverted to the older one. I'm not sure if it requires bumping the epoch of the iasl package, but that's a minor evil.
OK, although the new version of iasl is also a lot more sane (in terms of build system, lack of gross C errors) than the old version.
Maybe the Debian patch can be applied to the new version instead?
Rich.
Il 17/10/2012 11:27, Richard W.M. Jones ha scritto:
OK, although the new version of iasl is also a lot more sane (in terms of build system, lack of gross C errors) than the old version.
Maybe the Debian patch can be applied to the new version instead?
I can look into it for Rawhide, but in the meanwhile I think it is simpler to just revert the upgrade. Can you double-check whether it requires an epoch bump?
Paolo
On Wed, Oct 17, 2012 at 11:52:30AM +0200, Paolo Bonzini wrote:
Il 17/10/2012 11:27, Richard W.M. Jones ha scritto:
OK, although the new version of iasl is also a lot more sane (in terms of build system, lack of gross C errors) than the old version.
Maybe the Debian patch can be applied to the new version instead?
I can look into it for Rawhide, but in the meanwhile I think it is simpler to just revert the upgrade. Can you double-check whether it requires an epoch bump?
Definitely it would, unless we ignore existing Rawhide users.
Rich.
Il 17/10/2012 11:59, Richard W.M. Jones ha scritto:
On Wed, Oct 17, 2012 at 11:52:30AM +0200, Paolo Bonzini wrote:
Il 17/10/2012 11:27, Richard W.M. Jones ha scritto:
OK, although the new version of iasl is also a lot more sane (in terms of build system, lack of gross C errors) than the old version.
Maybe the Debian patch can be applied to the new version instead?
I can look into it for Rawhide, but in the meanwhile I think it is simpler to just revert the upgrade. Can you double-check whether it requires an epoch bump?
Definitely it would, unless we ignore existing Rawhide users.
Forward-porting the patches was a bit tedious, but doable, so now we have a big-endian-friendly iasl in F18 and the one in F19 is on its way.
I am a package maintainer for SeaBIOS, so I already pushed to distgit the spec changes that enable cross-compilation.
So things should be set... Karsten, feel free to bump the seabios release if needed to force a recompilation on PPC (also it will require a iasl build-override, but I don't need to tell you about that :).
The request for exception can be retired, I guess.
Paolo
On Tue, Oct 16, 2012 at 03:19:20PM +0100, Richard W.M. Jones wrote:
To summarise for everyone: Debian had patches to fix the endianness issues, and Paolo Bonzini did all the work of forward-porting these to Rawhide and getting them into F18 & Rawhide.
So we should be good, don't need the exception.
Rich.
packaging@lists.fedoraproject.org
-
Karsten Hopp -
Paolo Bonzini -
Richard W.M. Jones