> From: Paolo Bonzini <pbonzini@xxxxxxxxxx> > Sent: Wednesday, November 17, 2021 3:31 PM > > On 11/17/21 05:52, Nakajima, Jun wrote: > > If a (creative) guest wants to set XFD[AMX] = 1 for fun while keeping > > AMX state alive without saving the AXM state, it may lose the state > > after VM exit/entry. > > I think this should not happen, unless you also document that other > random events (hypothetically, it could be some other core using AMX?) > can cause the loss of XTILEDATA if XFD[AMX]=1. Virtualization should > not be special, I'd prefer that the guest has the same behavior as bare > metal in this respect. > The state may be lost with the simple version suggested by Thomas, because with XFD[AMX]=1 the AMX state won't be stored to guest_fpstate when the vcpu thread is preempted and then get lost when restored. To emulate the hardware behavior this will need additional trick to force XFD[AMX]=0 if XGETBV(1) is true (ignoring guest XFD) in fpu_update_guest_xfd_state(void). It also implies that the actual guest XFD needs to be saved in a place before forcing XFD[AMX] to 0 and recovered (after interrupt is disabled) before entering the guest. We are not sure whether such trick is worthwhile, since a sane guest shouldn't set XFD[AMX]=1 before storing the AMX state. This is why we want to seek SDM change to mark out that the software should not assume XTILEDATA is still valid when XFD[AMX]=1. Then KVM can make a simple assumption that once XFD[AMX]=1 it implies the guest doesn't care about the AMX state. Then the simple version from Thomas can work perfectly. Thanks Kevin
