[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.