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

Reply via email to