blob: a2480b0bada766007d4e972ac61e8a973886b3a2 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to classify this bug report for QEMU. The user mentioned that their system hangs when using Kata Containers with QEMU v5.1.0-rc0 and rc1, especially on a VSI that supports nested virtualization. They didn't see the issue on bare metal, which suggests it's related to virtualization.
The problem started after a specific commit: f19bcdfedd53ee93412d535a842a89fa27cae7f2. This commit adds the 'queue_enabled' method in virtio-pci, which is part of the VirtIO implementation for PCI devices. The user found that reverting this commit fixed the hang.
Looking at the possible categories: nested virtualization issues often relate to how QEMU handles hypervisor or device-related functions. The bug report mentions it's specific to a VSI with nested virt support, so it likely involves how VirtIO devices are handled in such environments.
The category 'hypervisor' seems appropriate because the issue arises in a nested virtualization setup, which is managed by the hypervisor part of QEMU/KVM. Alternatively, 'device' or 'graphic' might be considered, but since it's about VirtIO and nested virt, 'hypervisor' fits best.
</think>
The bug report involves a hang in QEMU when using nested virtualization with Kata Containers, pointing to an issue introduced by a commit modifying the VirtIO-PCI implementation. The problem is related to hypervisor functions.
**hypervisor**
|