Jiaxun Yang <jiaxun.y...@flygoat.com> 于2025年5月19日周一 17:17写道： > > > > 在2025年5月19日周一 上午9:55，Bibo Mao写道： > [...] > >> It's actually different machine as kernel irqchip is never on par with > >> usermode > >> emulation. This approach is taken by i386 (TYPE_KVM_IOAPIC vs TYPE_IOAPIC), > >> Arm (TYPE_KVM_ARM_ITS vs TYPE_ARM_GICV3_ITS), PowerPC (TYPE_KVM_OPENPIC vs > >> TYPE_OPENPIC) and I see no reason that LoongArch should not follow. > > So what is the advantage and disadvantage from yourself understanding here? > > I think I made myself pretty clear in previous replies, in case you missed > that. > > The advantage is clean design, clean interface, clean vmstates (user space > emulation > tends to have more states vs in-kernel irqchip), proper signalling to user > that > migration between user-space/in-kernel irqchip is not feasible, perhaps some > performance > advantage on reducing number of user space IOCSR ranges, reducing attack > surface > exposed by userspace emulation, reducing the chance of hypervisor error being > covered > up by userspace fallback.... > > I don't think there is any disadvantage. I don't really buy the "different > machine" > justification you made. Paravirt solution tends to have its own behaviour and > I don't > think it's a bad thing to expose it to users. irqchip-in-kernel is some kind of optimization, register layout and function is the same whatever it is emulated in kernel or user mode.
The same for cpu type, do you think that cpu type la464 should be named as la464-kvm in KVM mode? Or you do not care about name at all？ Regards Bibo Mao > > Thanks > -- > - Jiaxun >
