[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-6.1] i386: do not call cpudef-only models functions for m
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH for-6.1] i386: do not call cpudef-only models functions for max, host, base |
Date: |
Fri, 23 Jul 2021 13:18:30 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 7/23/21 10:19 AM, Claudio Fontana wrote:
> On 7/22/21 6:13 PM, Philippe Mathieu-Daudé wrote:
>> On 7/22/21 10:38 AM, Claudio Fontana wrote:
>>
>> It seems the subject got dropped and the first line
>> used as subject... But I'm not sure you want to
>> start the description with it.
>
> hmm the subject got dropped from where? I see it in the mail subject..
>>
>>> properties set by function x86_cpu_apply_props, including
>>> kvm_default_props, tcg_default_props,
>>> and the "vendor" property for KVM and HVF,
>>>
>>
>> This newline is what confuses me.
>
> hmm maybe better:
>
> "
> Some cpu properties have to be set only for cpu models in builtin_x86_defs,
> registered with x86_register_cpu_model_type, and not for
> cpu models "base", "max", and the subclass "host".
>
> These properties are the ones set by function x86_cpu_apply_props,
> (also including kvm_default_props, tcg_default_props),
> and the "vendor" property for the KVM and HVF accelerators.
>
> After recent refactoring of cpu, which also affected these properties,
> they were instead set unconditionally for all x86 cpus.
>
>>> This has been detected as a bug with Nested on AMD with cpu "host",
>>> as svm was not turned on by default, due to the wrongful setting of
>>> kvm_default_props via x86_cpu_apply_props.
>
> .. which set svm to "off".
>
>>> Rectify the bug introduced in commit "i386: split cpu accelerators"
>>> and document the functions that are builtin_x86_defs-only.
>>>
>>> Signed-off-by: Claudio Fontana <cfontana@suse.de>
>>> Tested-by: Alexander Bulekov <alxndr@bu.edu>
>>> Fixes: f5cc5a5c ("i386: split cpu accelerators from cpu.c,"...)
>>> Buglink: https://gitlab.com/qemu-project/qemu/-/issues/477
>>
>> If you want to have gitlab closes the issue once merged, you'd
>> need to use Resolves:/Fixes: tag instead, see
>> https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern
>
> I'll try Resolves: to avoid collision with Fixes: used to mark the commit
> that introduced the regression.
>
> Wdyt about the new text?
Clearer, thanks!