On Wed, 6 May 2015, Paolo Bonzini wrote: > 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.
Yes, that is correct, QEMU is only used as device emulator on Xen.
