On 2025/5/19 下午4:49, Jiaxun Yang wrote:
在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.
So what is the advantage and disadvantage from yourself understanding here?
Regards
Bibo Mao
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
