From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Regression] kvm-userspace: VM freezes after booting FreeDOS Date: Sat, 12 Jul 2008 13:19:42 +0200 Message-ID: <4878934E.70504@web.de> References: <52d4a3890807100847q5aef1a69hbd7179b018cb02ad@mail.gmail.com> <48763963.3010406@codemonkey.ws> <52d4a3890807101252h13c24b0ej35b4af71ac6b5b58@mail.gmail.com> <48766AE0.2050400@codemonkey.ws> <52d4a3890807101332v2cfe5604g78dc2d225e3c67d9@mail.gmail.com> <48767DB3.7090701@web.de> <52d4a3890807101559i408e3d3at8030034e858f0256@mail.gmail.com> <48773BA3.7090900@siemens.com> <52d4a3890807110755j4c501040y4749181ccfc33420@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig154F1EDA5A1AC0864E46A657" Cc: Jan Kiszka , Anthony Liguori , kvm@vger.kernel.org, Avi Kivity , Rik van Riel To: Mohammed Gamal Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:49512 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752192AbYGLLTs (ORCPT ); Sat, 12 Jul 2008 07:19:48 -0400 In-Reply-To: <52d4a3890807110755j4c501040y4749181ccfc33420@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig154F1EDA5A1AC0864E46A657 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mohammed Gamal wrote: > On Fri, Jul 11, 2008 at 1:53 PM, Jan Kiszka wr= ote: >> Mohammed Gamal wrote: >>> On Fri, Jul 11, 2008 at 12:22 AM, Jan Kiszka wrot= e: >>>> Mohammed Gamal wrote: >>>>> On Thu, Jul 10, 2008 at 11:02 PM, Anthony Liguori wrote: >>>>>> Mohammed Gamal wrote: >>>>>>> On Thu, Jul 10, 2008 at 7:31 PM, Anthony Liguori >>>>>>> wrote: >>>>>>> >>>>>>>> Mohammed Gamal wrote: >>>>>>>> >>>>>>>>> After updating my kvm-userspace tree to the latest git tree. I = am no >>>>>>>>> more able to run FreeDOS. The VM freezes after choosing any of = the >>>>>>>>> boot options. I am running both latest kvm.git and kvm-userspac= e.git >>> >>> >>>>> After booting FreeDOS, there are a number of boot options with >>>>> different memory extenders, after selecting any option the system >>>>> freezes and I get [Stopped] in thr QEMU title bar. >>>> "Stopped" - interesting. Seems like something causes QEMU to stop th= e >>>> guest as if some breakpoint was injected. >>>> >>>> I just downloaded that image and gave it a try against vanilla kvm-7= 0 >>>> and my own tree which is augment with guest debugging related patche= s. >>>> The former shows your observed behavior (Boot from CD, provide an em= pty >>>> HD image -> press '1' + ENTER -> press '1' -> "Stopped"). The latter= kvm >>>> tree made QEMU leave with a #GP in the guest. That may point to a de= bug >>>> register related issue, and that patch you identified just happen to= >>>> make it visible. However, will try to investigate. >>>> >>>> Jan >>> I'm interested in seeing these patches. If your tree is hosted online= , >>> could you please provide me with its location so that I can merge it >>> with mine. If not, where can I get them from? >> Find both attached. They are a rebase of the kernel side (subset) from= >> my earlier posted debug rework series. They apply against latest kvm >> kernel git in this order: >> >> 1. kvm-new-guest-debug-interface-v2.patch >> 2. kvm-x86-virtualize-debug-registers-v2.patch >> >> The first one makes no difference, but the second one changes the >> behavior from reporting a breakpoint to userland to reporting an excep= tion. >> >=20 > Thanks for sending. >=20 >> I haven't found enough time to dig into this yet, but my gut feeling s= o >> far is that some x86 real mode emulation issue is biting us. Debug >> registers are not involved, I've cross-checked with enhanced QEMU >> supporting that feature - no invocation of related helper functions th= ere. >> >=20 > I still think it might be an issue with debug exceptions. I did get a > #GP after applying your patches. >=20 > Analyizng the output I observed a few things: > - rflags has TF, IF, DF, RF, and of course VM set and IOPL =3D 3. Do we= Yes, we have TF set (I checked for this initially as well, but I starred at the wrong nibble). Here is the related code from himem.exe (himem64.asm [1]): > ;**********************************************************************= ******** > ; 16-bit transient code and data. only used once. > ;**********************************************************************= ******** > ; checks if CPU is a 386 > ; In: nothing > ; Out: CY=3D0 - processor is a 386 or higher > ; CY=3D1 - processor lower than 386 >=20 > proc check_cpu > pushf > xor ax,ax > push ax > popf > pushf > pop ax > and ah,0fh > cmp ah,0fh > je not386 > mov ah,7 > push ax > popf > pushf Here we crash (with my patch) or report a break to the host (vanilla) instead of delivering a #DB trap to the guest. > pop ax > and ah,7 > je not386 > popf > clc > ret > not386: > popf > stc > ret > endp check_cpu > handle interrupts while being aware that single-stepping takes a > higher priority over all other external interrupts? May be some > interrupt was injected while TF was set and we try to serve that > interrupt first? If yes, would that cause a #GP? >=20 > - The #GP pushed error code b . CIIW, but doesn't this mean it was > caused by a #DB exception (bits EXT =3D 1, IDT =3D 1, with IDT vector 1= > which is a debug exception) . It looks like that we should forward all #DB exceptions to the guest in real mode unless we are sure they were caused by a host-injection. Here is more or less a hack to achieve this (breaking guest debugging for now): diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index b60fcec..a6f9c9b 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2244,6 +2244,15 @@ static int handle_rmode_exception(struct kvm_vcpu = *vcpu, if (((vec =3D=3D GP_VECTOR) || (vec =3D=3D SS_VECTOR)) && err_code =3D=3D= 0) if (emulate_instruction(vcpu, NULL, 0, 0, 0) =3D=3D EMULATE_DONE) return 1; + /* + * Forward #DB + * FIXME: Quick-hack, breaks guest debugging in real mode, will be + * fixed with the required debugging infrastructure rework. + */ + if (vec =3D=3D 1) { + vmx_inject_irq(vcpu, vec); + return 1; + } return 0; } =20 /me now wonders if there are not even more exceptions that have to be forwarded. Right now we catch them all, but I did not find some path via which actual ones are pushed to the guest. Jan PS: The check for vcpu->arch.rmode.active is handle_rmode_exception is redundant. --------------enig154F1EDA5A1AC0864E46A657 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 iEYEARECAAYFAkh4k1EACgkQniDOoMHTA+mo1wCcC+t48cK0VU1SVMGxr+rd5Woj brEAnRfzaIqxk0kpGBJnoFMUF/ds5tob =n5gu -----END PGP SIGNATURE----- --------------enig154F1EDA5A1AC0864E46A657--