在2025年5月19日周一 上午8:09，Bibo Mao写道：
> On 2025/5/19 下午2:50, Jiaxun Yang wrote:
>>
>>
>> 在2025年5月19日周一 上午3:56，Bibo Mao写道：
>> [...]
>>>>
>>>> Hi Bibo,
>>>>
>>>> I believe hijacking loongarch_extioi.c is not the proper way to do it.
>>>> The sensible solution is to create a TYPE_LOONGARCH_EXTIOI_KVM, which
>>>> inherits TYPE_LOONGARCH_EXTIOI_COMMON, and let machine create
>>>> TYPE_LOONGARCH_EXTIOI_KVM vs TYPE_LOONGARCH_EXTIOI as necessary.
>>> what is advantage about creating TYPE_LOONGARCH_EXTIOI_KVM device in KVM
>>> node and TYPE_LOONGARCH_EXTIOI device in TCG mode?
>>
>> Cleaner, less error-prone, isolate unnecessary emulation functions to
>> reduce attack surface...
> yes, there is a beautiful code logic internal, however from user the
> device tree will be different because of irqchip-in-kernel feature, such
> as different output of *info qom-tree*. It will bring out illusions of
> different virt machine type for users.
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.
I'm actually planning to bring user space EXTIOI emulation closer to actual
hardware behaviour and I wound not expect such change to be accepted by
in-kernel irqchip.
Thanks
>
> Regards
> Bibo Mao
>>
--
- Jiaxun
