blob: 1d45dbc32fbd0ca4653ce19132dbb43668e07538 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, I'm trying to help classify this bug report for QEMU. The user mentioned a test failure in `test-crypto-secret.c` specifically at line 144 where the assertion `(key >= 0)` failed. They're running Arch Linux in an nspawn container.
First, I know that QEMU has two main modes: user-mode and system-mode. User-mode emulates a CPU and runs applications without full OS isolation, while system-mode is for virtualizing entire operating systems with device emulation.
The error seems related to the crypto secret tests. The `test-crypto-secret.c` file likely deals with cryptographic operations within QEMU. Since the test involves keyring functionality, this suggests it's part of QEMU's internal mechanisms for managing secrets or encryption keys.
Looking at how QEMU is built, if the user disabled the keyring before (with `--disable-keyring`), that might have worked around the issue previously. However, they mention it no longer works due to a specific commit, which probably changed how the keyring is handled.
The fact that this test is failing in both 5.1.0 and trunk suggests it's an ongoing issue with the crypto secret handling code. Since the error occurs during testing of internal cryptographic functions, it doesn't seem related to device emulation or peripherals, which are more system-mode concerns.
So, considering all this, the bug seems to be within QEMU's user-mode components, specifically in its cryptography and secret management modules rather than anything related to full OS virtualization or hardware devices.
</think>
user
|