From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/1 V4] qemu-kvm: fix improper nmi emulation Date: Fri, 14 Oct 2011 08:49:06 +0200 Message-ID: <4E97DB62.9020605@web.de> References: <20110913093835.GB4265@localhost.localdomain> <20110914093441.e2bb305c.kamezawa.hiroyu@jp.fujitsu.com> <4E705BC3.5000508@cn.fujitsu.com> <20110915164704.9cacd407.kamezawa.hiroyu@jp.fujitsu.com> <4E71B28F.7030201@cn.fujitsu.com> <4E72F3BA.2000603@jp.fujitsu.com> <4E73200A.7040908@jp.fujitsu.com> <4E76C6AA.9080403@cn.fujitsu.com> <4E7B04DC.1030407@cn.fujitsu.com> <4E7B4B8F.507@siemens.com> <4E7C51E4.2000503@cn.fujitsu.com> <4E7F3585.40108@redhat.com> <4E7F635E.6080009@web.de> <4E8035F9.9080908@redhat.com> <4E928B54.1070707@cn.fujitsu.com> <4E92958E.9000509@web.de> <4E9476E2.1070804@cn.fujitsu.com> <4E948842.4030406@web.de> <4E978827.6070008@cn.fujitsu.com> <4E97CE42.9020102@web.de> <4E97D85C.7070107@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD20CD09473BD0F55FC1CE443" Cc: "kvm@vger.kernel.org" , Avi Kivity , "qemu-devel@nongnu.org" , KAMEZAWA Hiroyuki , Kenji Kaneshige To: Lai Jiangshan Return-path: In-Reply-To: <4E97D85C.7070107@cn.fujitsu.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD20CD09473BD0F55FC1CE443 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-10-14 08:36, Lai Jiangshan wrote: > On 10/14/2011 01:53 PM, Jan Kiszka wrote: >> On 2011-10-14 02:53, Lai Jiangshan wrote: >>> >>>> >>>> As explained in some other mail, we could then emulate the missing >>>> kernel feature by reading out the current in-kernel APIC state, test= ing >>>> if LINT1 is unmasked, and then delivering the NMI directly. >>>> >>> >>> Only the thread of the VCPU can safely get the in-kernel LAPIC states= , >>> so this approach will cause some troubles. >> >> run_on_cpu() can help. >> >> Jan >> >=20 > Ah, I forgot it, Thanks. >=20 > From: Lai Jiangshan >=20 > 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. >=20 > With this patch, inject-nmi request is handled as follows. >=20 > - 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) >=20 > Changed from old version: > re-implement it by the Jan's suggestion. >=20 > Signed-off-by: Lai Jiangshan > Reported-by: Kenji Kaneshige > --- > hw/apic.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ > hw/apic.h | 1 + > monitor.c | 6 +++++- > 3 files changed, 54 insertions(+), 1 deletions(-) > diff --git a/hw/apic.c b/hw/apic.c > index 69d6ac5..9a40129 100644 > --- a/hw/apic.c > +++ b/hw/apic.c > @@ -205,6 +205,54 @@ void apic_deliver_pic_intr(DeviceState *d, int lev= el) > } > } > =20 > +#ifdef KVM_CAP_IRQCHIP Again, this is always defined on x86 thus pointless to test. > +static inline uint32_t kapic_reg(struct kvm_lapic_state *kapic, int re= g_id); > + > +struct kvm_get_remote_lapic_params { > + CPUState *env; > + struct kvm_lapic_state klapic; > +}; > + > +static void kvm_get_remote_lapic(void *p) > +{ > + struct kvm_get_remote_lapic_params *params =3D p; > + > + kvm_get_lapic(params->env, ¶ms->klapic); When you already interrupted that vcpu, why not inject from here? Avoids one further ping-pong round. > +} > + > +void apic_deliver_nmi(DeviceState *d) > +{ > + APICState *s =3D DO_UPCAST(APICState, busdev.qdev, d); > + > + if (kvm_irqchip_in_kernel()) { > + struct kvm_get_remote_lapic_params p =3D {.env =3D s->cpu_env,= }; > + uint32_t lvt; > + > + run_on_cpu(s->cpu_env, kvm_get_remote_lapic, &p); > + lvt =3D kapic_reg(&p.klapic, 0x32 + APIC_LVT_LINT1); > + > + if (lvt & APIC_LVT_MASKED) { > + return; > + } > + > + if (((lvt >> 8) & 7) !=3D APIC_DM_NMI) { > + return; > + } > + > + cpu_interrupt(s->cpu_env, CPU_INTERRUPT_NMI); Err, aren't you introducing KVM_CAP_LAPIC_NMI that allows to test if this workaround is needed? Oh, your latest kernel patch is missing this again - requires fixing as well. Jan --------------enigD20CD09473BD0F55FC1CE443 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6X22IACgkQitSsb3rl5xTgCwCgwUHA/tG0kKlEKBOk5d2u0BWp L2IAn2dSWAkiOh2ipW/WqcRlhKUe42Fe =chug -----END PGP SIGNATURE----- --------------enigD20CD09473BD0F55FC1CE443--