[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] x86/amd: Avoid cpu_has_hypervisor evaluating true on native hardware

On 11.02.2020 18:16, Andrew Cooper wrote:
> On 11/02/2020 16:59, Jan Beulich wrote:
>> On 11.02.2020 17:31, Roger Pau Monné wrote:
>>> On Tue, Feb 11, 2020 at 03:51:54PM +0000, Andrew Cooper wrote:
>>>> Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
>>>> configured with the HYPERVISOR bit before native CPUID is scanned for 
>>>> feature
>>>> bits.
>>>> This results in cpu_has_hypervisor becoming set as part of identify_cpu(), 
>>>> and
>>>> ends up appearing in the raw and host CPU policies.
>>>> A combination of this bug, and c/s bb502a8ca59 "x86: check feature flags 
>>>> after
>>>> resume" which checks that feature bits don't go missing, results in broken 
>>>> S3
>>>> on AMD hardware.
>>>> Alter amd_init_levelling() to exclude the HYPERVISOR bit from
>>>> cpumask_defaults, and update domain_cpu_policy_changed() to allow it to be
>>>> explicitly forwarded.
>>>> This also fixes a bug on kexec, where the hypervisor bit is left enabled 
>>>> for
>>>> the new kernel to find.
>>>> These changes highlight a further but - dom0 construction is asymetric with
>>>> domU construction, by not having any calls to domain_cpu_policy_changed().
>>>> Extend arch_domain_create() to always call domain_cpu_policy_changed().
>>>> Reported-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> ---
>>>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>>>> CC: Wei Liu <wl@xxxxxxx>
>>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>> CC: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
>>>> CC: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>>>> CC: Claudia <claudia1@xxxxxxxxxxx>
>>>> v2:
>>>>  * Rewrite the commit message.  No change to the patch content.
>>>> Marek/Claudia: Do either of you want a Reported-by tag seeing as you found 
>>>> a
>>>> brand new way that this was broken?
>> I understand this is addressing only one half of their issue. Since
>> you said you don't find it surprising, do you have any idea why the
>> OSXSAVE bit is behaving differently on AMD and on Intel?
> It isn't behaving differently between Intel and AMD, I don't think.
> The diagnostics are asymmetric - they ever printed when a feature
> disappears, not for a feature appearing.

Oh, I see - this is the part I was missing.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.