Message ID | 20221026134715.1438789-2-anrayabh@linux.microsoft.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp279306wru; Wed, 26 Oct 2022 06:52:25 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4wAnLV/SogTbYcYwo4r4yxU56DoxGTsTAkSNKK4eFGynce0NUcvtv6rwH4173RhrGwS78I X-Received: by 2002:a17:902:dac4:b0:186:c372:732a with SMTP id q4-20020a170902dac400b00186c372732amr8399888plx.174.1666792344877; Wed, 26 Oct 2022 06:52:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666792344; cv=none; d=google.com; s=arc-20160816; b=f2I5/ya27HAC+WZdZlbh2d+lyuPGOa2WfsuOZG52ZKyW38T/ZI/bmu7ccWMWU5YD5a UWrRG4fhLIJq9NmJna3UY2x/NYeT4VW1ZVvJQvJYb2cMvtjgAelRJFDr39OhDAcygcH2 G+Fme4IUh2f2g/plUh420RgFoPGJ03ro6lJyWWYcULa/2pTbb15qq9MXGz9r3tMqC1ER UgQoG5GYno9OY5RVqer7M4nvzFfFTR++EEVisIGHDQt3g/0+SKmsU9UFwP4GHSm83Mwp RIOgEpSieRbgQO8DLByrmpFAvZ3983gQ4Tbe6lJGOBAj+An7J8lo9XVgJRuzsEHuZAUC UFqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-filter; bh=jLGstakCq9S33uzmp4509MKhTHZdg717E6kd8XaghHM=; b=T9S7kHTuAlKW7KLQrptZ4/LywSrTyabjUpWj8oxvm9ctRnCzvv3XVHO40MR8vV8+XC wLenYLWDNe9MVBGgxjE0sMyKCPnJrUMJ9XXJWbHJFHQWodOV9DZwna8LDDzcWQueidxa ANXkT+XqVJcZwwQsdyNiSKtLx8ebfAZeDDgv9qpa7fvj7nOb01zpEs1v/db1/Rhn0obp o4K2A0NhcMfmEBkAUez4BEum/1UlCvk91+cDLhjOjukUNFKNbV8veAl8y/Oxm9pH1AP/ mjzi3KOU2mwcNfvpc4U7KriMIiRJnEsuW9HRsSCxRql6X5j/8MdyOQol0uWPY4mT46Qb uBsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=V28NrchL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w4-20020a656944000000b0043cad841eb1si6792848pgq.827.2022.10.26.06.51.58; Wed, 26 Oct 2022 06:52:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=V28NrchL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233868AbiJZNsw (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Wed, 26 Oct 2022 09:48:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233784AbiJZNsJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Oct 2022 09:48:09 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 002C08BBB2; Wed, 26 Oct 2022 06:48:08 -0700 (PDT) Received: from anrayabh-desk.corp.microsoft.com (unknown [167.220.238.193]) by linux.microsoft.com (Postfix) with ESMTPSA id 33CBC2109450; Wed, 26 Oct 2022 06:48:03 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 33CBC2109450 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1666792088; bh=jLGstakCq9S33uzmp4509MKhTHZdg717E6kd8XaghHM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V28NrchLL0/cxXjeEmrw1fkhrdeYTX4oxTaG2cE374/NzbC24nlsfT3KaJOYQM8nv B6b68znl+SiM2xtyzozf+XG/8as8x2ye9Ufip1Ad2VW9q143QRSW5a+svIi/0IQPkQ /1i0PumPEX2nzhhPewBK52PKrQmb2eF+TB1Byl24= From: Anirudh Rayabharam <anrayabh@linux.microsoft.com> To: kys@microsoft.com, haiyangz@microsoft.com, sthemmin@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, daniel.lezcano@linaro.org, Arnd Bergmann <arnd@arndb.de>, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Cc: Anirudh Rayabharam <anrayabh@linux.microsoft.com>, kumarpraveen@linux.microsoft.com, mail@anirudhrb.com Subject: [PATCH 1/2] x86/hyperv: fix invalid writes to MSRs during root partition kexec Date: Wed, 26 Oct 2022 19:17:14 +0530 Message-Id: <20221026134715.1438789-2-anrayabh@linux.microsoft.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221026134715.1438789-1-anrayabh@linux.microsoft.com> References: <20221026134715.1438789-1-anrayabh@linux.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747758449791994877?= X-GMAIL-MSGID: =?utf-8?q?1747758449791994877?= |
Series |
Fix MSR access errors during kexec in root partition
|
|
Commit Message
Anirudh Rayabharam
Oct. 26, 2022, 1:47 p.m. UTC
hv_cleanup resets the hypercall page by setting the MSR to 0. However,
the root partition is not allowed to write to the GPA bits of the MSR.
Instead, it uses the hypercall page provided by the MSR. Similar is the
case with the reference TSC MSR.
Clear only the enable bit instead of zeroing the entire MSR to make
the code valid for root partition too.
Signed-off-by: Anirudh Rayabharam <anrayabh@linux.microsoft.com>
---
arch/x86/hyperv/hv_init.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Comments
From: Anirudh Rayabharam <anrayabh@linux.microsoft.com> Sent: Wednesday, October 26, 2022 6:47 AM > > hv_cleanup resets the hypercall page by setting the MSR to 0. However, > the root partition is not allowed to write to the GPA bits of the MSR. > Instead, it uses the hypercall page provided by the MSR. Similar is the > case with the reference TSC MSR. > > Clear only the enable bit instead of zeroing the entire MSR to make > the code valid for root partition too. When the enable bit is cleared (but not the PFN) in the MSR, do we know for sure that Hyper-V removes the overlay page for the PFN? Making sure that the overlay page is removed is the main reason for clearing the entire MSR. If we're going to leave the PFN in place and just clear the enable bit, we need to confirm with the Hyper-V guys that the overlay page will be removed. Michael > > Signed-off-by: Anirudh Rayabharam <anrayabh@linux.microsoft.com> > --- > arch/x86/hyperv/hv_init.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > index 29774126e931..76ff63d69461 100644 > --- a/arch/x86/hyperv/hv_init.c > +++ b/arch/x86/hyperv/hv_init.c > @@ -537,6 +537,7 @@ void __init hyperv_init(void) > void hyperv_cleanup(void) > { > union hv_x64_msr_hypercall_contents hypercall_msr; > + u64 tsc_msr; > > unregister_syscore_ops(&hv_syscore_ops); > > @@ -552,12 +553,14 @@ void hyperv_cleanup(void) > hv_hypercall_pg = NULL; > > /* Reset the hypercall page */ > - hypercall_msr.as_uint64 = 0; > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.enable = 0; > wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > /* Reset the TSC page */ > - hypercall_msr.as_uint64 = 0; > - wrmsrl(HV_X64_MSR_REFERENCE_TSC, hypercall_msr.as_uint64); > + rdmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr); > + tsc_msr &= ~BIT_ULL(0); > + wrmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr); > } > > void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die) > -- > 2.34.1
On Wed, Oct 26, 2022 at 02:58:16PM +0000, Michael Kelley (LINUX) wrote: > From: Anirudh Rayabharam <anrayabh@linux.microsoft.com> Sent: Wednesday, October 26, 2022 6:47 AM > > > > hv_cleanup resets the hypercall page by setting the MSR to 0. However, > > the root partition is not allowed to write to the GPA bits of the MSR. > > Instead, it uses the hypercall page provided by the MSR. Similar is the > > case with the reference TSC MSR. > > > > Clear only the enable bit instead of zeroing the entire MSR to make > > the code valid for root partition too. > > When the enable bit is cleared (but not the PFN) in the MSR, do we know > for sure that Hyper-V removes the overlay page for the PFN? Making sure > that the overlay page is removed is the main reason for clearing the entire > MSR. If we're going to leave the PFN in place and just clear the enable bit, > we need to confirm with the Hyper-V guys that the overlay page will be > removed. I checked the hypervisor code. Just clearing the enable bit does cause the overlay page to be unmapped by the hypervisor. Thanks, Anirudh. > > Michael > > > > > Signed-off-by: Anirudh Rayabharam <anrayabh@linux.microsoft.com> > > --- > > arch/x86/hyperv/hv_init.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > > index 29774126e931..76ff63d69461 100644 > > --- a/arch/x86/hyperv/hv_init.c > > +++ b/arch/x86/hyperv/hv_init.c > > @@ -537,6 +537,7 @@ void __init hyperv_init(void) > > void hyperv_cleanup(void) > > { > > union hv_x64_msr_hypercall_contents hypercall_msr; > > + u64 tsc_msr; > > > > unregister_syscore_ops(&hv_syscore_ops); > > > > @@ -552,12 +553,14 @@ void hyperv_cleanup(void) > > hv_hypercall_pg = NULL; > > > > /* Reset the hypercall page */ > > - hypercall_msr.as_uint64 = 0; > > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > + hypercall_msr.enable = 0; > > wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > > > /* Reset the TSC page */ > > - hypercall_msr.as_uint64 = 0; > > - wrmsrl(HV_X64_MSR_REFERENCE_TSC, hypercall_msr.as_uint64); > > + rdmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr); > > + tsc_msr &= ~BIT_ULL(0); > > + wrmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr); > > } > > > > void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die) > > -- > > 2.34.1
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 29774126e931..76ff63d69461 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -537,6 +537,7 @@ void __init hyperv_init(void) void hyperv_cleanup(void) { union hv_x64_msr_hypercall_contents hypercall_msr; + u64 tsc_msr; unregister_syscore_ops(&hv_syscore_ops); @@ -552,12 +553,14 @@ void hyperv_cleanup(void) hv_hypercall_pg = NULL; /* Reset the hypercall page */ - hypercall_msr.as_uint64 = 0; + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + hypercall_msr.enable = 0; wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); /* Reset the TSC page */ - hypercall_msr.as_uint64 = 0; - wrmsrl(HV_X64_MSR_REFERENCE_TSC, hypercall_msr.as_uint64); + rdmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr); + tsc_msr &= ~BIT_ULL(0); + wrmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr); } void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die)