[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V8 3/8] hw/acpi: Update ACPI GED framework to support vCPU Ho
From: |
Zhao Liu |
Subject: |
Re: [PATCH V8 3/8] hw/acpi: Update ACPI GED framework to support vCPU Hotplug |
Date: |
Wed, 13 Mar 2024 14:14:02 +0800 |
Hi Salil,
It seems my comment [1] in v7 was missed, but I still hit the same
issue. Pls let me paste the previous comment here again.
[1]: https://lore.kernel.org/qemu-devel/ZXCqp32ggIFvUweu@intel.com/
[snip]
> @@ -400,6 +411,12 @@ static void acpi_ged_initfn(Object *obj)
> memory_region_init_io(&ged_st->regs, obj, &ged_regs_ops, ged_st,
> TYPE_ACPI_GED "-regs", ACPI_GED_REG_COUNT);
> sysbus_init_mmio(sbd, &ged_st->regs);
> +
> + memory_region_init(&s->container_cpuhp, OBJECT(dev), "cpuhp container",
> + ACPI_CPU_HOTPLUG_REG_LEN);
> + sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->container_cpuhp);
> + cpu_hotplug_hw_init(&s->container_cpuhp, OBJECT(dev),
> + &s->cpuhp_state, 0);
> }
>
I find this cpu_hotplug_hw_init() can still cause qtest errors (for v8)
on x86 platforms as you mentioned in v6:
https://lore.kernel.org/qemu-devel/15e70616-6abb-63a4-17d0-820f4a254607@opnsrc.net/T/#m108f102b2fe92b7dd7218f2f942f7b233a9d6af3
IIUC, microvm machine has its own 'possible_cpus_arch_ids' and that is
inherited from its parent x86 machine.
The above error is because device-introspect-test sets the none-machine:
# starting QEMU: exec ./qemu-system-i386 -qtest unix:/tmp/qtest-3094820.sock
-qtest-log /dev/null -chardev socket,path=/tmp/qtest-3094820.qmp,id=char0 -mon
chardev=char0,mode=control -display none -audio none -nodefaults -machine none
-accel qtest
So what about just checking mc->possible_cpu_arch_ids instead of an
assert in cpu_hotplug_hw_init()?
diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index 4b24a2500361..303f1f1f57bc 100644
--- a/hw/acpi/cpu.c
+++ b/hw/acpi/cpu.c
@@ -221,7 +221,10 @@ void cpu_hotplug_hw_init(MemoryRegion *as, Object *owner,
const CPUArchIdList *id_list;
int i;
- assert(mc->possible_cpu_arch_ids);
+ if (!mc->possible_cpu_arch_ids) {
+ return;
+ }
+
id_list = mc->possible_cpu_arch_ids(machine);
state->dev_count = id_list->len;
state->devs = g_new0(typeof(*state->devs), state->dev_count);
This check seems to be acceptable in the general code path? Not all machines
have possible_cpu_arch_ids, after all.
Thanks,
Zhao
- [PATCH V8 0/8] Add architecture agnostic code to support vCPU Hotplug, Salil Mehta, 2024/03/11
- [PATCH V8 1/8] accel/kvm: Extract common KVM vCPU {creation, parking} code, Salil Mehta, 2024/03/11
- [PATCH V8 2/8] hw/acpi: Move CPU ctrl-dev MMIO region len macro to common header file, Salil Mehta, 2024/03/11
- [PATCH V8 3/8] hw/acpi: Update ACPI GED framework to support vCPU Hotplug, Salil Mehta, 2024/03/11
- Re: [PATCH V8 3/8] hw/acpi: Update ACPI GED framework to support vCPU Hotplug,
Zhao Liu <=
- [PATCH V8 4/8] hw/acpi: Update GED _EVT method AML with CPU scan, Salil Mehta, 2024/03/11
- [PATCH V8 5/8] hw/acpi: Update CPUs AML with cpu-(ctrl)dev change, Salil Mehta, 2024/03/11
- [PATCH V8 6/8] physmem: Add helper function to destroy CPU AddressSpace, Salil Mehta, 2024/03/11
- [PATCH V8 7/8] gdbstub: Add helper function to unregister GDB register space, Salil Mehta, 2024/03/11
- [PATCH V8 8/8] docs/specs/acpi_hw_reduced_hotplug: Add the CPU Hotplug Event Bit, Salil Mehta, 2024/03/11
- Re: [PATCH V8 0/8] Add architecture agnostic code to support vCPU Hotplug, Michael S. Tsirkin, 2024/03/12