Messages in this thread | ![/](/images/icornerl.gif) | | From | Andy Lutomirski <> | Date | Wed, 19 Aug 2020 14:25:09 -0700 | Subject | Re: FSGSBASE causing panic on 5.9-rc1 |
| |
On Wed, Aug 19, 2020 at 11:19 AM Tom Lendacky <thomas.lendacky@amd.com> wrote: > > On 8/19/20 1:07 PM, Tom Lendacky wrote: > > It looks like the FSGSBASE support is crashing my second generation EPYC > > system. I was able to bisect it to: > > > > b745cfba44c1 ("x86/cpu: Enable FSGSBASE on 64bit by default and add a chicken bit") > > > > The panic only happens when using KVM. Doing kernel builds or stress > > on bare-metal appears fine. But if I fire up, in this case, a 64-vCPU > > guest and do a kernel build within the guest, I get the following: > > I should clarify that this panic is on the bare-metal system, not in the > guest. And that specifying nofsgsbase on the bare-metal command line fixes > the issue.
I certainly see some oddities:
We have this code:
static void svm_vcpu_put(struct kvm_vcpu *vcpu) { struct vcpu_svm *svm = to_svm(vcpu); int i;
avic_vcpu_put(vcpu);
++vcpu->stat.host_state_reload; kvm_load_ldt(svm->host.ldt); #ifdef CONFIG_X86_64 loadsegment(fs, svm->host.fs); wrmsrl(MSR_KERNEL_GS_BASE, current->thread.gsbase); load_gs_index(svm->host.gs);
Surely that should do load_gs_index() *before* wrmsrl(). But that's not the problem at hand.
There are also some open-coded rdmsr and wrmsrs of MSR_GS_BASE -- surely these should be x86_gsbase_read_cpu() and x86_gsbase_write_cpu(). (Those functions don't actually exist, but the fsbase equivalents do, and we should add them.) But that's also not the problem at hand.
I haven't actually spotted the bug yet...
--Andy
| ![\](/images/icornerr.gif) |