Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions

[Richard Henderson]

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 <arch>_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~