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.
Regards
Bibo Mao
That means there will be two virt machine types since device name is
different in different accel mode.
Yes I do think you shouldn't aim migration capability between different
accel mode. It's not doable given we can't emulate full set of h/w behaviour.
In this way you can avoid ugly "irqchip-in-kernel" property.
Also you don't really want all those emulation functions in
loongarch_extioi.c to kick in when irqchip is in kernel. If
IOCSR VMEXIT happens on extioi range, it's a hypervisor error
rather than something needs to be emulated.
Also I think EXTIOI_VIRT_CONFIG range MMIO needs to be handled
differently on KVM vs userspace irqchip. EXTIOI_VIRT_CONFIG needs
to be relayed to kernel, as virt_iocsr_misc_write will perform
IOCSR read/write in userspace, this needs to be translated to
KVM_DEV_LOONGARCH_EXTIOI_SW_STATUS_STATE.
Will handle it, misc iocsr should be emulated in kernel also.
IMHO misc IOCSR should be in user space because it described
the capability of machine instead of CPU, it's not a part of
irqchip.
Regards
Bibo Mao
Thanks
