Hi Bin,
On Mon, 31 Jul 2023 at 11:07, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 31 Jul 2023 at 08:46, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Jul 31, 2023 at 10:37 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 31 Jul 2023 at 08:32, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Jul 29, 2023 at 1:32 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Fri, 28 Jul 2023 at 09:46, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Jul 24, 2023 at 10:52 PM Simon Glass sjg@chromium.org wrote: > > Unfortunately the bochs driver does not currently work with distros. It > causes a hang sometime between grub menu selection and the OS displaying > something.
Does this reproduce reliably?
Yes, it does.
BTW I've also hit another problem with '-M accel-kvm' which hangs on the move to 64-bit mode. Oddly if I boot U-Boot from coreboot, the problem goes away. So perhaps coreboot is doing some x86 init which U-Boot is missing.
This indicates a kvm-x86 bug. I think you can simplify a test case and report it to the KVM mailing list.
Firstly it doesn't really matter, since it doesn't work, so we do need to revert.
Agreed, but before we revert this, I would like to see we investigate this issue a little bit further.
I enabled the grub debug output today and not sure if grub jumps to the kernel entry yet:
kern/verifiers.c:214: string: boot, type: 2 loader/efi/linux_sb.c:55: kernel_addr: 0x1000000 handover_offset: 0x190 params: 0x7ce63000
Secondly I am not sure it kvm's fault, since the problem does not happen with coreboot. I will see if I can isolate what coreboot is doing differently, but not sure that that fix will make the release.
Does the 64-bit mode switch ever work on a real x86 board? If yes, then it's very likely a KVM bug.
Yes it works fine on chromebook_link64, for example.
If not, then we can check the coreboot to find out the difference.
Yes...do you have any ideas?
If it helps, I am using something like this:
qemu-system-x86_64 -m 8G -smp 4 -bios /tmp/b/qemu-x86_64/u-boot.rom -drive id=fdisk,file=root.img,if=virtio,driver=raw -drive \ file=/vid/software/linux/ubuntu/ubuntu-23.04-desktop-amd64.iso,if=virtio,driver=raw \ -serial mon:stdio
For coreboot my script is:
UBTEST=/vid/software/devel/ubtest/ BUILD_DIR=/tmp/b/coreboot64 DISK=/vid/software/linux/ubuntu/ubuntu-23.04-desktop-amd64.iso
cp $UBTEST/coreboot.rom.in $BUILD_DIR/coreboot.rom cbfstool $BUILD_DIR/coreboot.rom add-flat-binary \ -f $BUILD_DIR/u-boot-x86-with-spl.bin \ -n fallback/payload -c LZMA -l 0x1110000 -e 0x1110000
Add this in below: #-M accel=kvm
qemu-system-x86_64 -m 2G -smp 4 -bios $BUILD_DIR/coreboot.rom -serial mon:stdio \ -drive id=disk,file=$DISK,if=none \ -device ahci,id=ahci \ -device ide-hd,drive=disk,bus=ahci.0
I haven't looked into the problem here, but I did notice this coreboot commit: https://review.coreboot.org/c/coreboot/+/49228
I am not sure it is related though, since we already have page tables in RAM.
Regards, Simon