qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Bibo Mao" <maobibo@loongson.cn>, "QEMU devel" <qemu-devel@nongnu.org>
Cc: "Huacai Chen" <chenhuacai@kernel.org>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Song Gao" <gaosong@loongson.cn>
Subject: Re: [PATCH v3 1/4] hw/intc: Remove loongarch_ipi.c
Date: Wed, 26 Jun 2024 08:40:22 +0100	[thread overview]
Message-ID: <a08de6f3-3e7d-4ea4-8595-c047b4880a58@app.fastmail.com> (raw)
In-Reply-To: <e1b8bbd8-2a9d-2417-1123-4aabfdedb684@loongson.cn>



在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?

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


  reply	other threads:[~2024-06-26  7:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-05  2:15 [PATCH v3 0/4] hw/mips/loongson3_virt: Implement IPI support Jiaxun Yang
2024-06-05  2:15 ` [PATCH v3 1/4] hw/intc: Remove loongarch_ipi.c Jiaxun Yang
2024-06-05  3:32   ` gaosong
2024-06-18 11:09   ` Philippe Mathieu-Daudé
2024-06-26  4:11   ` maobibo
2024-06-26  7:40     ` Jiaxun Yang [this message]
2024-06-26  7:51       ` maobibo
2024-06-26 10:03         ` Jiaxun Yang
2024-06-26 12:10     ` Philippe Mathieu-Daudé
2024-06-27  2:44       ` gaosong
2024-06-27 13:02         ` Philippe Mathieu-Daudé
2024-07-01  1:35           ` maobibo
2024-07-01  6:44             ` maobibo
2024-07-01  7:01               ` Jiaxun Yang
2024-07-01  7:22                 ` maobibo
2024-07-01  8:29                   ` Jiaxun Yang
2024-07-01  8:51                     ` maobibo
2024-07-01  7:08             ` Jiaxun Yang
2024-07-01  7:24               ` maobibo
2024-06-05  2:15 ` [PATCH v3 2/4] hw/intc/loongson_ipi: Provide per core MMIO address spaces Jiaxun Yang
2024-06-05  2:15 ` [PATCH v3 3/4] hw/mips/loongson3_virt: Wire up loongson_ipi device Jiaxun Yang
2024-06-18 11:17   ` Philippe Mathieu-Daudé
2024-06-18 11:24     ` Philippe Mathieu-Daudé
2024-06-05  2:15 ` [PATCH v3 4/4] hw/intc/loongson_ipi: Replace ipi_getcpu with cpu_by_arch_id Jiaxun Yang
2024-06-05  3:33   ` gaosong
2024-06-12 12:09 ` [PATCH v3 0/4] hw/mips/loongson3_virt: Implement IPI support Jiaxun Yang
2024-06-18 11:49   ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a08de6f3-3e7d-4ea4-8595-c047b4880a58@app.fastmail.com \
    --to=jiaxun.yang@flygoat.com \
    --cc=chenhuacai@kernel.org \
    --cc=gaosong@loongson.cn \
    --cc=maobibo@loongson.cn \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).