Hi, Xiaoyao!
Hi, Zhao!
Thank you for your feedback.
You wrote:
> QEMU allocates separate KVM address space for SMM in
> register_smram_listener(). But the address space doesn't associated with
> cpu's address space.
The address space allocated in register_sm_ram_listener() is stored in
KVMState::KVMAs::as
However, function cpu_asidx_from_attrs() returns index which is used to
reference CPUState::cpu_ases
These are different array used to store address spaces. In softmmu setup there
is a function called for cpu initialisation qemu_init_vcpu() which has
hardcoded number of address spaces used to 1
if (!cpu->as) {
/* If the target cpu hasn't set up any address spaces itself,
* give it the default one.
*/
cpu->num_ases = 1;
cpu_address_space_init(cpu, 0, "cpu-memory", cpu->memory);
}
Do I understand your concern correctly?
The number of address spaces from KVM is allocated correctly (2 address spaces)
however in QEMU CPUState is allocated only 1, so the correct fix would be to
associate/map KVM allocated address spaces with
QEMU CPUState address spaces ?
> On 2 Jul 2025, at 19:24, Xiaoyao Li <xiaoyao...@intel.com> wrote:
>
> On 7/2/2025 11:10 PM, Xiaoyao Li wrote:
>> On 7/2/2025 10:16 PM, Xiaoyao Li wrote:
>>> On 5/23/2025 11:44 PM, Kirill Martynov wrote:
>>>> Certain error conditions can trigger x86_cpu_dump_state() to output CPU
>>>> state
>>>> debug information e.g. KVM emulation failure due to misbehaving guest.
>>>> However, if the CPU is in System Management Mode (SMM) when the assertion
>>>> in cpu_asidx_from_attrs failure happens because:
>>>>
>>>> 1. In SMM mode (smm=1), the CPU must use multiple address spaces
>>>> with a dedicated SMM address space
>>>> 2. On machine types with softmmu, address spaces are hardcoded to 1
>>>> (no multiple address spaces available)
>>>>
>>>> The assertion occurs in cpu_asidx_from_attrs() when trying to
>>>> access memory in SMM mode with insufficient address spaces.
>>>>
>>>> Fix this by:
>>>> 1. If number of address spaces is 1 always use index 0
>>>> 2. In other cases use attr.secure for identified proper index
>>>>
>>>> This prevents the assertion while still providing useful debug
>>>> output during VM shutdown errors.
>>>
>>> To me, it's just a workaround to avoid the assertion.
>>>
>>> When attrs.secure is 1, it means it's in SMM mode. As you describe above,
>>>
>>> > 1. In SMM mode (smm=1), the CPU must use multiple address spaces
>>> > with a dedicated SMM address space
>>>
>>> So I think we need to first figure out why it gets attrs.secure as 1 when
>>> there is only 1 address space.
>> Ah, with KVM, QEMU can only support 1 address space.
>
> In fact, KVM does support different address space for supporting SMM mode.
> There is KVM_CAP_MULTI_ADDRESS_SPACE to report how many address space is
> supported by KVM.
>
> (It turns out my memory on KVM is correct. I was misled by QEMU code and
> comment)
>
> QEMU allocates separate KVM address space for SMM in
> register_smram_listener(). But the address space doesn't associated with
> cpu's address space.
>
> I think this patch can only avoid the assertion in you case when vcpu is in
> SMM mode with KVM. But with this patch, do you get the correct info of SMM
> mode dumped? I guess no, since the info is of address space 0, not the SMM
> address space.
>
> If there is no reason of cannot associate KVM's address space with cpu's
> address space, I think the right fix is to enable the association with them.
>
>
>> Reviewed-by: Xiaoyao Li <xiaoyao...@intel.com <mailto:xiaoyao...@intel.com>>
>
> Based on above, I need to withdraw my Reviewed-by.
>
>
>>>> }
>>>> static inline AddressSpace *cpu_addressspace(CPUState *cs, MemTxAttrs
>>>> attrs)
