From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception Date: Sun, 15 Nov 2009 15:36:58 +0100 Message-ID: <4B00120A.6010406@web.de> References: <20091111192947.348198723@localhost.localdomain> <20091111193837.115825934@localhost.localdomain> <20091112122659.GC7392@redhat.com> <4AFFF716.5000708@redhat.com> <20091115125146.GF7392@redhat.com> <4AFFFE1A.9090203@redhat.com> <4B001031.60508@web.de> <4B00118F.4080604@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig13CC11508BD3073CCFD62699" Cc: Gleb Natapov , Marcelo Tosatti , kvm@vger.kernel.org, jan.kiszka@siemens.com, joerg.roedel@amd.com To: Avi Kivity Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:36535 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752701AbZKOOgy (ORCPT ); Sun, 15 Nov 2009 09:36:54 -0500 In-Reply-To: <4B00118F.4080604@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig13CC11508BD3073CCFD62699 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 11/15/2009 04:29 PM, Jan Kiszka wrote: >> Avi Kivity wrote: >> =20 >>> On 11/15/2009 02:51 PM, Gleb Natapov wrote: >>> =20 >>>> =20 >>>>> "replacing" exceptions is dangerous in the case of debug exceptions= >>>>> and machine checks, since restarting execution won't recover them. >>>>> >>>>> >>>>> =20 >>>> But not replacing them is not better. No point in re-injecting >>>> exception that causes another exception. >>>> >>>> =20 >>> Right, just pointing out there's still a small hole left. Replacing = is >>> much better ignoring. >>> =20 >> Is the hardware doing some queuing in this case? >=20 > Gleb has verified by testing, and Intel has confirmed, that the hardwar= e > does not queue, and will in fact lose traps and NMIs in such a case. S= o > the small hole is actually present in the processor and we're better of= f > not queueing! I've forgotten about this but Gleb reminded me. >=20 >> Would it be overly >> complicated to adopt the real behavior here? >> =20 >=20 > Not only would it be difficult, it would also be incorrect. >=20 I'm all for correctness - so this correctly drop events. :) Jan --------------enig13CC11508BD3073CCFD62699 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAksAEgoACgkQitSsb3rl5xRrEgCeL+NbEONUPAiufKcRX95cbqyC lVIAn0jbd4G5BfNQqbbXi3zYqOhp8jLS =9RUX -----END PGP SIGNATURE----- --------------enig13CC11508BD3073CCFD62699--