在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
