| Message ID | 20250216204421.3560012-1-sjg@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86: Improve operation under QEMU | expand |
On 2/16/25 21:43, Simon Glass wrote: > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > is not perfect. > > With both builds, executing the VESA ROM causes an intermittent hang, at > least on some AMD CPUs. > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > is done in a way that works on real hardware but not with QEMU. This > means that performance is 4-5x slower than it could be, at least on my > CPU. Do you have a reproducer for this? It shouldn't happen... also, do you know if this is broken for both Intel and AMD CPUs? Thanks, Paolo > We can work around the first problem by using Bochs, which is anyway a > better choice than VESA for QEMU. The second can be addressed by using > the same descriptor across the jump to long mode. > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > Changes in v2: > - Redo commit message > - Add new patch to rename the _D dirty flag > - Add new patch to support CPU functions in long mode > - Add new patch to tidy up address size in MTRR calculations > - Add new patch with a 64-bit version of is_power_of_2() > - Add new patch to set an MTRR for the RAM in QEMU > - Add new patch with a helper to send characters > - Add new patch to allow tests to be filtered by role > - Add more patches to support booting with kvm > - Add new patch with a test for booting Ubuntu 24.04 > > Simon Glass (28): > x86: Expand x86_64 early memory > x86: qemu: Switch to bochs display > x86: qemu: Enable dhrystone > x86: qemu: Avoid accessing BSS too early > x86: Drop mpspec from the SPL build > x86: Add some log categories > x86: Drop use of CONFIG_REALMODE_DEBUG > x86: Avoid clearing the VESA display > x86: Add 64-bit entries to the GDT > x86: Use defines for the cache flags > x86: spl: Drop duplicate CPU init > x86: Drop the message about features missing in 64-bit > x86: Include stdbool.h in interrupt header > x86: Tidy up the GDT size in start/16.S > x86: Disable paging before changing to long mode > x86: Use the same GDT when jumping to long mode > x86: Use a simple jump into long mode > x86: Rename the _D dirty flag > x86: Support CPU functions in long mode > x86: Tidy up address size in MTRR calculations > Add a 64-bit version of is_power_of_2() > x86: Support MTRRs of 4GB on 32-bit machines > x86: emulation: Set an MTRR for the RAM > scripts: Expand a few options > test/py: Add a helper to send characters > test/py: Allow tests to be filtered by role > RFC: test/py: Deal with timeouts > test: Add a test for booting Ubuntu 24.04 > > .gitlab-ci.yml | 5 +++ > arch/x86/cpu/cpu.c | 24 +++++++++++++++ > arch/x86/cpu/i386/call64.S | 35 +++++++++------------ > arch/x86/cpu/i386/cpu.c | 41 +++++++++--------------- > arch/x86/cpu/mtrr.c | 12 +++++--- > arch/x86/cpu/qemu/dram.c | 15 +++++++++ > arch/x86/cpu/qemu/qemu.c | 20 ++++++++---- > arch/x86/cpu/start.S | 4 ++- > arch/x86/cpu/start16.S | 3 +- > arch/x86/cpu/x86_64/cpu.c | 5 --- > arch/x86/include/asm/cpu.h | 35 ++++++++++++++++++--- > arch/x86/include/asm/interrupt.h | 1 + > arch/x86/include/asm/processor.h | 5 ++- > arch/x86/lib/Makefile | 2 ++ > arch/x86/lib/bios.c | 27 +++++++++------- > arch/x86/lib/bios_interrupts.c | 8 ++--- > arch/x86/lib/i8259.c | 2 ++ > arch/x86/lib/spl.c | 4 +-- > configs/qemu-x86_64_defconfig | 10 +++--- > configs/qemu-x86_defconfig | 6 ++-- > include/linux/log2.h | 6 ++++ > scripts/build-qemu.sh | 4 +-- > test/py/conftest.py | 22 +++++++++++++ > test/py/console_base.py | 33 ++++++++++++-------- > test/py/pytest.ini | 1 + > test/py/tests/test_distro.py | 53 ++++++++++++++++++++++++++++++++ > test/py/tests/test_sleep.py | 1 + > 27 files changed, 273 insertions(+), 111 deletions(-) > create mode 100644 test/py/tests/test_distro.py >
On Sun, Feb 16, 2025 at 01:43:45PM -0700, Simon Glass wrote: > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > is not perfect. > > With both builds, executing the VESA ROM causes an intermittent hang, at > least on some AMD CPUs. > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > is done in a way that works on real hardware but not with QEMU. This > means that performance is 4-5x slower than it could be, at least on my > CPU. > > We can work around the first problem by using Bochs, which is anyway a > better choice than VESA for QEMU. The second can be addressed by using > the same descriptor across the jump to long mode. > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 This seems needlessly not against mainline.
Hi Tom, On Sun, 16 Feb 2025 at 14:57, Tom Rini <trini@konsulko.com> wrote: > > On Sun, Feb 16, 2025 at 01:43:45PM -0700, Simon Glass wrote: > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > > is not perfect. > > > > With both builds, executing the VESA ROM causes an intermittent hang, at > > least on some AMD CPUs. > > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > > is done in a way that works on real hardware but not with QEMU. This > > means that performance is 4-5x slower than it could be, at least on my > > CPU. > > > > We can work around the first problem by using Bochs, which is anyway a > > better choice than VESA for QEMU. The second can be addressed by using > > the same descriptor across the jump to long mode. > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > This seems needlessly not against mainline. I just tried it and yes there is a very small delta. I can resend it rebased to -next if you like. I'd really like to get some OS-booting tests into CI. Regards, Simon
Hi Paolo, On Sun, 16 Feb 2025 at 14:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 2/16/25 21:43, Simon Glass wrote: > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > > is not perfect. > > > > With both builds, executing the VESA ROM causes an intermittent hang, at > > least on some AMD CPUs. > > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > > is done in a way that works on real hardware but not with QEMU. This > > means that performance is 4-5x slower than it could be, at least on my > > CPU. > > Do you have a reproducer for this? It shouldn't happen... also, do you > know if this is broken for both Intel and AMD CPUs? You can see this if you build the right commit (e52e307c7ca) from my tree[1], i.e. after U-Boot changes to Bochs and before it changes the 64-bit entry mechanism: 04:57 $ pe e52e307c7ca (HEAD) x86: qemu: Switch to bochs display 83f8b00df47 x86: Expand x86_64 early memory 71a6c3eb3d8 Revert "efi_memory: do not add U-Boot memory to the memory map" d9d87e11e97 test: Make net tests depend on CONFIG_CMD_NET 3c67e62b109 test/py: Show info about module-loading 7059d976d22 test/py: Drop assigning ubman to cons e361abfc638 test/py: Drop importing utils as util 460ecb6e5cd test/py: Drop u_boot_ prefix on test files cc5600e734c test/py: Shorten u_boot_console 777c7a0c20e test: Update documentation ✔ ~/u [:e52e307c7ca|…6⚑ 1160] 04:57 $ ./tools/buildman/buildman --bo qemu-x86_64 -o /tmp/b/qemu-x86_64/ -w Building current source for 1 boards (1 thread, 32 jobs per thread) 1 0 0 /1 qemu-x86_64 Completed: 1 total built, 1 newly), duration 0:00:02, rate 0.50 ✔ ~/u [:e52e307c7ca|…6⚑ 1160] 04:57 $ qemu-system-x86_64 -bios /tmp/b/qemu-x86_64/u-boot.rom -enable-kvm -nographic Running qemu-system-x86_64 -display none -serial mon:stdio U-Boot SPL 2025.01-rc3-00635-ge52e307c7ca8 (Feb 17 2025 - 04:57:59 -0700) Trying to boot from SPI Jumping to 64-bit U-Boot: Note many features are missing (hangs here) QEMU: Terminated I am running this on an AMD system. But I just tried it on an Intel laptop and it has the same issue. > > Thanks, > > Paolo > Regards, Simon > > We can work around the first problem by using Bochs, which is anyway a > > better choice than VESA for QEMU. The second can be addressed by using > > the same descriptor across the jump to long mode. > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > > > Changes in v2: > > - Redo commit message > > - Add new patch to rename the _D dirty flag > > - Add new patch to support CPU functions in long mode > > - Add new patch to tidy up address size in MTRR calculations > > - Add new patch with a 64-bit version of is_power_of_2() > > - Add new patch to set an MTRR for the RAM in QEMU > > - Add new patch with a helper to send characters > > - Add new patch to allow tests to be filtered by role > > - Add more patches to support booting with kvm > > - Add new patch with a test for booting Ubuntu 24.04 > > > > Simon Glass (28): > > x86: Expand x86_64 early memory > > x86: qemu: Switch to bochs display > > x86: qemu: Enable dhrystone > > x86: qemu: Avoid accessing BSS too early > > x86: Drop mpspec from the SPL build > > x86: Add some log categories > > x86: Drop use of CONFIG_REALMODE_DEBUG > > x86: Avoid clearing the VESA display > > x86: Add 64-bit entries to the GDT > > x86: Use defines for the cache flags > > x86: spl: Drop duplicate CPU init > > x86: Drop the message about features missing in 64-bit > > x86: Include stdbool.h in interrupt header > > x86: Tidy up the GDT size in start/16.S > > x86: Disable paging before changing to long mode > > x86: Use the same GDT when jumping to long mode > > x86: Use a simple jump into long mode > > x86: Rename the _D dirty flag > > x86: Support CPU functions in long mode > > x86: Tidy up address size in MTRR calculations > > Add a 64-bit version of is_power_of_2() > > x86: Support MTRRs of 4GB on 32-bit machines > > x86: emulation: Set an MTRR for the RAM > > scripts: Expand a few options > > test/py: Add a helper to send characters > > test/py: Allow tests to be filtered by role > > RFC: test/py: Deal with timeouts > > test: Add a test for booting Ubuntu 24.04 > > > > .gitlab-ci.yml | 5 +++ > > arch/x86/cpu/cpu.c | 24 +++++++++++++++ > > arch/x86/cpu/i386/call64.S | 35 +++++++++------------ > > arch/x86/cpu/i386/cpu.c | 41 +++++++++--------------- > > arch/x86/cpu/mtrr.c | 12 +++++--- > > arch/x86/cpu/qemu/dram.c | 15 +++++++++ > > arch/x86/cpu/qemu/qemu.c | 20 ++++++++---- > > arch/x86/cpu/start.S | 4 ++- > > arch/x86/cpu/start16.S | 3 +- > > arch/x86/cpu/x86_64/cpu.c | 5 --- > > arch/x86/include/asm/cpu.h | 35 ++++++++++++++++++--- > > arch/x86/include/asm/interrupt.h | 1 + > > arch/x86/include/asm/processor.h | 5 ++- > > arch/x86/lib/Makefile | 2 ++ > > arch/x86/lib/bios.c | 27 +++++++++------- > > arch/x86/lib/bios_interrupts.c | 8 ++--- > > arch/x86/lib/i8259.c | 2 ++ > > arch/x86/lib/spl.c | 4 +-- > > configs/qemu-x86_64_defconfig | 10 +++--- > > configs/qemu-x86_defconfig | 6 ++-- > > include/linux/log2.h | 6 ++++ > > scripts/build-qemu.sh | 4 +-- > > test/py/conftest.py | 22 +++++++++++++ > > test/py/console_base.py | 33 ++++++++++++-------- > > test/py/pytest.ini | 1 + > > test/py/tests/test_distro.py | 53 ++++++++++++++++++++++++++++++++ > > test/py/tests/test_sleep.py | 1 + > > 27 files changed, 273 insertions(+), 111 deletions(-) > > create mode 100644 test/py/tests/test_distro.py > > > [1] https://ci.u-boot.org/u-boot/u-boot/-/commits/qemu?ref_type=heads
On Mon, Feb 17, 2025 at 06:14:12AM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 16 Feb 2025 at 14:57, Tom Rini <trini@konsulko.com> wrote: > > > > On Sun, Feb 16, 2025 at 01:43:45PM -0700, Simon Glass wrote: > > > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > > > is not perfect. > > > > > > With both builds, executing the VESA ROM causes an intermittent hang, at > > > least on some AMD CPUs. > > > > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > > > is done in a way that works on real hardware but not with QEMU. This > > > means that performance is 4-5x slower than it could be, at least on my > > > CPU. > > > > > > We can work around the first problem by using Bochs, which is anyway a > > > better choice than VESA for QEMU. The second can be addressed by using > > > the same descriptor across the jump to long mode. > > > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > > > This seems needlessly not against mainline. > > I just tried it and yes there is a very small delta. I can resend it > rebased to -next if you like. I'd really like to get some OS-booting > tests into CI. Sure, and please start pushing scripts to u-boot-extras. Having these scripts in u-boot itself explicitly makes it harder to use them for debug as you now rely on them being within the tree with the changes you want on whatever older commit you want. And since you want to move these to Python too you that also means language updates need to be in there as well. Thanks.