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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.11.13 at 00:35, Sarah Newman <srn@xxxxxxxxx> wrote:

>> Note the comment close to the beginning - the fact that CR0.TS
>> is clear at exception handler entry is actually part of the PV ABI,
>> i.e. by altering hypervisor behavior here you break all forward
>> ported kernels.
>> 
>> 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.
> 
> This is a serious bug.  Unfortunately not all of us have the option of 
> updating our guests if/when
> such a fix is made to Linux.
> 
> How about a per domU + xen command line configuration option to implement 
> Zhu's changes that is
> disabled by default?  I'm willing to try to implement it.

There's nothing keeping you from doing so - whether we'd then
accept it as a workaround, or whether instead you'd have to
carry it as a private patch would need to be seen. Iirc there
hasn't been a precedent like this (a command line / config file
override to alter the ABI), so I can't really make predictions on
how acceptable such a change might be.

I'm personally not eager to see something like this go in, most
importantly because I think bugs should be fixed where they
got introduced, not worked around elsewhere, and also
because I think that a generally available workaround would
lower the chances of the bug getting fixed properly.

Apart from that this workaround of yours would have very
ugly behavior: If a guest later got updated to a fixed kernel,
you'd have to alter its configuration along with booting into
the new kernel (i.e. a simple reboot of the VM won't do), or
else your new kernel would crash due to not clearing CR0.TS
before trying to restore FPU context.

Jan


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