From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsC2j-0004dn-1P for qemu-devel@nongnu.org; Tue, 12 May 2015 11:24:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsC2f-0001sQ-4r for qemu-devel@nongnu.org; Tue, 12 May 2015 11:24:24 -0400 Received: from mail-qg0-x22f.google.com ([2607:f8b0:400d:c04::22f]:36822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsC2e-0001sJ-W0 for qemu-devel@nongnu.org; Tue, 12 May 2015 11:24:21 -0400 Received: by qgeb100 with SMTP id b100so5928809qge.3 for ; Tue, 12 May 2015 08:24:20 -0700 (PDT) Sender: Richard Henderson Message-ID: <55521B20.8050507@twiddle.net> Date: Tue, 12 May 2015 08:24:16 -0700 From: Richard Henderson MIME-Version: 1.0 References: <6920fa40d097d15d0cfcaf63c26b6325ee5edc46.1431322749.git.crosthwaite.peter@gmail.com> <55508206.5040206@suse.de> <55508368.3010300@redhat.com> <55510E7B.4050209@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Edgar Iglesias , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Soren Brinkmann , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 05/12/2015 12:23 AM, Peter Crosthwaite wrote: > In my multi-compile approach helper_*[ld|st]* needs to be renamed > per-arch for the multiple compiled cputlb.o. Hence I have no symbol > with the unqualified name. But even if I do solve my namespacing > problem, I still have an ambiguity of which cputlb.o provided > helper_*[ld|st]* to use from the TCG backend. This would mean all > those APIs would have to virtualised. The big question for Paolo, is > what complete set of APIs defines the common-code/non-common-code > boundary? tlb_fill does seem to do the job nicely and looking at the > architecture implementations it's not a super fast path (falling back > to a page table faulter). > > Somewhere along the call path from the qemu_st_helpers uses > (tcg/i386/tcg-target.c) through to tlb_fill there has to be a > virtualised function unless I am missing something? I think both cpu_unaligned_access and tlb_fill need to be hooked. >> I think that this is a decent step forward, modulo the conditionals along the >> use paths. I think we ought to clean up all of the translators to the new QOM >> hooks. >> > > So the conditional can be ditched by having the CPU base class > defaulting the hook to the globally defined function. Then arches can > be brought online one-by-one. Yes, exactly. > Ok so the solution to this is to opt-out of the hook via a re-#define > when we have a target-specific cpu.h handy. This will actually mean no > change to single-arch builds but multi-arch will use the hook from > core code only. Err... not via #defines, please. Just use the _foo name all spelled out from target-specific code. > I don't know what this means exactly. tlb_fill is called by functions > that are linked to common code (TCG backends) so I don't see a non > virtualized solution. Is this refactoring to move tlb_fill? It means if we do find a way to parameterize the tcg backend, e.g. by putting the whole table of functions into the class, then we can revisit generating cpu-specific versions of the memory helpers. r~