From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DWvHf-0003MP-MO for qemu-devel@nongnu.org; Sat, 14 May 2005 07:58:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DWvHa-0003Ji-UV for qemu-devel@nongnu.org; Sat, 14 May 2005 07:58:16 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DWvHZ-00033k-EC for qemu-devel@nongnu.org; Sat, 14 May 2005 07:58:13 -0400 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DWv0g-0004s6-80 for qemu-devel@nongnu.org; Sat, 14 May 2005 07:40:46 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: request : qemu-smp as target Date: Sat, 14 May 2005 12:31:21 +0100 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505141231.22402.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: Blue Swirl On Saturday 14 May 2005 10:37, Blue Swirl wrote: > Hi, > > The architecture used in sparc target (sun4m) supports SMP up to a maximum > of 16 CPUs. At hardware emulation level (hw/*, target-sparc/*), it would be > easy to add the missing interprocessor interrupts, per-CPU counters and > atomic instructions. It would also be simple to add the prom functions for > starting/stopping CPUs to Proll. Maybe some days' work in total. > > Higher level (vl.c, cpu-exec.c) could need more work. Maybe Fabrice can > enlighten us? I guess you'd really want to simulate multiple CPUs with multiple host threads. One of the additional problems could then be memory/cache coherency. I'm not sure how much of a problem this would be in practice. If both host and guest require the same (or no) explicit SMP memory barriert it's not a problem. It the guest has stronger coherency requirements than the host we have a problem. > For some reason, Sparc performance is low (1/10 of native x86 nbench) > compared to x86 (2/3). Simulating SMP on a uniprocessor would only decrease > performance. It think x86-on-x86 user-mode uses code-copying by default. ie. it runs a lot of the the code unmodified. In my experience i386-softmmu is generally 10-15x slower than native, and arm-user is 5-10x slower. Paul