On 06/05/2015 16:12, Richard Henderson wrote: >> Can >> > we rely on the env/CPUState always being up to date during >> > target_disas (which happens at translate time?) or will we need to go >> > field by field to make sure any env updates explicitly occur before >> > target_disas? > I *think* so, but it's a near thing. The path goes > > tb_find_fast: > cpu_get_tb_cpu_state, fill fill in flags for TB from current ENV state. > tb_find_slow, > tb_gen_code, using those same flags. > > There's the edge case of re-translation, but I'm going to assert that cpu mode > changes ought not happen in that context. Doing otherwise means that the > kernel has just switched modes, the translator has failed to end the TB, and > the new code has faulted immediately. > > What I don't know is if we can, at the moment, canonicalize on TB flags. If > the monitor were to use cpu_get_tb_cpu_state, I know it would work when using > TCG, but I don't know if we keep all the same data up-to-date in KVM or XEN > modes.
We do for KVM. As far as I know, Xen doesn't have CPU state at all, not even in fully-virtualized mode. The CPU state is held (and serialized during migration) by the hypervisor. Paolo