From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8ujO-0003xn-11 for qemu-devel@nongnu.org; Tue, 15 Dec 2015 13:53:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8ujJ-0003aP-Un for qemu-devel@nongnu.org; Tue, 15 Dec 2015 13:53:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8ujJ-0003Zo-Q4 for qemu-devel@nongnu.org; Tue, 15 Dec 2015 13:53:45 -0500 Date: Tue, 15 Dec 2015 19:53:39 +0100 From: Radim Krcmar Message-ID: <20151215185335.GF17283@potion.brq.redhat.com> References: <1449926146-14828-1-git-send-email-arei.gonglei@huawei.com> <566E9259.2010404@redhat.com> <33183CC9F5247A488A2544077AF19020B02B4533@SZXEMA503-MBS.china.huawei.com> <566EBB34.5030205@redhat.com> <33183CC9F5247A488A2544077AF19020B02B45BB@SZXEMA503-MBS.china.huawei.com> <566EC61A.7090407@redhat.com> <33183CC9F5247A488A2544077AF19020B02B4BE3@SZXEMA503-MBS.china.huawei.com> <145192308.40660604.1450176186593.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <145192308.40660604.1450176186593.JavaMail.zimbra@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] rtc: introduce nmi disable bit handler for cmos List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Gonglei (Arei)" , "Huangpeng (Peter)" , qemu-devel@nongnu.org, kevin@koconnor.net, rth@twiddle.net, ehabkost@redhat.com 2015-12-15 05:43-0500, Paolo Bonzini: >> Hi Paolo, >>=20 >> /* for KVM_GET/SET_VCPU_EVENTS */ >> struct kvm_vcpu_events { >> ... >> struct { >> __u8 injected; >> __u8 pending; >> __u8 masked; >> __u8 pad; >> } nmi; >> ... >>=20 >> I found that the nmi.masked property does these enable or disable NMI = jobs. >> So, I think we don't need to add a new bit. Right? >=20 > nmi.masked says whether the CPU is accepting the NMIs, and is cleared > by the next IRET instruction. This is a different thing; it probably > shouldn't affect NMI IPIs, and it definitely should remain set until > cleared via the RTC. So it should be something like >=20 > _u8 external_nmi_disabled; >=20 > or similar. >=20 > *However* I found this in the ICH9 datasheet: >=20 > The ICH9's I/O APIC can only send interrupts due to interrupts whic= h > do not include SMI, NMI or INIT. This means that in IA-32/Intel =C2= =AE 64 > based platforms, Front Side Bus interrupt message format delivery m= odes > 010 (SMI/PMI), 100 (NMI), and 101 (INIT) as indicated in this secti= on, > must not be used and is not supported. >=20 > In theory the PIIX4 could deliver such messages, but perhaps we could > disable them in the KVM IOAPIC. If we do this, there is no need for a > change to struct kvm_vcpu_events, because all external NMI sources will > be in userspace. >=20 > Radim, what do you think? I looked at the 440fx, piix, and 82083aa(ioapic) datasheets and the NMI_EN bit doesn't seem to be propagated into the IOAPIC. The IOAPIC datasheet doesn't mention a thing about NMI masking and PIIX4 generates NMI on SERR# or IOCHK# so it seems that the NMI_EN feature only changes the behavior of those two ... I think it's best to do nothing in KVM. (q35 guests shouldn't configure IOAPIC to send unsupported messages and disabling SMI/NMI/INIT in the in-kernel IOAPIC for piix is risky.)