From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2oGZ-0007bS-0U for qemu-devel@nongnu.org; Mon, 13 Jan 2014 15:37:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2oGX-0000Gl-Jp for qemu-devel@nongnu.org; Mon, 13 Jan 2014 15:37:46 -0500 Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:57843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2oGX-0000GQ-Bf for qemu-devel@nongnu.org; Mon, 13 Jan 2014 15:37:45 -0500 Received: by mail-lb0-f180.google.com with SMTP id n15so1526032lbi.11 for ; Mon, 13 Jan 2014 12:37:43 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1389598802-14977-1-git-send-email-edgar.iglesias@gmail.com> References: <1389598802-14977-1-git-send-email-edgar.iglesias@gmail.com> From: Artyom Tarasenko Date: Mon, 13 Jan 2014 21:37:23 +0100 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH v3 00/22] Steps towards per CPU address-spaces List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: edgar.iglesias@gmail.com Cc: Peter Maydell , qemu-devel , Blue Swirl , aliguori@amazon.com, pcrost@xilinx.com, Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Aurelien Jarno , Richard Henderson Hi Edgar, On Mon, Jan 13, 2014 at 8:39 AM, wrote: > From: "Edgar E. Iglesias" > > Hi, > > I'm looking at modeling systems where multiple CPUs co-exist with > different views of their attached buses/devs. > > With this series I'm trying to take some steps towards having > an address-space per CPU. This is a very interesting approach. Would it be also possible to have multiple address-spaces per CPU? At least SPARC emulation would profit from that, the CPUs have separate MMUs for data and code. Artyom > It's not complete but good enough for > making it possible to model (to some extent) CPU local memories > for MicroBlaze systems in emulation mode (TCG). I'm updating the > petalogix-ml605 here and will follow-up later with the petalogix-s3adsp. > > The per-cpu address space is added into the CPUState. I tried to > measure performance diff with having it in the CPUState->env. > For "normal" and even for IO heavy workloads on linux kernels, > the diff is not measurable. I also tested with a tight guest loop > that continuously does I/O accesses and there I can see a 2.5% drop in perf. > I dont think the runtime type check involved when casting from env to CS > will be much of a problem. > > I've reordered the series and moved the AS props to the end, hoping > we can get through the bulk of the series with less controversy and > get it commited soon. > I've kept the interface with properties to set AddressSpace pointers > which I think is the more flexible approach but we can explore other > ideas if there are. > > There is lots of future work needed, for example to transform more of > the cpu_* bus accessing functions. To add more usage of AddressSpace > properties to pass on address spaces to DMA models. Qtest mechanisms > to target specific address spaces, etc... > > Cheers, > Edgar > > v2 -> v3: > Move CPU address-space prop into CPUState level. > > v1 -> v2: > Add braces in cpu_memory_rw_debug. > Avoid mixing var/code declarations in tcg_commit. > Move per-cpu address space into CPUState. > Reorder patch series to add the AS properties last. -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu