From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvuKj-0006mb-MD for qemu-devel@nongnu.org; Tue, 23 Aug 2011 13:00:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvuKc-0006p2-PQ for qemu-devel@nongnu.org; Tue, 23 Aug 2011 13:00:13 -0400 Received: from mail.windriver.com ([147.11.1.11]:60261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvuKc-0006lo-FO for qemu-devel@nongnu.org; Tue, 23 Aug 2011 13:00:06 -0400 Message-ID: <4E53DC90.5080007@windriver.com> Date: Tue, 23 Aug 2011 12:00:00 -0500 From: Jason Wessel MIME-Version: 1.0 References: <1314075344-20839-1-git-send-email-agraf@suse.de> In-Reply-To: <1314075344-20839-1-git-send-email-agraf@suse.de> Content-Type: multipart/alternative; boundary="------------010205090305010105040800" Subject: Re: [Qemu-devel] [PATCH 0/3] PPC: E500: Support SPE guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: scottwood@freescale.com, qemu-devel@nongnu.org --------------010205090305010105040800 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 08/22/2011 11:55 PM, Alexander Graf wrote: > When I bumped into Jason on Linuxcon, we tried out to run the e500 target > on his Windriver build that used SPE and immediately ran into emulation > issues. Fortunately there weren't too many, so here are the patches to get > a guest using SPE instructions working just fine. > The patch set looks good to me. I tried it out this morning. I have a patch that implements enough of the the dbcr0, dbsr, and msr DE bit in order to single step, but I am seeing random fatal mmu faults. Before we go down the route of implementing more pieces, I am interested to know if you see the same behavior, or if you had any ideas around how to further debug it. Using just your patch series + the QEMU HEAD + the SPE enabled rootfs + qemu NFS mounting the rootfs, here is the "litmus test" to see if you experience the fatal mmu faults to user space. ulimit -c unlimited while [ 1 ] ; do echo 3 > /proc/sys/vm/drop_caches (echo quit ; sleep 2) | gdb /bin/ls || break done I find that this runs between 1-15 times and crashes with a core file. Looking at the core file it is usually in a malloc or free operation in the user space, and always in the page fault handler in the kernel. This really amounts to running a medium sized app through the startup, which does a whole bunch of malloc and free because it maps in the elf debug info for /bin/ls , and gdb is not really getting used for anything to ptrace. Jason. --------------010205090305010105040800 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 08/22/2011 11:55 PM, Alexander Graf wrote:
> When I bumped into Jason on Linuxcon, we tried out to run the e500 target
> on his Windriver build that used SPE and immediately ran into emulation
> issues. Fortunately there weren't too many, so here are the patches to get
> a guest using SPE instructions working just fine.
>

The patch set looks good to me.  I tried it out this morning.

I have a patch that implements enough of the the dbcr0, dbsr, and msr DE bit in order to single step, but I am seeing random fatal mmu faults.   Before we go down the route of implementing more pieces, I am interested to know if you see the same behavior, or if you had any ideas around how to further debug it.

Using just your patch series + the QEMU HEAD + the SPE enabled rootfs + qemu NFS mounting the rootfs, here is the "litmus test" to see if you experience the fatal mmu faults to user space.

ulimit -c unlimited

while [ 1 ] ; do
   echo 3 > /proc/sys/vm/drop_caches
   (echo quit ; sleep 2) | gdb /bin/ls || break
done


I find that this runs between 1-15 times and crashes with a core file.  Looking at the core file it is usually in a malloc or free operation in the user space, and always in the page fault handler in the kernel.  This really amounts to running a medium sized app through the startup, which does a whole bunch of malloc and free because it maps in the elf debug info for /bin/ls , and gdb is not really getting used for anything to ptrace.

Jason.
--------------010205090305010105040800--