[Xen-devel] fpu_taskswitch adjustment proposal

["Jan Beulich" <JBeulich@xxxxxxxx>]

While pv-ops so far doesn't care to eliminate the two trap-and-
emulate CR0 accesses from the asm/xor.h save/restore
operations, the legacy x86-64 kernel uses conditional clts()/stts()
for this purpose. While looking into whether to extend this to the
newly added (in 3.5) AVX operations there I realized that this isn't
fully correct: It doesn't properly nest inside a kernel_fpu_begin()/
kernel_fpu_end() pair (as it will stts() at the end no matter what
the original state of CR0.TS was).

In order to not introduce completely new hypercalls to overcome
this (fpu_taskswitch isn't really extensible on its own), I'm
considering to add a new VM assist, altering the fpu_taskswitch
behavior so that it would return an indicator whether any change
to the virtual CR0.TS was done. That way, the kernel can
implement a true save/restore cycle here.

In order to allow the kernel to run on older hypervisors without
extra conditionals (behaving the same way as it does currently,
i.e. with the incorrect nesting), the return value 0 (which the
hypercall currently always returns) would need to be used to
indicate that the bit got actually flipped (such that on an old
hypervisor an updated kernel would always think that
something needs to be restored).

Would that be an acceptable solution? Can someone think of
other ways to deal with this? (And - is pv-ops interested in
eliminating the two CR0 access emulations in what is supposed
to be a fast path?)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel