blob: c0e3f476d9697cfde33040fa63df4ddb0ae152a6 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Alright, I need to classify this bug report into one of the given categories for QEMU. Let me read through the details carefully.
The user is encountering an issue where their code isn't finding an ACPI table when running under QEMU. They mentioned that when they run it in Oracle VirtualBox, everything works fine. The command line shows they're using `qemu-system-i386` with two disks: one as an ISO image and another as a test file.
Looking at the code provided, they're trying to detect memory blocks of type MULTIBOOT_MEMORY_ACPI_RECLAIMABLE. However, in their loop, they print that they are inside only if the condition is met, but there's no indication whether this block was found or not. The bug report says that no such block is found.
So the problem seems to be related to QEMU not providing the expected ACPI information when running as a hypervisor. Since they're using QEMU/KVM (as indicated by the `qemu-system-i386` command), the issue could be with how the hardware is being emulated, particularly regarding the presence of the ACPI table.
In QEMU, the `-M` option specifies the machine type. The user tried `-M 1.6`, but it's not recognized. This might mean that they're using an outdated or incorrect machine type. Alternatively, maybe the way QEMU handles ACPI in this configuration is flawed.
Since the issue pertains to the absence of an ACPI table and a problem with the `-M` option (which relates to the machine setup), this likely falls under the hypervisor category because it's related to how the virtual machine's hardware is configured. The hypervisor is responsible for emulating the physical hardware, including providing necessary tables like ACPI.
Therefore, the appropriate category is "hypervisor."
</think>
hypervisor
|