Hi Bin, On Mon, 31 Jul 2023 at 08:46, Bin Meng <bmeng...@gmail.com> wrote: > > Hi Simon, > > On Mon, Jul 31, 2023 at 10:37 PM Simon Glass <s...@chromium.org> wrote: > > > > Hi Bin, > > > > On Mon, 31 Jul 2023 at 08:32, Bin Meng <bmeng...@gmail.com> wrote: > > > > > > Hi Simon, > > > > > > On Sat, Jul 29, 2023 at 1:32 AM Simon Glass <s...@chromium.org> wrote: > > > > > > > > Hi Bin, > > > > > > > > On Fri, 28 Jul 2023 at 09:46, Bin Meng <bmeng...@gmail.com> wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Mon, Jul 24, 2023 at 10:52 PM Simon Glass <s...@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 Regards, Simon