lkml.org 
[lkml]   [2021]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Thoughts of AMX KVM support based on latest kernel
Date
> From: Paolo Bonzini <pbonzini@redhat.com>
> 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
\
 
 \ /
  Last update: 2021-11-17 11:16    [W:0.092 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site