Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: George Dunlap <george.dunlap <at> eu.citrix.com>
Subject: Re: [PATCH] x86/fpu: CR0.TS should be set before trap into PV guest's #NM exception handler
Newsgroups: gmane.comp.emulators.xen.devel
Date: Thursday 27th February 2014 12:46:05 UTC (over 4 years ago)
On 02/27/2014 08:00 AM, Jan Beulich wrote:
>>>> On 27.02.14 at 01:04, Matt Wilson  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
 
CD: 8ms