[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200509110542.8159-3-xiaoyao.li@intel.com>
Date: Sat, 9 May 2020 19:05:36 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Sean Christopherson <sean.j.christopherson@...el.com>,
kvm@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>, peterz@...radead.org,
Arvind Sankar <nivedita@...m.mit.edu>,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Xiaoyao Li <xiaoyao.li@...el.com>
Subject: [PATCH v9 2/8] x86/split_lock: Remove bogus case in handle_guest_split_lock()
The bogus case can never happen, i.e., when sld_state == sld_off, guest
won't trigger split lock #AC and of course no handle_guest_split_lock()
will be called.
Beside, drop bogus case also makes future patch easier to remove
sld_state if we reach the alignment that it must be sld_warn or
sld_fatal when handle_guest_split_lock() is called.
Signed-off-by: Xiaoyao Li <xiaoyao.li@...el.com>
---
The alternative would be to remove the "SLD enabled" check from KVM so
that a truly unexpected/bogus #AC would generate a warn. It's not clear
whether or not calling handle_guest_split_lock() iff SLD is enabled was
intended in the long term.
---
arch/x86/kernel/cpu/intel.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 0e6aee6ef1e8..4602dac14dcb 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1088,9 +1088,8 @@ bool handle_guest_split_lock(unsigned long ip)
return true;
}
- pr_warn_once("#AC: %s/%d %s split_lock trap at address: 0x%lx\n",
- current->comm, current->pid,
- sld_state == sld_fatal ? "fatal" : "bogus", ip);
+ pr_warn_once("#AC: %s/%d fatal split_lock trap at address: 0x%lx\n",
+ current->comm, current->pid, ip);
current->thread.error_code = 0;
current->thread.trap_nr = X86_TRAP_AC;
--
2.18.2
Powered by blists - more mailing lists