On 9/27/2025 1:48 AM, Peter Maydell wrote:
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 34e74f24470..d191d7177f1 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -2704,6 +2704,7 @@ static MemoryRegion smram_as_mem;static void register_smram_listener(Notifier *n, void *unused) { + CPUState *cpu; MemoryRegion *smram = (MemoryRegion *) object_resolve_path("/machine/smram", NULL); @@ -2728,6 +2729,10 @@ static void register_smram_listener(Notifier *n, void *unused) address_space_init(&smram_address_space, &smram_as_root, "KVM-SMRAM"); kvm_memory_listener_register(kvm_state, &smram_listener, &smram_address_space, 1, "kvm-smram"); + + CPU_FOREACH(cpu) { + cpu_address_space_init(cpu, 1, "cpu-smm", &smram_as_root); + } }However, this code is in a machine_init_done notifier, so it runs only once when QEMU starts up. So the CPUs initially present on QEMU startup get their AS 1 initialized, but any CPU hot-plugged later on while QEMU is running will not ever call cpu_address_space_init() for AS 1. I saw this with some work-in-progress patches I have that try to free the AddressSpaces of the CPU (which crash because the hot-plugged CPU claims to have 2 ASes but the second one is NULL). You can probably also get a crash for a variation of the reported crash that this commit is trying to fix, if the CPU that we try to x86_cpu_dump_state() for is a hot-plugged one in SMM state. Where should we be initing the AS for hot-plugged CPUs?
I think we can do it inside x86_cpu_plug(). Let me try to cook a patch for it.
