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 <laijs@xxxxxxxxxxxxxx> > > > 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 <laijs@xxxxxxxxxxxxxx> > Reported-by: Kenji Kaneshige <kaneshige.kenji@xxxxxxxxxxxxxx> > Acked-by: Avi Kivity <avi@xxxxxxxxxx> > Acked-by: Jan Kiszka <jan.kiszka@xxxxxx> Please rebase. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
