[Bug 2120835] Re: EDK2 tests for riscv emulation fail against qemu 10.1 on ppc64el

[Christian Ehrhardt]

** Changed in: qemu (Ubuntu)
       Status: Invalid => In Progress

** Changed in: edk2 (Ubuntu)
     Assignee: Christian Ehrhardt (paelzer) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-15 in Ubuntu.
https://bugs.launchpad.net/bugs/2120835

Title:
  EDK2 tests for riscv emulation fail against qemu 10.1 on ppc64el

Status in edk2 package in Ubuntu:
  Invalid
Status in gcc-15 package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  In testing qemu 10.1 we've seen them start to fail on armhf and ppc64
  (only there)

  https://autopkgtest.ubuntu.com/packages/e/edk2/questing/armhf
  https://autopkgtest.ubuntu.com/packages/e/edk2/questing/ppc64el

  An example log is
  https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/ppc64el/e/edk2/20250818_045238_153f0@/log.gz

  
  With a porterbox setup the good case is reproducible like this:

       sudo apt install -y ovmf ovmf-ia32 python3-pexpect qemu-efi-aarch64 qemu-efi-arm qemu-efi-loongarch64 qemu-efi-riscv64 qemu-system-arm qemu-system-loongarch64 qemu-system-riscv64 qemu-system-x86
       apt source edk2
       cd edk2-2025.02/
       PYTHONPATH=./debian/python python3 debian/tests/shell.py
       PYTHONPATH=./debian/python python3 debian/tests/shell.py 2>&1 | tee -a ~/compare-10.0.log
       ...
       works fine


  Switching to the qemu 10.1 (and by dependency glibc) from proposed
  makes this reproducible.

  
  The error (or red herring) is

    241s ERROR:target/riscv/pmu.c:216:riscv_pmu_icount_update_priv: assertion failed: (newpriv <= PRV_S)
    241s Bail out! ERROR:target/riscv/pmu.c:216:riscv_pmu_icount_update_priv: assertion failed: (newpriv <= PRV_S)
    251s ERROR

  PMU again - really? - /me is shaking the fist!


  And inside the test that is

  251s ======================================================================
  251s ERROR: test_riscv64 (__main__.BootToShellTest.test_riscv64)
  251s ----------------------------------------------------------------------
  251s Traceback (most recent call last):
  251s   File "/tmp/autopkgtest.RPBps3/build.f20/src/debian/tests/shell.py", line 100, in run_cmd_check_shell
  251s     i = child.expect(
  251s         [
  251s     ...<3 lines>...
  251s             timeout=TEST_TIMEOUT,
  251s     )
  251s   File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 354, in expect
  251s     return self.expect_list(compiled_pattern_list,
  251s            ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  251s             timeout, searchwindowsize, async_)
  251s             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  251s   File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 383, in expect_list
  251s     return exp.expect_loop(timeout)
  251s            ~~~~~~~~~~~~~~~^^^^^^^^^
  251s   File "/usr/lib/python3/dist-packages/pexpect/expect.py", line 179, in expect_loop
  251s     return self.eof(e)
  251s            ~~~~~~~~^^^
  251s   File "/usr/lib/python3/dist-packages/pexpect/expect.py", line 122, in eof
  251s     raise exc

  AFAICS this very much comes down to

  251s args: [b'/usr/bin/qemu-system-riscv64', b'-no-user-config',
  b'-nodefaults', b'-m', b'256', b'-smp',
  b'1,sockets=1,cores=1,threads=1', b'-display', b'none', b'-serial',
  b'stdio', b'-machine', b'virt', b'-device', b'virtio-serial-device',
  b'-drive', b'file=/usr/share/qemu-efi-
  riscv64/RISCV_VIRT_CODE.fd,if=pflash,format=raw,unit=0,readonly=on',
  b'-drive',
  b'file=/tmp/tmpr31gjfit,if=pflash,format=raw,unit=1,readonly=off']

  
  From here I have two log filed for 10.0 and 10.1 which we can compare, but the diff shows no interesting Delta until the bug happens.
  I need to modify the test to keep the artifacts around and allow it to be ran directly.

  We can steal the test drive from the test (will attach) and then
  isolate the command:

  Command:
  qemu-system-riscv64 -no-user-config -nodefaults -m 256 -smp '1,sockets=1,cores=1,threads=1' -display 'none' -serial 'stdio' -machine 'virt' -device 'virtio-serial-device' -drive 'file=/usr/share/qemu-efi-riscv64/RISCV_VIRT_CODE.fd,if=pflash,format=raw,unit=0,readonly=on' -drive 'file=/tmp/testdrive,if=pflash,format=raw,unit=1,readonly=off'


  Riddles: At least in automation they only fail on armhf and ppc64
  (?!?) ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2120835/+subscriptions