From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 1/1 V6 resent ] qemu-kvm: fix improper nmi emulation Date: Thu, 27 Oct 2011 10:47:14 -0200 Message-ID: <20111027124714.GB30571@amt.cnet> References: <4EA68790.4020606@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Jan Kiszka , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Hiroyuki KAMEZAWA , Kenji Kaneshige To: Lai Jiangshan Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46968 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751827Ab1J0MuT (ORCPT ); Thu, 27 Oct 2011 08:50:19 -0400 Content-Disposition: inline In-Reply-To: <4EA68790.4020606@cn.fujitsu.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Oct 25, 2011 at 05:55:28PM +0800, Lai Jiangshan wrote: > Previous discussions------------: > >> >> > >> >> Which approach you prefer to? > >> >> I need to know the result before wasting too much time to respin > >> >> the approach. > > > > > > Yes, sorry about the slow and sometimes conflicting feedback. > > > > >> >> 1) Fix KVM_NMI emulation approach (which is v3 patchset) > >> >> - It directly fixes the problem and matches the > >> >> real hard ware more, but it changes KVM_NMI bahavior. > >> >> - Require both kernel-site and userspace-site fix. > >> >> > >> >> 2) Get the LAPIC state from kernel irqchip, and inject NMI if it is allowed > >> >> (which is v4 patchset) > >> >> - Simple, don't changes any kernel behavior. > >> >> - Only need the userspace-site fix > >> >> > >> >> 3) Add KVM_SET_LINT1 approach (which is v5 patchset) > >> >> - don't changes the kernel's KVM_NMI behavior. > >> >> - much complex > >> >> - Require both kernel-site and userspace-site fix. > >> >> - userspace-site should also handle the !KVM_SET_LINT1 > >> >> condition, it uses all the 2) approach' code. it means > >> >> this approach equals the 2) approach + KVM_SET_LINT1 ioctl. > >> >> > >> >> This is an urgent bug of us, we need to settle it down soo > > > > > > While (1) is simple, it overloads a single ioctl with two meanings, > > > that's not so good. > > > > > > Whether we do (1) or (3), we need (2) as well, for older kernels. > > > > > > So I recommend first focusing on (2) and merging it, then doing (3). > > > > > > (note an additional issue with 3 is whether to make it a vm or vcpu > > > ioctl - we've been assuming vcpu ioctl but it's not necessarily the best > > > choice). > > > > It is the 2) approach. > It only changes the user space site, the kernel site is not touched. > It is changed from previous v4 patch, fixed problems found by Jan. > ----------------------------end previous discussions > > > From: Lai Jiangshan > > > Currently, NMI interrupt is blindly sent to all the vCPUs when NMI > button event happens. This doesn't properly emulate real hardware on > which NMI button event triggers LINT1. Because of this, NMI is sent to > the processor even when LINT1 is maskied in LVT. For example, this > causes the problem that kdump initiated by NMI sometimes doesn't work > on KVM, because kdump assumes NMI is masked on CPUs other than CPU0. > > With this patch, inject-nmi request is handled as follows. > > - When in-kernel irqchip is disabled, deliver LINT1 instead of NMI > interrupt. > - When in-kernel irqchip is enabled, get the in-kernel LAPIC states > and test the APIC_LVT_MASKED, if LINT1 is unmasked, and then > delivering the NMI directly. (Suggested by Jan Kiszka) > > Changed from old version: > re-implement it by the Jan's suggestion. > fix the race found by Jan. > > Signed-off-by: Lai Jiangshan > Reported-by: Kenji Kaneshige > Acked-by: Avi Kivity > Acked-by: Jan Kiszka Please rebase.