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