Re: [PATCH] x86/cpu: Handle SMM mode in x86_cpu_dump_state for softmmu

[Zhao Liu <zhao1.liu@intel.com>]

Hi Kirill,

On Mon, Jul 28, 2025 at 05:44:25PM +0300, Kirill Martynov wrote:
> Date: Mon, 28 Jul 2025 17:44:25 +0300
> From: Kirill Martynov <stdcalllevi@yandex-team.ru>
> Subject: Re: [PATCH] x86/cpu: Handle SMM mode in x86_cpu_dump_state for
>  softmmu
> X-Mailer: Apple Mail (2.3826.600.51.1.1)
> 
> Hi Xiaoyao!
> Hi Zhao!
> 
> Xiaoyao,
> I tested the patch you provided, it works smoothly, easy to apply. Nothing to complain about.
> 
> Zhao, 
> I also tried your approach (extend cpu_address_space_init with AddressSpace parameter)
> First, it crashed in malloc with error:
> malloc(): unaligned tcache chunk detected
> After a little investigation I resized cpu->cpu_ases array, so it can fit second element and
> it started working. However, it looks like that function cpu_address_space_destroy needs
> some adjustment, because now it treats cpu->cpu_ases elements as dynamically allocated and
> destroys them with g_free() and passing &smram_address_space to cpu_address_space_init()
> in register_smram_listener() could lead to a problem since it is statically allocated in binary.

Thanks for testing. Yes, resize related details are needed, which were
I missed. These 2 patches essentially are all about adding SMM CPU
address space for KVM, like TCG did.

> So, my question now, what should I do?

I still believe we should update cpu_address_space_init() and remove its
outdated assumptions about KVM first.

Moreover, users should have control over the added address spaces (I
think this is why num_ases should be set before
cpu_address_space_init()), and quietly updating num_ases is not a good
idea.

The question of whether to reuse smram_address_space for the CPU is
flexible. At least TCG doesn't reuse the same SMM space, and there's
already cpu_as_root (and cpu_as_mem!) in X86CPU. There are also some
cleanup things worth considering, such as how to better handle the TCG
memory listener in cpu_address_space_init() - KVM also has the similar
logic. If possible, I can help you further refine this fix and clean up
other related stuff in one goes as well.

Thanks,
Zhao