Created attachment 940927 [details]
Bad 'xl dmesg' output

A bit of tweaking and I found out that if I build the xen RPMs without "--with-system-seabios=/usr/share/seabios/bios.bin" it boots fine.

A bit of digging in and I found out that hvmloader slurps up the bios images during build. For fun I decided to replace /usr/share/seabios/bios.bin with a 1.7.5 (configured using Xen's configuration found in tools/firmware/seabios-config). And that worked fine!

Now off to figure out why the seabios-bin RPM which is suppose to be 1.7.5 does not work.

Well that was easy. The seabios-bin has: "CONFIG_XEN=n" in its .config!

And sure enough, changing in config.seabios-128k from CONFIG_XEN=n to CONFIG_XEN=y, rebuilding, installing, and rebuilding Xen RPMS (so that they can pick up the new /usr/share/seabios/bios.bin) and it all works.

Re-assigning to seabios maintainers.

Sorry about that, wasn't away xen was using the seabios package.

The reason Xen is disabled is to keep the legacy bios.bin under 128k to preserve migration compatibility. I just tested locally and it appears enabling xen does still keep us under the size constraints, so it should be okay. CCing Gerd to see confirm

Also, does xen use the /usr/share/... bios path explicitly, or does it just depend on qemu to do the right thing? Because if you guys are accessing paths directly, you probably want to mimic what qemu does with bios.bin vs bios-256k.bin so new VMs pick up the latest seabios features.

(In reply to Cole Robinson from comment #5)
> Sorry about that, wasn't away xen was using the seabios package.
> 
> The reason Xen is disabled is to keep the legacy bios.bin under 128k to
> preserve migration compatibility. I just tested locally and it appears
> enabling xen does still keep us under the size constraints, so it should be
> okay. CCing Gerd to see confirm

I can confirm it too (since I did a local build)

> 
> Also, does xen use the /usr/share/... bios path explicitly, or does it just
> depend on qemu to do the right thing? Because if you guys are accessing
> paths directly, you probably want to mimic what qemu does with bios.bin vs
> bios-256k.bin so new VMs pick up the latest seabios features.

It does not use it during run-time (hence there are no run-time requirements for it), but it does use it during build-time. At build-time is slurps up /usr/share/seabios/bios.bin and packs in an 'hvmloader' binary. The 'hvmloader' is executed as a guest - and it figures out Xen related things (using hypercalls and such), and once it has finished that it launches one of the BIOSes it has
in its memory - SeaBIOS or the Bochs BIOS one (The other BIOSes that are slurped up are removed from memory).

(In reply to Cole Robinson from comment #5)
> Sorry about that, wasn't away xen was using the seabios package.
> 
> The reason Xen is disabled is to keep the legacy bios.bin under 128k to
> preserve migration compatibility. I just tested locally and it appears
> enabling xen does still keep us under the size constraints, so it should be
> okay. CCing Gerd to see confirm
> 
> Also, does xen use the /usr/share/... bios path explicitly, or does it just
> depend on qemu to do the right thing? Because if you guys are accessing
> paths directly, you probably want to mimic what qemu does with bios.bin vs
> bios-256k.bin so new VMs pick up the latest seabios features.

I started trying to use Fedora's seabios in Fedora 20 xen to avoid source code duplication (by default xen 4.3+ pulls in the seabios source code), and unfortunately I hadn't spotted it didn't work. I don't see why we can't switch to the 256k seabios if it works with xen.

> I started trying to use Fedora's seabios in Fedora 20 xen to avoid source
> code duplication (by default xen 4.3+ pulls in the seabios source code), and
> unfortunately I hadn't spotted it didn't work. I don't see why we can't
> switch to the 256k seabios if it works with xen.

IIRC xen has a size limit of 256k for seabios+hvmloader, so using the 256k bios as-is isn't going to fly (unless this has changed recently).  128k bios works only if we turn off some features, also not good.

hvmloader can deal with seabios having odd sizes (not a power of two) though.  So we can add a third configuration, with CONFIG_ROM_SIZE=192 + CONFIG_XEN=y + nothing turned off to match the 128k mark, which xen can pick up them.

But we don't need to switch to 256K? If you build the seabios RPM with CONFIG_XEN=y it is still under 128k.

What am I missing? Oh, Gerd want to turn on _all_ of the features on instead of selectively disabling some.

I hadn't tried to see what would be involved in lifting the 256K for seabios+hvmloader - thought I am not sure if the limit is there - as the hvmloader blob is 787kB.

I can experiment with different sizes on Monday and report what the results are.
And if there are limits, we can focus on getting them done for Xen 4.6.

> What am I missing? Oh, Gerd want to turn on _all_ of the features on instead
> of selectively disabling some.

Exactly.  The 128k has XHCI support turned off for example to make it fit, and IIRC one of the newer scsi adapters (pvscsi?) too.

> I hadn't tried to see what would be involved in lifting the 256K for
> seabios+hvmloader - thought I am not sure if the limit is there - as the
> hvmloader blob is 787kB.

Maybe my info is wrong or outdated meanwhile.  If using the 256k version as-is works fine -- even better, we don't need a special xen config then.

Gerd,

With this change:

--- seabios.spec.old	2014-07-09 11:36:26.000000000 -0400
+++ seabios.spec	2014-09-29 09:37:07.758982848 -0400
@@ -1,6 +1,6 @@
 Name:           seabios
 Version:        1.7.5
-Release:        3%{?dist}
+Release:        4%{?dist}
 Summary:        Open-source legacy BIOS implementation
 
 Group:          Applications/Emulators
@@ -16,7 +16,6 @@
 Source14:       config.vga.vmware
 Source15:       config.csm
 Source16:       config.coreboot
-Source17:       config.seabios-128k
 Source18:       config.seabios-256k
 
 # Fix PCI-e hotplug (bz #1115598)
@@ -106,8 +105,7 @@
 # seabios
 build_bios %{SOURCE15} Csm16.bin bios-csm.bin
 build_bios %{SOURCE16} bios.bin.elf bios-coreboot.bin
-build_bios %{SOURCE17} bios.bin bios.bin
-build_bios %{SOURCE18} bios.bin bios-256k.bin
+build_bios %{SOURCE18} bios.bin bios.bin
 cp out/src/fw/*dsdt*.aml binaries
 
 # seavgabios
@@ -121,7 +119,6 @@
 mkdir -p $RPM_BUILD_ROOT%{_datadir}/seabios
 mkdir -p $RPM_BUILD_ROOT%{_datadir}/seavgabios
 install -m 0644 binaries/bios.bin $RPM_BUILD_ROOT%{_datadir}/seabios/bios.bin
-install -m 0644 binaries/bios-256k.bin $RPM_BUILD_ROOT%{_datadir}/seabios/bios-256k.bin
 install -m 0644 binaries/bios-csm.bin $RPM_BUILD_ROOT%{_datadir}/seabios/bios-csm.bin
 install -m 0644 binaries/bios-coreboot.bin $RPM_BUILD_ROOT%{_datadir}/seabios/bios-coreboot.bin
 install -m 0644 binaries/*.aml $RPM_BUILD_ROOT%{_datadir}/seabios

And with this end result:


[root@localhost noarch]# ls -al /usr/share/seabios/bios.bin
-rw-r--r--. 1 root root 262144 Sep 29 09:33 /usr/share/seabios/bios.bin


(d3) HVM Loader
(d3) Detected Xen v4.4.1
(d3) Xenbus rings @0xfeffc000, event channel 4
(d3) System requested SeaBIOS
(d3) CPU speed is 3512 MHz
(d3) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:270: Dom3 PCI link 0 changed 0 -> 5
(d3) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom3 PCI link 1 changed 0 -> 10
(d3) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom3 PCI link 2 changed 0 -> 11
(d3) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom3 PCI link 3 changed 0 -> 5
(d3) PCI-ISA link 3 routed to IRQ5
(d3) pci dev 01:2 INTD->IRQ5
(d3) pci dev 01:3 INTA->IRQ10
(d3) pci dev 02:0 INTA->IRQ11
(d3) No RAM in high memory; setting high_mem resource base to 100000000
(d3) pci dev 03:0 bar 10 size 002000000: 0f0000008
(d3) pci dev 02:0 bar 14 size 001000000: 0f2000008
(d3) pci dev 03:0 bar 30 size 000010000: 0f3000000
(d3) pci dev 03:0 bar 14 size 000001000: 0f3010000
(d3) pci dev 02:0 bar 10 size 000000100: 00000c001
(d3) pci dev 01:2 bar 20 size 000000020: 00000c101
(d3) pci dev 01:1 bar 20 size 000000010: 00000c121
(d3) Multiprocessor initialisation:
(d3)  - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d3)  - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d3) Testing HVM environment:
(d3)  - REP INSB across page boundaries ... passed
(d3)  - GS base MSRs and SWAPGS ... passed
(d3) Passed 2 of 2 tests
(d3) Writing SMBIOS tables ...
(d3) Loading SeaBIOS ...
(d3) Creating MP tables ...
(d3) Loading ACPI ...
(d3) vm86 TSS at fc00a080
(d3) BIOS map:
(d3)  10000-100d3: Scratch space
(d3)  c0000-fffff: Main BIOS
(d3) build_e820_table requested for 786432 bytes.
(d3) E820 table:
(d3)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d3)  HOLE: 00000000:000a0000 - 00000000:000c0000
(d3)  [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
(d3)  [02]: 00000000:00100000 - 00000000:3f800000: RAM
(d3)  HOLE: 00000000:3f800000 - 00000000:fc000000
(d3)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(d3) seabios_setup_e820: Image is 262144 bytes

==========> THERE, 256k BIOS no problem <===========

(d3) Invoking SeaBIOS ...
(d3) SeaBIOS (version 1.7.5-20140929_093254-localhost.localdomain)
(d3) 
(d3) Found Xen hypervisor signature at 40000000
(d3) Running on QEMU (i440fx)
(d3) xen: copy e820...
(d3) Relocating init from 0x000e05a9 to 0x3f7af330 (size 68612)
(d3) CPU Mhz=3512
(d3) Found 7 PCI devices (max PCI bus is 00)
(d3) Allocated Xen hypercall page at 3f7ff000
(d3) Detected Xen v4.4.1
(d3) xen: copy BIOS tables...
(d3) Copying SMBIOS entry point from 0x00010010 to 0x000f1190
(d3) Copying MPTABLE from 0xfc001150/fc001160 to 0x000f1090
(d3) Copying PIR from 0x00010030 to 0x000f1010
(d3) Copying ACPI RSDP from 0x000100b0 to 0x000f0fe0
(d3) Using pmtimer, ioport 0xb008
(d3) Scan for VGA option rom
(d3) Running option rom at c000:0003
(XEN) stdvga.c:147:d3 entering stdvga and caching modes
(d3) pmm call arg1=0
(d3) Turning on vga text mode console
(d3) SeaBIOS (version 1.7.5-20140929_093254-localhost.localdomain)
(d3) Machine UUID 349584c9-565c-47d6-9af4-52ce9d8ee2c2
(d3) UHCI init on dev 00:01.2 (io=c100)
(d3) Found 0 lpt ports
(d3) Found 1 serial ports
(d3) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
(d3) ATA controller 2 at 170/374/0 (irq 15 dev 9)
(d3) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
(d3) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
(d3) PS2 keyboard initialized
(d3) All threads complete.
(d3) Scan for option roms
(d3) 
(d3) Press F12 for boot menu.
(d3) 
(d3) Searching bootorder for: HALT
(d3) Space available for UMB: c9800-ee800, f0000-f0f60
(d3) Returned 258048 bytes of ZoneHigh
(d3) e820 map has 6 items:
(d3)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
(d3)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
(d3)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
(d3)   3: 0000000000100000 - 000000003f7ff000 = 1 RAM
(d3)   4: 000000003f7ff000 - 000000003f800000 = 2 RESERVED
(d3)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
(d3) enter handle_19:
(d3)   NULL
(d3) Booting from DVD/CD...
(d3) Booting from 0000:7c00


It is happy enough to load an 256K BIOS image.

  Hi,

> @@ -16,7 +16,6 @@
>  Source14:       config.vga.vmware
>  Source15:       config.csm
>  Source16:       config.coreboot
> -Source17:       config.seabios-128k
>  Source18:       config.seabios-256k

That isn't going to fly.  We need both 128k and 256k bios for qemu.  qemu switched from 128k to 256k with the 1.7 release.  Old machine types (-M pc-i440fx-1.6) continue to use the 128k bios though, for backward compatibility reasons.

> (d3) seabios_setup_e820: Image is 262144 bytes
> 
> ==========> THERE, 256k BIOS no problem <===========
> 
> (d3) Invoking SeaBIOS ...
> (d3) SeaBIOS (version 1.7.5-20140929_093254-localhost.localdomain)
 
> It is happy enough to load an 256K BIOS image.

Great.  Is it possible to make xen simply use bios-256k.bin instead of bios.bin?

xen-4.4.1-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/xen-4.4.1-5.fc21

xen-4.4.1-6.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/xen-4.4.1-6.fc21

Excellent. Tested it and it works correctly. Thank you!

Package xen-4.4.1-6.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xen-4.4.1-6.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12002/xen-4.4.1-6.fc21
then log in and leave karma (feedback).

xen-4.4.1-6.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.