arch/loongarch/include/asm/kvm_eiointc.h
Source file repositories/reference/linux-study-clean/arch/loongarch/include/asm/kvm_eiointc.h
File Facts
- System
- Linux kernel
- Corpus path
arch/loongarch/include/asm/kvm_eiointc.h- Extension
.h- Size
- 2451 bytes
- Lines
- 85
- Domain
- Architecture Layer
- Bucket
- arch/loongarch
- Inferred role
- Architecture Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
kvm/iodev.h
Detected Declarations
struct loongarch_eiointc
Annotated Snippet
struct loongarch_eiointc {
spinlock_t lock;
struct kvm *kvm;
struct kvm_io_device device;
struct kvm_io_device device_vext;
uint32_t num_cpu;
uint32_t features;
uint32_t status;
/* hardware state */
u64 nodetype[EIOINTC_IRQS_NODETYPE_COUNT / 4];
/* one bit shows the state of one irq */
u64 bounce[EIOINTC_IRQS_U64_NUMS];
u64 isr[EIOINTC_IRQS_U64_NUMS];
u64 coreisr[EIOINTC_ROUTE_MAX_VCPUS][EIOINTC_IRQS_U64_NUMS];
u64 enable[EIOINTC_IRQS_U64_NUMS];
/* use one byte to config ipmap for 32 irqs at once */
u64 ipmap;
/* use one byte to config coremap for one irq */
u64 coremap[EIOINTC_IRQS / 8];
DECLARE_BITMAP(sw_coreisr[EIOINTC_ROUTE_MAX_VCPUS][LOONGSON_IP_NUM], EIOINTC_IRQS);
uint8_t sw_coremap[EIOINTC_IRQS];
};
int kvm_loongarch_register_eiointc_device(void);
void eiointc_set_irq(struct loongarch_eiointc *s, int irq, int level);
#endif /* __ASM_KVM_EIOINTC_H */
Annotation
- Immediate include surface: `kvm/iodev.h`.
- Detected declarations: `struct loongarch_eiointc`.
- Atlas domain: Architecture Layer / arch/loongarch.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.