在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...
>
> 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
--
- Jiaxun
