1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Alright, let me try to figure out how to classify this bug report. The user provided a list of categories, and I need to pick the correct one based on the description.
The bug is about ARM GICv3 not supporting irq numbers greater than 992. From what I understand, GIC stands for Generic Interrupt Controller, which manages interrupts in ARM systems. The problem arises when trying to set `num-irq` beyond a certain point because QEMU enforces a limit of 1020 and requires that the number be a multiple of 32.
The user mentioned that according to the specification, irq numbers below 1020 should be available. But QEMU's check is causing issues when trying to use more than 992. So this seems related to how QEMU initializes and configures the GICv3.
Looking at the categories provided: hypervisor, kernel, peripherals, etc. Since GIC is a hardware component in the system that handles interrupts, which are part of the device or peripheral management. But considering that this involves the hypervisor's handling of devices and their interrupt configurations, 'hypervisor' might be the right category.
Wait, but sometimes such issues fall under how QEMU handles device models. However, GIC is more about the interrupt controller itself, which could be considered a hardware peripheral. So 'peripherals' might also fit. But since it's related to the hypervisor's initialization and checks on irq numbers, perhaps 'hypervisor' is more appropriate.
Alternatively, if this is about how QEMU configures devices (like GIC) in the virtual machine setup, it could be under 'device'. Hmm. The problem is that when initializing GICv3, there's a check in QEMU code that limits num_irq to 1020 and requires it to be a multiple of 32. So this seems like an issue within how QEMU (the hypervisor) manages the device configuration.
I'm leaning towards 'hypervisor' because it's about the virtualization layer enforcing constraints on hardware resources, specifically irq numbers for the GICv3. Alternatively, 'device' could also make sense if the focus is on the GICv3 device itself, but since the issue is with QEMU's handling during initialization, I think 'hypervisor' is more accurate.
</think>
hypervisor
|