On Mon, Aug 04, 2014 at 06:30:09PM +0200, Marcin Gibuła wrote: > W dniu 2014-07-31 13:27, Marcin Gibuła pisze: > >>>Can you dump *env before and after the call to kvm_arch_get_registers? > >> > >>Yes, but it seems they are equal - I used memcmp() to compare them. Is > >>there any other side effect that cpu_synchronize_all_states() may have? > > > >I think I found it. > > > >The reason for hang is, because when second call to > >kvm_arch_get_registers() is skipped, it also skips kvm_get_apic() which > >updates cpu->apic_state. > > Paolo, > > is this analysis deep enough for you? I don't know if that can be fixed with > existing api as cpu_synchronize_all_states() is all or nothing kind of > stuff. > > Kvmclock needs it only to read current cpu registers, so syncing everything > is not really necessary. Perhaps exporting one of kvm_arch_get_* would be > enough. And it wouldn't mess with lazy get/put. > > On the other hand, if in future any other driver adds > cpu_synchronize_all_states() in its change state callback it could result in > same error so perhaps more generic approach is needed.
Does anybody know why the APIC state loaded by the first call to kvm_arch_get_registers() is wrong, in the first place? What exactly is different in the APIC state in the second kvm_arch_get_registers() call, and when/why does it change? If cpu_synchronize_state() does the wrong thing if it is called at the wrong moment, then we may have other hidden bugs, because the user can trigger cpu_synchronize_all_states() calls arbitrarily using monitor commands. -- Eduardo