Re: [Xen-devel] XSAVE IRC thread

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/05/2013 12:13, Ben Guthro wrote:
> On May 3, 2013, at 10:58 AM, Jan Beulich <JBeulich@xxxxxxxx>
>  wrote:
>
>>>>> On 30.04.13 at 18:24, Mark Roddy <mark.roddy@xxxxxxxxxx> wrote:
>>> The two values are pointers to the before and after regions:
>>>
>>> 1: kd> dd 841c4880
>>> 841c4880  0000027f 00000000 6e83506e 0000001b
>>> 841c4890  01d113d8 00000023 00001f80 0000ffff
>>> 841c48a0  00000000 00000000 00000000 00000000
>>> 841c48b0  00000000 00000000 00000000 00000000
>>> 841c48c0  00000000 00000000 00000000 00000000
>>> 841c48d0  00000000 00000000 00000000 00000000
>>> 841c48e0  00000000 00000000 00000000 00000000
>>> 841c48f0  00000000 00000000 00000000 00000000
>>>
>>> 1: kd> dd 841c4600 
>>> 841c4600  0000027f 00000000 6e83506e 00000000
>>> 841c4610  01d113d8 00000000 00001f80 0000ffff
>>> 841c4620  00000000 00000000 00000000 00000000
>>> 841c4630  00000000 00000000 00000000 00000000
>>> 841c4640  00000000 00000000 00000000 00000000
>>> 841c4650  00000000 00000000 00000000 00000000
>>> 841c4660  00000000 00000000 00000000 00000000
>>> 841c4670  00000000 00000000 00000000 00000000
>>>
>>> I don't know if that helps, but obviously there are differences, two of 
>>> them, at offsets 0xc and 0x12.
>>>
>>> " Interrupt Service Routine 88CAC91C has changed extended thread context.
>>> Context saved before executing ISR: 841C4880. Context saved after executing 
>>> ISR: 841C4600."
>>>
>>> 841C4880 is before and 841C4600 is after.
>> Attached a patch that I think should address this problem. It's
>> against the tip of the staging tree, and doesn't apply without
>> adjustment to 4.2 (and making it work for 4.1 would be quite a
>> bit more work) - please let me know whether that's sufficient for
>> you testing this, or whether you need me to do any backporting.
>>
>> I didn't verify this with any Windows, but since the same issue
>> can - if one is looking for it - be observed on PV Linux, I did verify
>> the patch to help there.
>>
>> I'd like to note though that while this is expected to help with
>> 32-bit guests, and with a 64-bit guest kernels doing such checking
>> after using the respective save (and possibly restore) instructions
>> with a 64-bit operand size, the hypervisor has no way of knowing
>> whether the context actually belongs to a 32-bit process while the
>> guest is in kernel (64-bit) mode. That means that from a 32-bit
>> app's perspective, inconsistencies could still be observed under
>> certain conditions (but the case where the hypervisor side save
>> happens after a VM exit from user mode should also work with
>> that patch). I don't see any way to hide that, other than running
>> on CPUs that don't save/restore the selector values at all
>> anymore (Intel at least has a feature bit for this).
>>
>> Jan
>>
>> <x86-FPU-preserve-selectors.patch>
> Jan,
>
> Thank you very much for looking into this so quickly.
>
> Our QA infrastructure is currently set up for testing against our XenClient 
> product built on Xen 4.2.2.
> Since this is an intermittent failure, in order to reduce the number of 
> variables in testing this solution,
> I'll look into backporting this on Mon to 4.2, and report back after a night, 
> or two of testing.
>
> Thanks again for your help
>
> Ben

I will also look to getting this into XenServer testing ASAP

~Andrew

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


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