From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33742 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHiCu-00081r-J7 for qemu-devel@nongnu.org; Thu, 27 May 2010 14:53:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHiCs-0003s3-Qc for qemu-devel@nongnu.org; Thu, 27 May 2010 14:53:28 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:35423) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHiCs-0003rk-G9 for qemu-devel@nongnu.org; Thu, 27 May 2010 14:53:26 -0400 Message-ID: <4BFEBF9E.90600@web.de> Date: Thu, 27 May 2010 20:53:18 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4BFE8F13.2000009@cs.vu.nl> In-Reply-To: <4BFE8F13.2000009@cs.vu.nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig17E0A615793659D9027E46BA" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: SVM emulation: EVENTINJ marked valid when a pagefault happens while issuing a software interrupt List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Erik van der Kouwe Cc: Joerg Roedel , qemu-devel@nongnu.org, Gleb Natapov This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig17E0A615793659D9027E46BA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Erik van der Kouwe wrote: > Dear all, >=20 > I have been experiencing problems with duplicate delivery of software > interrupts when running a VMM inside QEMU with SVM emulation. I believe= Be warned: Though my experience is already more than a year old, the SVM emulation in QEMU is most probably not yet rock-stable. Always check suspicious behavior against real hardware and/or the spec. [ As real hardware is everywhere, nesting works with KVM+SVM and is much faster, motivation to improve QEMU in this area is unfortunately limited. ] > QEMU's behaviour deviates from the SVM specification in "AMD64 > Architecture Programmer=E2=80=99s Manual Volume 2 System Programming" b= ut I am > not entirely certain because this specification isn't very clear. I > would like to hear your views on this. >=20 > My set-up is as follows: > Host: Linux 2.6.31-21-generic-pae (Ubuntu 9.10) > VMM running on host: QEMU 0.12.3 (compiled from source) > Outer guest: MINIX 3.1.7 (from SVN, see http://www.minix3.org/) > VMM running on outer guest: Palacios 1.2.0 32-bit (from git, see > http://www.v3vee.org/palacios/) > Inner guest: MINIX 3.1.7 (from SVN, see http://www.minix3.org/) >=20 > The issue is the following: whenever an software interrupt instruction > (INT n, used in this case to perform a system call) in the inner guest > triggers a page fault (used for shadow paging by Palacios, not a real > guest page fault), QEMU sets the EVENTINV field of the guest VMCB to th= e > exit information that the software interrupt would produce and marks it= > as valid. Palacios does not overwrite the EVENTINJ field, so after the > page fault is handled a software interrupt event is injected. After the= > IRET of the interrupt handler, control returns to the original INT n > instruction which once again triggers the interrupt. >=20 > This issue is easy to work around by clearing the EVENTINJ field on eac= h > #VMEXIT (and I have submitted a patch to that effect to the Palacios > people) and this approach is also found in KVM. /me does not find such clearing in KVM - what line(s) are you looking at?= >=20 > However, I haven't been able to find information in the AMD > documentation that mentions that the CPU sets the valid bit in the > EVENTINJ field so, unless I am mistaken here, I believe this behaviour > is incorrect. QEMU stores interrupt information in both EVENTINJ and > EXITINTINFO while I believe it should be only in the latter. > Unfortunately I don't have a physical AMD available to verify its > behaviour. Based on the KVM code (which is known to work perfectly :) ), I think you are right: SVM apparently clears the valid bit in EVENTINJ during VMRUN once it starts processing the injection, not after it as it's the case in current QEMU. But better ask the experts: J=C3=B6rg, Gleb? >=20 > The relevant code is in target-i386/op_helper.c. The "handle_even_inj" > function sets the EVENTINJ field (called event_inf in the QEMU code) an= d > the helper_vmexit function copies that field into EXITINTINFO > (exit_int_info in the QEMU code). I believe (but once again, am not > certain) that the SVM documentation only says that this information > should be stored in EXITINTINFO. Yes, this also looks suspicious. handle_even_inj should not push the real (level 1) event to be injected into event_inj[_err] but into exit_int_info[_err] or some temporary fields from which the exit info is then loaded later on. Jan --------------enig17E0A615793659D9027E46BA 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 iEYEARECAAYFAkv+v6IACgkQitSsb3rl5xRleQCfX7K6FoIlKlfMKm7sD1g+0AWQ VHEAoNNWolwrY2XfBInbzLt1RmIdfAoR =iCPZ -----END PGP SIGNATURE----- --------------enig17E0A615793659D9027E46BA--