Re: [Xen-devel] [PATCH] x86/fpu: CR0.TS should be set before trap into PV guest's #NM exception handler

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 02/27/2014 08:00 AM, Jan Beulich wrote:
> > > > On 27.02.14 at 01:04, Matt Wilson <msw@xxxxxxxxx> wrote:
> > On Wed, Nov 06, 2013 at 08:51:56AM +0000, Jan Beulich wrote:
> > > Nevertheless I agree that there is an issue, but this needs to be
> > > fixed on the Linux side (hence adding the Linux maintainers to Cc);
> > > this issue was introduced way back in 2.6.26 (before that there
> > > was no allocation on that path). It's not clear though whether
> > > using GFP_ATOMIC for the allocation would be preferable over
> > > stts() before calling the allocation function (and clts() if it
> > > succeeded), or whether perhaps to defer the stts() until we
> > > actually know the task is being switched out. It's going to be an
> > > ugly, Xen-specific hack in any event.
> > Was there ever a resolution to this problem? I never saw a comment
> > from the Linux Xen PV maintainers.
> Neither did I, so no, I'm not aware of a solution.
Well we basically have two solutions I think:

1. Add a flag to the guest kernel that requests Xen to keep the TS bit 
set (and eat the extra cost of the trap on clearing it).
2. In the uncommon case of the first use, set the TS  bit again 
(incurring the cost of the extra trap) before calling allocate.
 -George

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