Re: [PATCH 03/15] hw/intc/loongarch_extioi: Add irqchip-in-kernel save/restore function

["Jiaxun Yang" <jiaxun.yang@flygoat.com>]

在2025年5月19日周一 下午2:24，bibo mao写道：
[...]
>> 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.

I can already observe some differences, for example with in-kernel irqchip
PCH MSI can be delivered to any EXTIOI vector while in user space it's only
possible to do so for 64+ vector.

I'm also planning to bring user space EXTIOI emulation closer to hardware,
as I found many issues when I was trying to bring up SylixOS BSP in QEMU,
and it's unlikely in-kernel one will follow due to performance considerations.

>
> 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？
            ^ 

I do think it for user interface it should be "host" or "max" whenever
possible in KVM mode. From QOM perspective, TCG vs KVM is handled by
TYPE_ACCEL_OPS, this makes clear distinctions at higher level.

Also, EXTIOI device is not user creatable, QOM tree information is a deep
internal detail. I searched mailing list and gitlab issues and I was unable to
find any user reports about "qom tree information confused users", given that
other architectures had taken this approach for a while.

QOM is severing QEMU's internal design, not vice versa.

Thanks
-- 
- Jiaxun