Re: [Xen-devel] fpu_taskswitch adjustment proposal

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Jun 18, 2012 at 08:32:05AM +0100, Jan Beulich wrote:
> >>> On 15.06.12 at 19:06, Keir Fraser <keir@xxxxxxx> wrote:
> > On 15/06/2012 17:03, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > 
> >> 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).

That sounds like a bug in the generic code then?
> >> 
> >> 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.

How would that work with the multi-calls? Right now clts is batched
and so is cr0 write.
> > 
> > It should be possible for the guest kernel to track its CR0.TS setting
> > shouldn't it? It gets modified only via a few paravirt hooks, and implicitly

Hm, the clts() paravirt could take advantage of the per-cpu cr0 to
figure out whether it truly needs to do anything.

> > cleared on #NM.
> Sure, but selling this to the Linux maintainers I would expect to be
> harder than fitting the Xen side of things into the current save-
> and-restore model the native xor code uses. It would only be strait
> forward to implement on the legacy, forward ported trees.
> 
> However, with the #NM handler in pv-ops apparently not
> leveraging the fact that CR0.TS is already cleared for it on entry,
> maybe this could indeed be introduced together. Konrad?

Would this require an extra pvops call from the #NM handler?

> 
> Jan

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