From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IQQNS-0005rA-TU for qemu-devel@nongnu.org; Wed, 29 Aug 2007 12:26:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IQQNR-0005pg-Jq for qemu-devel@nongnu.org; Wed, 29 Aug 2007 12:26:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQQNR-0005pT-DT for qemu-devel@nongnu.org; Wed, 29 Aug 2007 12:26:45 -0400 Received: from mx2.suse.de ([195.135.220.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IQQNQ-0001lQ-TE for qemu-devel@nongnu.org; Wed, 29 Aug 2007 12:26:45 -0400 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id D990721992 for ; Wed, 29 Aug 2007 18:26:42 +0200 (CEST) Message-ID: <46D59E6B.1000606@suse.de> Date: Wed, 29 Aug 2007 18:27:23 +0200 From: Alexander Graf MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000702030106080204080308" Subject: [Qemu-devel] CC_DST problem Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------000702030106080204080308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I'm still trying to implement SVM correctly and hit a serious problem. If I set CC_OP to EFLAGS / DYNAMIC after each instruction (so most conditional operations are based on EFLAGS) everything works as expected. If using CC_OP==CC_OP_EFLAGS only CC_SRC should be used and CC_DST is supposed to be completely ignored. So I set CC_DST to 0 (this happens when leaving and rejoining the virtual machine, so this is the real problem) and if I do that, I get funny segmentation faults in x86_64 guest userspace programs running in the virtual machine (this is exactly what I see in kvm with my current patchset as well), while 32 bit userspace programs simply hang. So I guess this is the real problem. Is there any logical reason CC_DST could be used with CC_OP==CC_OP_EFLAGS? Attached to this email you will find a small patch that triggers this problem. Thanks for any reply that could help on this, Alexander Graf --------------000702030106080204080308 Content-Type: text/x-patch; name="eflags.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eflags.patch" Index: qemu/target-i386/op.c =================================================================== --- qemu.orig/target-i386/op.c +++ qemu/target-i386/op.c @@ -1248,6 +1248,13 @@ void OPPROTO op_movl_crN_T0(void) helper_movl_crN_T0(PARAM1); } +void OPPROTO op_geneflags(void) +{ + CC_SRC = cc_table[CC_OP].compute_all(); + CC_DST = 0; + CC_OP = CC_OP_EFLAGS; +} + #if !defined(CONFIG_USER_ONLY) void OPPROTO op_movtl_T0_cr8(void) { Index: qemu/target-i386/translate.c =================================================================== --- qemu.orig/target-i386/translate.c +++ qemu/target-i386/translate.c @@ -3154,6 +3154,12 @@ static target_ulong disas_insn(DisasCont target_ulong next_eip, tval; int rex_w, rex_r; + ////// DEBUG + if (s->cc_op != CC_OP_DYNAMIC) + gen_op_set_cc_op(s->cc_op); + gen_op_geneflags(); + s->cc_op = CC_OP_DYNAMIC; + /////////////////// s->pc = pc_start; prefixes = 0; aflag = s->code32; --------------000702030106080204080308--