|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Ping: [PATCH v4] x86: clear RDRAND CPUID bit on AMD family 15h/16h
On 09.03.2020 10:08, Jan Beulich wrote:
> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>
> There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. This issue stems from a BIOS
> not performing the proper steps during resume to ensure RDRAND continues
> to function properly.
>
> Update the CPU initialization to clear the RDRAND CPUID bit for any family
> 15h and 16h processor that supports RDRAND. If it is known that the family
> 15h or family 16h system does not have an RDRAND resume issue or that the
> system will not be placed in suspend, the "cpuid=rdrand" kernel parameter
> can be used to stop the clearing of the RDRAND CPUID bit.
>
> Note, that clearing the RDRAND CPUID bit does not prevent a processor
> that normally supports the RDRAND instruction from executing it. So any
> code that determined the support based on family and model won't #UD.
>
> Warn if no explicit choice was given on affected hardware.
>
> Check RDRAND functions at boot as well as after S3 resume (the retry
> limit chosen is entirely arbitrary).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Still slightly RFC, and still in particular because of the change to
> parse_xen_cpuid(): Alternative approach suggestions are welcome. But now
> also because with many CPUs there may now be a lot of warnings in case
> of issues.
Ping?
> ---
> v4: Check always, including during boot. Slightly better sanity check,
> inspired by Linux commit 7879fc4bdc7.
> v3: Add call to warning_add(). If force-enabled, check RDRAND still
> functioning after S3 resume.
> v2: Re-base.
>
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -488,6 +488,10 @@ The Speculation Control hardware feature
> be ignored, e.g. `no-ibrsb`, at which point Xen won't use them itself, and
> won't offer them to guests.
>
> +`rdrand` can be used to override the default disabling of the feature on
> certain
> +AMD systems. Its negative form can of course also be used to suppress use
> and
> +exposure of the feature.
> +
> ### cpuid_mask_cpu
> > `= fam_0f_rev_[cdefg] | fam_10_rev_[bc] | fam_11_rev_b`
>
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -4,6 +4,7 @@
> #include <xen/param.h>
> #include <xen/smp.h>
> #include <xen/pci.h>
> +#include <xen/warning.h>
> #include <asm/io.h>
> #include <asm/msr.h>
> #include <asm/processor.h>
> @@ -646,6 +647,25 @@ static void init_amd(struct cpuinfo_x86
> if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
> amd_acpi_c1e_quirk = true;
> break;
> +
> + case 0x15: case 0x16:
> + /*
> + * There are too many Fam15/Fam16 systems where upon resume
> + * from S3 firmware fails to re-setup properly functioning
> + * RDRAND. Clear the feature unless force-enabled on the
> + * command line.
> + */
> + if (c == &boot_cpu_data &&
> + cpu_has(c, X86_FEATURE_RDRAND) &&
> + !is_forced_cpu_cap(X86_FEATURE_RDRAND)) {
> + static const char __initconst text[] =
> + "RDRAND may cease to work on this hardware upon
> resume from S3.\n"
> + "Please choose an explicit cpuid={no-}rdrand
> setting.\n";
> +
> + setup_clear_cpu_cap(X86_FEATURE_RDRAND);
> + warning_add(text);
> + }
> + break;
> }
>
> display_cacheinfo(c);
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -11,6 +11,7 @@
> #include <asm/io.h>
> #include <asm/mpspec.h>
> #include <asm/apic.h>
> +#include <asm/random.h>
> #include <asm/setup.h>
> #include <mach_apic.h>
> #include <public/sysctl.h> /* for XEN_INVALID_{SOCKET,CORE}_ID */
> @@ -98,6 +99,11 @@ void __init setup_force_cpu_cap(unsigned
> __set_bit(cap, boot_cpu_data.x86_capability);
> }
>
> +bool is_forced_cpu_cap(unsigned int cap)
> +{
> + return test_bit(cap, forced_caps);
> +}
> +
> static void default_init(struct cpuinfo_x86 * c)
> {
> /* Not much we can do here... */
> @@ -498,6 +504,28 @@ void identify_cpu(struct cpuinfo_x86 *c)
> printk("\n");
> #endif
>
> + /*
> + * If RDRAND is available, make an attempt to check that it actually
> + * (still) works.
> + */
> + if (cpu_has(c, X86_FEATURE_RDRAND)) {
> + unsigned int prev = 0;
> +
> + for (i = 0; i < 5; ++i)
> + {
> + unsigned int cur = arch_get_random();
> +
> + if (prev && cur != prev)
> + break;
> + prev = cur;
> + cpu_relax();
> + }
> +
> + if (i >= 5)
> + printk(XENLOG_WARNING "CPU%u: RDRAND appears to not
> work\n",
> + smp_processor_id());
> + }
> +
> if (system_state == SYS_STATE_resume)
> return;
>
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -71,6 +71,9 @@ static int __init parse_xen_cpuid(const
> {
> if ( !val )
> setup_clear_cpu_cap(mid->bit);
> + else if ( mid->bit == X86_FEATURE_RDRAND &&
> + (cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_RDRAND)) )
> + setup_force_cpu_cap(X86_FEATURE_RDRAND);
> mid = NULL;
> }
>
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -166,6 +166,7 @@ extern const struct x86_cpu_id *x86_matc
> extern void identify_cpu(struct cpuinfo_x86 *);
> extern void setup_clear_cpu_cap(unsigned int);
> extern void setup_force_cpu_cap(unsigned int);
> +extern bool is_forced_cpu_cap(unsigned int);
> extern void print_cpu_info(unsigned int cpu);
> extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
>
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |