Am 30.05.2012 09:53, schrieb Alexander Graf: > Mind to elaborate (in the patch description maybe) why we need a CPU specific > TLB flush callback that merely calls the globally visible tlb_flush? :)
Ouch! That's one patch description I forgot to fill in. :-/ The issue is that env is defined in X86CPU, PowerPCCPU, etc. and its parent, CPUState, does not know about it. Thus, a function passed CPUState *cpu cannot call functions expecting CPUArchState *env, here tlb_flush(), unless it is target-specific (e.g., cpu_has_work()). I've previously structured my series in such a way that all references to env were removed first before the argument type was changed, cf. (iv) in [1]. VMState restricts my artistic freedom there by needing matching types of which the offsets are calculated and which is passed as opaque to its callbacks. So the alternative to finding some indirect way to call tlb_flush() from there would be to postpone patch 59 until the TLB is QOM'ified. But since Anthony had suggested to make "halted" a QOM property for controlling the vCPU, I did not want to wait forever. ;) To make it clear, this patch (or an alternative thereof) is only needed as band-aid for patch 59. It does not provide any value on its own. Long-term I was thinking of keeping cpu_tlb_flush() as wrapper that forwards to a TLBClass::flush() or so, so the function in qom/cpu.c wouldn't have been a complete waste. Andreas [1] https://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01286.html -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg