1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
<think>
Alright, let me try to figure out the category for this bug report. The user is having trouble booting from an emulated NVMe disk with SeaBIOS in QEMU versions 6.0.0 and 6.1.0. They mention that it worked fine in version 5.1.0, which suggests a regression introduced after that.
The problem occurs when using SeaBIOS; the NVMe entry doesn't show up in the boot menu. However, when using OVMF (which is UEFI-based), booting from NVMe works correctly across all versions tested. This indicates that the issue might be specific to how SeaBIOS interacts with the NVMe emulation in newer QEMU versions.
The user provided a bisected commit that seems to be the first bad one: 7f0f1acedf159d00684d495d7a14d52220c1d16b. Looking at the commit message, it introduces support for multiple namespaces in NVMe by adding a new 'nvme-ns' device model. The commit changes how NVMe devices are created and connects them through a bus named from the device ID.
In the steps to reproduce, the user tried using both '-device nvme' and '-device nvme-ns', but neither worked with SeaBIOS. Since OVMF works, it's likely that the issue is in how SeaBIOS detects or handles NVMe devices after this change.
Considering the categories provided: mistranslation, assembly lowering, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
The problem is related to booting from an emulated NVMe disk and affects SeaBIOS but not OVMF. Since the issue arises after a change in how NVMe devices are modeled (introducing 'nvme-ns'), it's likely that the device setup or detection has changed, affecting the BIOS's ability to recognize the NVMe drive.
The categories I'm considering are 'device' and 'boot'. The problem is about booting, but since it's related to how the device (NVMe) is emulated and detected by SeaBIOS, which might be a firmware or device handling issue.
Alternatively, it could fall under 'peripherals' because NVMe is a type of storage peripheral. However, since the primary issue is during the boot process, 'boot' seems more directly related. But the root cause lies in how the device is emulated, so maybe 'device' is the better category.
But wait, looking back at the categories, 'device' might be too broad. The bug report mentions that it's specific to SeaBIOS and affects booting from NVMe. Since SeaBIOS is a firmware that handles device enumeration during boot, the issue could be in how QEMU presents the NVMe devices to SeaBIOS.
The commit modifies how NVMe devices are created and connected via a bus. Perhaps SeaBIOS doesn't correctly enumerate the new 'nvme-ns' devices or their buses, leading to the missing entry in the boot menu.
Therefore, this issue is related to device handling during the boot process, specifically with how QEMU's emulation of NVMe devices interacts with SeaBIOS. So the most appropriate category would be 'boot', as it directly affects the booting process from a device.
</think>
The bug report describes an issue where SeaBIOS fails to detect and boot from an emulated NVMe disk in newer versions of QEMU, specifically after a commit that introduced support for multiple namespaces via the 'nvme-ns' device. The problem is related to how the NVMe devices are modeled and connected, affecting their detection by SeaBIOS during the boot process.
Considering the categories provided, this issue primarily affects the booting mechanism when using SeaBIOS with an NVMe disk. Therefore, it falls under the 'boot' category as the root cause lies in how QEMU presents the device to the firmware (SeaBIOS) during the initial stages of the boot process.
**Answer:**
boot
|