From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LfGga-0000nT-2B for qemu-devel@nongnu.org; Thu, 05 Mar 2009 11:44:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LfGgY-0000kN-E6 for qemu-devel@nongnu.org; Thu, 05 Mar 2009 11:44:39 -0500 Received: from [199.232.76.173] (port=59639 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LfGgY-0000k5-8Z for qemu-devel@nongnu.org; Thu, 05 Mar 2009 11:44:38 -0500 Received: from mx20.gnu.org ([199.232.41.8]:59464) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LfGgX-00030S-JD for qemu-devel@nongnu.org; Thu, 05 Mar 2009 11:44:38 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LfGgT-0003eU-9x for qemu-devel@nongnu.org; Thu, 05 Mar 2009 11:44:33 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 7/7] PPC64: Don't fault at lwsync Date: Thu, 5 Mar 2009 16:44:30 +0000 References: <1236262454-6293-1-git-send-email-agraf@suse.de> <1236262454-6293-7-git-send-email-agraf@suse.de> <1236262454-6293-8-git-send-email-agraf@suse.de> In-Reply-To: <1236262454-6293-8-git-send-email-agraf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903051644.30883.paul@codesourcery.com> 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 Cc: blauwirbel@gmail.com, Alexander Graf , Alexander Graf > If anyone knows how to really fix this, please step forward and do > so. This only makes things work at all for me :-). I bet lwsync being a nop is a clue. When an MMU exception occurs, qemu figures out the guest location from the location of the MMU access in guest code (see cpu_restore_state). My guess is that this breaks when two guest instructions have the same location. I'm not entirely sure what the correct fix is, or where the bug lies (cpu_restore_state, gen_intermediate_code_pc, or tcg_gen_code_search_pc) but hopefully this will point you in the right direction. One thing to try (to confirm this theory) is make lwsync do domething (write to a dummy register or call a helper function) and see if the problem goes away. Paul