From patchwork Mon Sep 30 14:58:10 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Beulich X-Patchwork-Id: 11166839 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 74187112B for ; Mon, 30 Sep 2019 14:59:28 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 597A320679 for ; Mon, 30 Sep 2019 14:59:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 597A320679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iEx7q-0005BN-AJ; Mon, 30 Sep 2019 14:58:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iEx7o-00059q-St for xen-devel@lists.xenproject.org; Mon, 30 Sep 2019 14:58:08 +0000 X-Inumbo-ID: b5766dd2-e392-11e9-b588-bc764e2007e4 Received: from mx1.suse.de (unknown [195.135.220.15]) by localhost (Halon) with ESMTPS id b5766dd2-e392-11e9-b588-bc764e2007e4; Mon, 30 Sep 2019 14:58:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 928F3AD72; Mon, 30 Sep 2019 14:58:05 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Message-ID: <6e22b19d-e9d0-6915-d27b-6c5f711af60d@suse.com> Date: Mon, 30 Sep 2019 16:58:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Language: en-US Subject: [Xen-devel] [PATCH v2] x86: clear RDRAND CPUID bit on AMD family 15h/16h X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" 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. Signed-off-by: Jan Beulich --- Slightly RFC, in particular because of the change to parse_xen_cpuid(): Alternative approach suggestions are welcome. --- 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 @@ -648,6 +648,18 @@ 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 && + !is_forced_cpu_cap(X86_FEATURE_RDRAND)) + setup_clear_cpu_cap(X86_FEATURE_RDRAND); + break; } display_cacheinfo(c); --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -97,6 +97,11 @@ void __init setup_force_cpu_cap(unsigned __set_bit(cap, boot_cpu_data.x86_capability); } +bool __init 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... */ --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -67,6 +67,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);