From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SR2OE-0005GQ-2k for qemu-devel@nongnu.org; Sun, 06 May 2012 10:24:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SR2OC-0006TI-5W for qemu-devel@nongnu.org; Sun, 06 May 2012 10:24:45 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51508 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SR288-00078N-9T for qemu-devel@nongnu.org; Sun, 06 May 2012 10:08:08 -0400 Message-ID: <4FA685C5.3060004@suse.de> Date: Sun, 06 May 2012 16:08:05 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <4F9EC895.5010303@suse.de> <7692E997-2413-4B64-93D0-960BE4B260BB@suse.de> <4FA65002.1000000@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Poking a sun4v machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Juan Quintela , Alexander Graf , Artyom Tarasenko , qemu-devel Am 06.05.2012 12:58, schrieb Blue Swirl: > On Sun, May 6, 2012 at 10:18 AM, Andreas F=C3=A4rber = wrote: >> Am 06.05.2012 10:58, schrieb Alexander Graf: >>> Am 06.05.2012 um 10:29 schrieb Blue Swirl : >>>> On Wed, May 2, 2012 at 2:38 PM, Artyom Tarasenko wrote: >>>>> On Tue, May 1, 2012 at 4:06 PM, Blue Swirl w= rote: >>>>>> On Tue, May 1, 2012 at 13:54, Artyom Tarasenko wrote: >>>>>>> To me it looks like at the end do_interrupt will have less >>>>>>> common parts between sun4u and sun4v than specific ones. >>>>>> >>>>>> Same as tlb_fill(), switch() or function pointer. The functions ar= e different. >>>>>> >>>>>> This is unavoidable (unless maybe in the future the TLB handling c= an >>>>>> be pushed partially higher so mmu_idx parameters can be eliminated= ) >>>>>> and the performance cost is not great. >> [...] >>>> Architectures are not meant to handle small issues like this. >>>> Should performance become a problem, there are a plenty of lower >>>> hanging fruits where to start optimizing. >>>> >>>> Even in this case, rather than the new architecture solution, it cou= ld >>>> be possible to build separate TLB handlers which call directly the >>>> correct MMU functions without switches and these would be selected a= t >>>> translation time or earlier. For the PPCEMB case, maybe the memory A= PI >>>> could be changed to handle different page sizes without loss of >>>> performance, I don't know. Devices should not depend on >>>> TARGET_PAGE_SIZE. >>> >>> It's not a matter of an API. The main problem is that the QEMU TLB ha= s to be fine grained enough to handle 1k faults, so it has to be in 1k-st= eps in its current design. >> >> Due to the TLB being a common property of CPUs yet dependent on target >> sizes, I had the idea of breaking it out from CPU(Arch)State so that w= e >> can have a different inheritance hierarchy than for CPUs. But that's >> just an unevaluated idea so far and more than 138 commits in the futur= e. >=20 > Yes, this is in part what I wanted with cputlb.[ch] change. >=20 >> Same problem for breakpoints and watchpoints btw. >> >> ppcemb is no priority for me, but in order to move the very basic halt= ed >> and interrupt_request fields to CPUState, for a VMState post_load hook >> we need to be able to tlb_flush() based on CPUState rather than >> CPUArchState. Currently just a pointer hack on qom-cpu branch; as an >> interim solution I might just defer that to target code to workaround >> the problem... >=20 > Could the TLB become a separate object? That's what I meant with "breaking it out from CPU(Arch)State". :) /-F --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg