When I kexec either Xen or Linux in real mode, from either Xen or Linux, it fails.
The last thing I see looks like SeaBIOS trying to use SMM for call32:
---------------- IN: 0x00000000000f70ec: mov %eax,%esi 0x00000000000f70ef: mov $0xb5,%eax 0x00000000000f70f5: mov $0x1234,%ecx 0x00000000000f70fb: mov $0xef3dc,%ebx 0x00000000000f7101: out %al,$0xb2 0x00000000000f7103: pause
---------------- IN: 0x00000000000ef3db: hlt
This happens when the real mode boot code calls INT 13h to read from the disk. It seems to happen with virtio and SATA disks.
This is with the Ubuntu-packaged 1.10.2-1ubuntu1 SeaBIOS. Switching to an IDE disk, or booting with 'edd=skipmbr', makes Xen work and Linux get a little further before it dies anyway.
On Mon, Apr 29, 2019 at 12:05:33AM +0300, David Woodhouse wrote:
When I kexec either Xen or Linux in real mode, from either Xen or Linux, it fails.
The last thing I see looks like SeaBIOS trying to use SMM for call32:
IN: 0x00000000000f70ec: mov %eax,%esi 0x00000000000f70ef: mov $0xb5,%eax 0x00000000000f70f5: mov $0x1234,%ecx 0x00000000000f70fb: mov $0xef3dc,%ebx 0x00000000000f7101: out %al,$0xb2 0x00000000000f7103: pause
IN: 0x00000000000ef3db: hlt
This happens when the real mode boot code calls INT 13h to read from the disk. It seems to happen with virtio and SATA disks.
This is with the Ubuntu-packaged 1.10.2-1ubuntu1 SeaBIOS. Switching to an IDE disk, or booting with 'edd=skipmbr', makes Xen work and Linux get a little further before it dies anyway.
Hi David,
That call trace certainly looks odd. The SeaBIOS debugging info would help - try compiling SeaBIOS with debug level 8 and grab the log (as described at: https://www.seabios.org/Debugging#Diagnostic_information ).
-Kevin
On Tue, 2019-04-30 at 22:56 -0400, Kevin O'Connor wrote:
Hi David,
That call trace certainly looks odd. The SeaBIOS debugging info would help - try compiling SeaBIOS with debug level 8 and grab the log (as described at: https://www.seabios.org/Debugging#Diagnostic_information ).
Choosing Xen because it actually succeeds, while Linux real-mode boot then dies a bit later even if I use IDE disks...
This SeaBIOS git master (f4c6e4c1) with an IDE disk, from the moment of kexec:
unimplemented handle_15XX:330: a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=0060 f=0246 enter handle_12: a=534d3c00 b=0000befe c=00003c00 d=002ffb80 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000af1 bp=00000000 sp=0000fe8e cs=8f00 ip=0143 f=0202 invalid handle_legacy_disk:729: a=534d4139 b=000055aa c=0000fe03 d=002ffb81 ds=8f00 es=8f00 ss=d980 si=00001539 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=015b f=0293 invalid handle_legacy_disk:729: a=534d0201 b=00000000 c=889f0001 d=002f0081 ds=8f00 es=8ee0 ss=d980 si=0000aa55 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=0202 f=0247 Xen 4.11.2-pre (XEN) Xen version 4.11.2-pre (dwmw@ant.amazon.com) (gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0) debug=n Wed May 1 22:08:39 IDT 2019 (XEN) Latest ChangeSet: Wed May 1 13:37:09 2019 +0300 git:7c281700a8 (XEN) Bootloader: kexec 2.0.19.git (XEN) Command line: console=vga,com1 (XEN) Xen image load base address: 0 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures
And this is all I see when the disk is virtio:
unimplemented handle_15XX:330: a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=0060 f=0246 enter handle_12: a=534d3c00 b=0000befd c=00003c00 d=002ffb40 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000af1 bp=00000000 sp=0000fe8e cs=8f00 ip=0143 f=0202 invalid handle_legacy_disk:729: a=534d4139 b=000055aa c=0000fe03 d=002ffb81 ds=8f00 es=8f00 ss=d980 si=00001539 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=015b f=0293
Increasing debug to 9, I see:
enter handle_15: a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000000 bp=00000000 sp=0000f96e cs=8f00 ip=0060 f=0246 unimplemented handle_15XX:330: a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000000 bp=00000000 sp=0000f96e cs=8f00 ip=0060 f=0246 enter handle_15: a=0000e820 b=00000000 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000a51 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0246 enter handle_15: a=0000e820 b=00000001 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000a65 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202 enter handle_15: a=0000e820 b=00000002 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000a79 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202 enter handle_15: a=0000e820 b=00000003 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000a8d bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0206 enter handle_15: a=0000e820 b=00000004 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000aa1 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202 enter handle_15: a=0000e820 b=00000005 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000ab5 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0206 enter handle_15: a=0000e820 b=00000006 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000ac9 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0206 enter handle_15: a=0000e820 b=00000007 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000add bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202 enter handle_15: a=534d88f1 b=00000000 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000af1 bp=00000000 sp=0000f96e cs=8f00 ip=0112 f=0246 enter handle_15: a=534de801 b=00000000 c=00000000 d=534d0000 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000af1 bp=00000000 sp=0000f96e cs=8f00 ip=011f f=0246 enter handle_12: a=534d3c00 b=0000befd c=00003c00 d=002ffb40 ds=8f00 es=8f00 ss=d980 si=00000000 di=00000af1 bp=00000000 sp=0000f96e cs=8f00 ip=0143 f=0202 invalid handle_legacy_disk:729: a=534d4139 b=000055aa c=0000fe03 d=002ffb81 ds=8f00 es=8f00 ss=d980 si=00001539 di=00000000 bp=00000000 sp=0000f96e cs=8f00 ip=015b f=0293 call32_smm 0x000ed91a e9120 handle_smi cmd=b5 smbase=0x000a0000 vp notify fe003000 (2) -- 0x0 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 handle_smi cmd=b5 smbase=0x000a0000 handle_smi cmd=b5 smbase=0x000a0000 call16_smm 0x00007a79 0 0 ...
That just goes on for ever. The full log from boot (including the boot of the first kernel) is at http://david.woodhou.se/smi-wtf.txt
Hi David,
On Wed, May 01, 2019 at 11:16:03PM +0300, David Woodhouse wrote:
On Tue, 2019-04-30 at 22:56 -0400, Kevin O'Connor wrote:
That call trace certainly looks odd. The SeaBIOS debugging info would help - try compiling SeaBIOS with debug level 8 and grab the log (as described at: https://www.seabios.org/Debugging#Diagnostic_information ).
Choosing Xen because it actually succeeds, while Linux real-mode boot then dies a bit later even if I use IDE disks...
[...]
The full log from boot (including the boot of the first kernel) is at http://david.woodhou.se/smi-wtf.txt
From that log, it doesn't look like SeaBIOS itself is reset during the kexec. I could be wrong, but here's my understanding of that log:
- SeaBIOS starts normally and initializes the virtio-blk device
- SeaBIOS hands control to the bootloader. The bootloader makes various BIOS calls that read blocks from the virtio-blk device.
- At some point the bootloader loads Linux. Linux reinitializes the virtio-blk device to its liking.
- At some point, a kexec occurs and then SeaBIOS gets a request to read data from the virtio-blk device. However, the virtio-blk device was reset by Linux, so the SeaBIOS' device structures are no longer valid.
- SeaBIOS waits indefinitely for a virtio notify event that it wont ever receive (because it is waiting on a control structure that the virtio-blk device is no longer configured to use).
If SeaBIOS doesn't get a signal to reinitialize itself, I'm not sure there's much it can do in that situation. (Though, as above, it's possible I've misread the log.)
Cheers, -Kevin
-
David Woodhouse -
Kevin O'Connor