在2024年6月26日六月 上午8:51，maobibo写道：
> On 2024/6/26 下午3:40, Jiaxun Yang wrote:
>>
>>
>> 在2024年6月26日六月 上午5:11，maobibo写道：
>> [...]
>>> It is different with existing implementation.
>> What do you mean? Isn't this the actual hardware behaviour?
>>
>>>
>>> With hw/intc/loongson_ipi.c, every vcpu has one ipi_mmio_mem, however on
>>> loongarch ipi machine, there is no ipi_mmio_mem memory region.
>>> So if machine has 256 vcpus, there will be 256 ipi_mmio_mem memory
>>> regions. In function sysbus_init_mmio(), memory region can not exceed
>>> QDEV_MAX_MMIO (32). With so many memory regions, it slows down memory
>>> region search speed also.
>> Ouch, never thought about that before, but I think we can control the
>> registration of sysbus_mmio with a device property or even ifdef so LoongArch
>> machine won't be affected.
>>
>> For MIPS loongson3-virt machine, our CPU number is capped, so that won't
>> be a problem.
>>
>> I'm currently travelling without access to my PC, I'll prepare a patch
>> as soon as I gain access again. Feel free to send a patch before me with
>> this approach if you desperately want to fix it.
>>
>>>
>>> void sysbus_init_mmio(SysBusDevice *dev, MemoryRegion *memory)
>>> {
>>> int n;
>>>
>>> assert(dev->num_mmio < QDEV_MAX_MMIO);
>>> n = dev->num_mmio++;
>>> dev->mmio[n].addr = -1;
>>> dev->mmio[n].memory = memory;
>>> }
>>>
>>> Can we revert this patch? We want to do production usable by real users
>>> rather than show pure technology.
>>
>> I don't really get your point, we have at leat 4 real users requesting SMP
>> support for loongson3-virt on gitlab issues, plus I need this to test
>> MIPS/Loongson64 SMP kernel.
>>
>> If there is a problem with your use case, we can fix it. Why we do want to
>> remove the functionality when there is an easy fix?
> I do not think we have the ability to abstract hw and continuous
> maintenance for two different architecture, including you and me.
After all it’s the same IP block, I fail to see any reason to implement it
separately.
I perfectly understand that piece of hardware IP and I fix broken stuff in this
driver time by time.
I understand how does it work on LoongArch systems so I make my best effort to
cover LoongArch part.
There might be some edge cases that I missed, and I’ll be thankful for reports
or assistance.
The approach of shared drivers for LoongArch/MIPS works so well in kernel
development, for QEMU I believe it’s also desirable.
I’m not asking you or Loongson to maintain any MIPS/Loongson related features,
I’ll take care of them if things go wrong.
>lp
> So I suggest that different files will be better for the present. After
> one year or later, if we have further understanding about system, it is
> ok to merge them into one file.
If there is anything not clear to you on both MIPS and LoongArch side please
let me know, I’m happy to help.
We promote code reuse in QEMU to minimize maintenance burden.
Thanks
>
> Regards
> Bibo Mao
>>
>> It’s not only the features necessary for you that made QEMU an outstanding
>> project; it’s everything coming together that completes it.
>>
>> Thanks
>> - Jiaxun
>>>
>>> Regards
>>> Bibo Mao
>>>
>>>> -
>>>> - s->cpu = g_new0(IPICore, s->num_cpu);
>>>> - if (s->cpu == NULL) {
>>>> - error_setg(errp, "Memory allocation for ExtIOICore faile");
>>>> - return;
>>>> - }
>>>> -
>>>> - for (i = 0; i < s->num_cpu; i++) {
>>>> - qdev_init_gpio_out(dev, &s->cpu[i].irq, 1);
>>>> - }
>>>> -}
>>>> -
>>>> -static const VMStateDescription vmstate_ipi_core = {
>>>> - .name = "ipi-single",
>>>> - .version_id = 2,
>>>> - .minimum_version_id = 2,
>>>> - .fields = (const VMStateField[]) {
>>>> - VMSTATE_UINT32(status, IPICore),
>>>> - VMSTATE_UINT32(en, IPICore),
>>>> - VMSTATE_UINT32(set, IPICore),
>>>> - VMSTATE_UINT32(clear, IPICore),
>>>> - VMSTATE_UINT32_ARRAY(buf, IPICore, IPI_MBX_NUM * 2),
>>>> - VMSTATE_END_OF_LIST()
>>>> - }
>>>> -};
>>>> -
>>>> -static const VMStateDescription vmstate_loongarch_ipi = {
>>>> - .name = TYPE_LOONGARCH_IPI,
>>>> - .version_id = 2,
>>>> - .minimum_version_id = 2,
>>>> - .fields = (const VMStateField[]) {
>>>> - VMSTATE_STRUCT_VARRAY_POINTER_UINT32(cpu, LoongArchIPI, num_cpu,
>>>> - vmstate_ipi_core, IPICore),
>>>> - VMSTATE_END_OF_LIST()
>>>> - }
>>>> -};
>>>> -
>>>> -static Property ipi_properties[] = {
>>>> - DEFINE_PROP_UINT32("num-cpu", LoongArchIPI, num_cpu, 1),
>>>> - DEFINE_PROP_END_OF_LIST(),
>>>> -};
>>>> -
>>>> -static void loongarch_ipi_class_init(ObjectClass *klass, void *data)
>>>> -{
>>>> - DeviceClass *dc = DEVICE_CLASS(klass);
>>>> -
>>>> - dc->realize = loongarch_ipi_realize;
>>>> - device_class_set_props(dc, ipi_properties);
>>>> - dc->vmsd = &vmstate_loongarch_ipi;
>>>> -}
>>>> -
>>>> -static void loongarch_ipi_finalize(Object *obj)
>>>> -{
>>>> - LoongArchIPI *s = LOONGARCH_IPI(obj);
>>>> -
>>>> - g_free(s->cpu);
>>>> -}
>>>> -
>>>> -static const TypeInfo loongarch_ipi_info = {
>>>> - .name = TYPE_LOONGARCH_IPI,
>>>> - .parent = TYPE_SYS_BUS_DEVICE,
>>>> - .instance_size = sizeof(LoongArchIPI),
>>>> - .class_init = loongarch_ipi_class_init,
>>>> - .instance_finalize = loongarch_ipi_finalize,
>>>> -};
>>>> -
>>>> -static void loongarch_ipi_register_types(void)
>>>> -{
>>>> - type_register_static(&loongarch_ipi_info);
>>>> -}
>>>> -
>>>> -type_init(loongarch_ipi_register_types)
>>>>
>>
--
- Jiaxun
