[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3170164-8b89-621e-59f8-999e4149e0a4@intel.com>
Date: Thu, 20 Aug 2020 13:07:36 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Tom Lendacky <thomas.lendacky@....com>,
Jim Mattson <jmattson@...gle.com>
Cc: Andy Lutomirski <luto@...nel.org>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Joerg Roedel <joro@...tes.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>,
"Chang S. Bae" <chang.seok.bae@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Sasha Levin <sashal@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: FSGSBASE causing panic on 5.9-rc1
On 8/20/20 12:05 PM, Tom Lendacky wrote:
>> I added a quick hack to save TSC_AUX to a new variable in the SVM
>> struct and then restore it right after VMEXIT (just after where GS is
>> restored in svm_vcpu_enter_exit()) and my guest is no longer crashing.
>
> Sorry, I mean my host is no longer crashing.
Just to make sure I've got this:
1. Older CPUs didn't have X86_FEATURE_RDPID
2. FSGSBASE patches started using RDPID in the NMI entry path when
supported *AND* FSGSBASE was enabled
3. There was a latent SVM bug which did not restore the RDPID data
before NMIs were reenabled after VMEXIT
4. If an NMI comes in the window between VMEXIT and the
wrmsr(TSC_AUX)... boom
If FSGSBASE reverted is disabled (as Tom did on the command-line), then
the RDPID path isn't hit.
Fun.
Powered by blists - more mailing lists