[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modular tcg

From: Claudio Fontana
Subject: Re: modular tcg
Date: Thu, 29 Jul 2021 12:42:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 7/29/21 12:26 PM, Gerd Hoffmann wrote:
>   Hi,
>>> It's basically two groups:
>>>  * Arch-specific (functions taking CPUX86State as argument), most of the
>>>    unresolved symbols in target/i386/ and i386/ directories go into this
>>>    category.
>> Yes, and we need to think about all targets, not just i386.
> Sure.  I just want go forward in small steps, so my plan is to tackle
> them one by one (starting with i386).
>>>  * Common (functions taking CPUState as argument).  Everything else.
>>> The common functions could be added TCGCPUOps to allow them being called via
>> TCGCCPUOps are target-specific in their implementation, so I guess
>> it's the arch specific part that could be TCGCPUOps (maybe, would need
>> deep thinking).
> Ok, lets make it three groups then.
>   (1) generic interface, arch implementation (this is what we have
>       TCGCPUOps hooks right now).
>   (2) generic interface, generic implementation (functions taking a
>       CPUState as argument, simliar to group (1).
>   (3) arch-specific interface and implementation (functions taking a
>       CPUX86State argument).
> We could add group (2) to TCGCPUOps for this ...
>>> CPUClass->tcg_ops->$name instead of a direct symbol reference.  Not sure 
>>> this
>>> is a good idea though.  Experimental patch covering tcg_exec_realizefn +
>>> tcg_exec_unrealizefn below.
> ... but as I sayed, not sure this is the best plan.
> Adding group (3) to TCGCPUOps is a non-starter IMHO given that the
> function prototypes are arch-specific (using CPUX86State) and also
> the interfaces actually needed are arch-specific.  something like
> x86_register_ferr_irq or cpu_x86_update_dr7 simply doesn't exist on
> !x86.  I guess we'll need TCG${arch}Ops for those.
>>> No idea yet how to handle arch-specific bits best.  Seems there is no 
>>> existing
>>> infrastructure to untangle target-specific code and tcg, so this probably 
>>> needs
>>> something new.
>> We need target-specific modules. They could at the beginning absorb
>> also the non-target specific parts in my view.  So you have a big
>> tcg-arm module, a tcg-i386 module etc.
>> I think I sketched already the idea in the Makefile I shared before?
> We have target-specific modules in master branch.
> Used for qtest (all archs) and tcg (i386/x86_64 only, accel ops only).
> The build system changes to build more tcg bits modular are here:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/modules-tcg-meson
> Doesn't build due unresolved symbols, but shows which code
> changes/cleanups/reorganizations are needed for (more) modular tcg.
> take care,
>   Gerd

What I mean is, for starters, lets make all tcg code land in the 
target-specific module.

Sorry I am multitasking quite a bit so I may be missing something obvious.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]