From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH v2] KVM: x86: Inject pending interrupt even if pending nmi exist Date: Wed, 23 Mar 2016 20:04:07 +0100 Message-ID: <20160323190406.GB22164@potion.brq.redhat.com> References: <7CC7D3013F4B10479273CE019E6A8C7A3ED90C@BPXM15GP.gisp.nec.co.jp> <56F297A7.1030309@redhat.com> <20160323172159.GA22164@potion.brq.redhat.com> <56F2DEDD.5060600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Yuki Shibuya , "kvm@vger.kernel.org" , Jan Kiszka , Nobuo Yoshida To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33219 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753771AbcCWTEL (ORCPT ); Wed, 23 Mar 2016 15:04:11 -0400 Content-Disposition: inline In-Reply-To: <56F2DEDD.5060600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2016-03-23 19:22+0100, Paolo Bonzini: > On 23/03/2016 18:21, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> NMIs are latched (queue length 1) and therefore cannot be pending af= ter >> an injection. I think we want to do it unconditionally. >=20 > If that is right, process_nmi would be the place where you'd limit th= e > queue to 1. You are right. I think we can always limit the queue to 1: process_nmi is from 7460fb4a3400 ("KVM: Fix simultaneous NMIs") and the commit message explains If simultaneous NMIs happen, we're supposed to queue the second and next (collapsing them), but currently we sometimes collapse the secon= d into the first. I think that hardware coalesces all NMIs that arrive within one instruction (NMI is delivered at instruction boundaries) and one NMI is sufficient anyway (all events that triggered NMIs are going to be handled in the first one and the second one is for nothing)= , so reasons behind "supposed to" elude me. We could overhaul NMI handling much more at that point, but it's safer to keep it this way as there aren't major bugs. :)