[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions |
Date: |
Tue, 12 May 2015 08:24:16 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
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~
- [Qemu-devel] [RFC PATCH 03/34] target-multi: Add, (continued)
- [Qemu-devel] [RFC PATCH 03/34] target-multi: Add, Peter Crosthwaite, 2015/05/11
- [Qemu-devel] [RFC PATCH 01/34] cpu-all: Prototype cpu_exec and cpu_signal_handler, Peter Crosthwaite, 2015/05/11
- [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions, Peter Crosthwaite, 2015/05/11
- Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions, Richard Henderson, 2015/05/11
- Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions, Peter Crosthwaite, 2015/05/12
- Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions,
Richard Henderson <=
Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions, Peter Maydell, 2015/05/11
[Qemu-devel] [RFC PATCH 04/34] mb: Change target long to 64b, Peter Crosthwaite, 2015/05/11
Re: [Qemu-devel] [RFC PATCH 00/34] Multi Architecture System Emulation, Peter Maydell, 2015/05/11
Re: [Qemu-devel] [RFC PATCH 00/34] Multi Architecture System Emulation, Andreas Färber, 2015/05/11