On Mon, Nov 30, 2020, Paolo Bonzini wrote: > On 16/09/20 00:44, Sean Christopherson wrote: > > > KVM doesn't have control of them. They are part of the guest's encrypted > > > state and that is what the guest uses. KVM can't alter the value that the > > > guest is using for them once the VMSA is encrypted. However, KVM makes > > > some decisions based on the values it thinks it knows. For example, early > > > on I remember the async PF support failing because the CR0 that KVM > > > thought the guest had didn't have the PE bit set, even though the guest > > > was in protected mode. So KVM didn't include the error code in the > > > exception it injected (is_protmode() was false) and things failed. Without > > > syncing these values after live migration, things also fail (probably for > > > the same reason). So the idea is to just keep KVM apprised of the values > > > that the guest has. > > > > Ah, gotcha. Migrating tracked state through the VMSA would probably be ideal. > > The semantics of __set_sregs() kinda setting state but not reaaaally setting > > state would be weird. > > How would that work with TDX? Can you elaborate? I.e. how would what work with TDX?
