1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, I'm trying to classify this bug report from QEMU. Let's see what it says.
The user mentioned that the host PCI bridge has disappeared on a big-endian MIPS Malta machine. The test `tests/avocado/linux_ssh_mips_malta.py` is failing because when they run `lspci -d 11ab:4620`, it doesn't show the expected output. So, the guest kernel isn't detecting the host bridge correctly anymore.
Looking at the steps to reproduce, it involves getting a kernel and disk image from a specific URL and then booting the guest. The key part is that this started failing after a particular commit: 145e2198d749ec09a405f1607a9932499b76f1eb.
The user also noted that some code was removed in the new version which included a check `phb->config_reg & 0x00fff800`. Without this, the space for the host bridge might not be swapped correctly. They suggest reverting two commits to fix the problem on little-endian hosts.
Now, I need to categorize this bug. The possible categories are: mistranslation, assembly, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor, and other.
The issue is related to the host PCI bridge not being detected by the guest's lspci command. This suggests a problem with how devices are exposed or handled in the virtual machine. The mention of the guest kernel not discovering the host bridge points towards device management within QEMU.
Looking at the categories, 'device' seems appropriate because it pertains to hardware devices (like PCI bridges) not functioning correctly in the VM. Other options like 'kernel' could be a possibility since it's about how the guest OS interacts with the hardware, but 'device' is more specific here.
So, I think the correct category for this bug report is 'device'.
</think>
The issue relates to the detection of the host PCI bridge by the guest kernel, which falls under device management in QEMU.
**Answer:** device
|