2016-04-23 1:21 GMT+08:00 David Matlack :
> On Fri, Apr 22, 2016 at 12:30 AM, Wanpeng Li wrote:
>> Hi Paolo and David,
>> 2016-03-31 3:24 GMT+08:00 David Matlack :
>>>
>>> kernel_fpu_begin() saves the current fpu context. If this uses
2016-04-23 1:21 GMT+08:00 David Matlack :
> On Fri, Apr 22, 2016 at 12:30 AM, Wanpeng Li wrote:
>> Hi Paolo and David,
>> 2016-03-31 3:24 GMT+08:00 David Matlack :
>>>
>>> kernel_fpu_begin() saves the current fpu context. If this uses
>>> XSAVE[OPT], it may leave the xsave area in an undesirable
On Fri, Apr 22, 2016 at 12:30 AM, Wanpeng Li wrote:
> Hi Paolo and David,
> 2016-03-31 3:24 GMT+08:00 David Matlack :
>>
>> kernel_fpu_begin() saves the current fpu context. If this uses
>> XSAVE[OPT], it may leave the xsave area in an undesirable state.
On Fri, Apr 22, 2016 at 12:30 AM, Wanpeng Li wrote:
> Hi Paolo and David,
> 2016-03-31 3:24 GMT+08:00 David Matlack :
>>
>> kernel_fpu_begin() saves the current fpu context. If this uses
>> XSAVE[OPT], it may leave the xsave area in an undesirable state.
>> According to the SDM, during XSAVE bit
Hi Paolo and David,
2016-03-31 3:24 GMT+08:00 David Matlack :
> An interrupt handler that uses the fpu can kill a KVM VM, if it runs
> under the following conditions:
> - the guest's xcr0 register is loaded on the cpu
> - the guest's fpu context is not loaded
> - the host
Hi Paolo and David,
2016-03-31 3:24 GMT+08:00 David Matlack :
> An interrupt handler that uses the fpu can kill a KVM VM, if it runs
> under the following conditions:
> - the guest's xcr0 register is loaded on the cpu
> - the guest's fpu context is not loaded
> - the host is using eagerfpu
>
>
On Fri, Apr 8, 2016 at 9:50 AM, Paolo Bonzini wrote:
>
>
> On 08/04/2016 18:25, David Matlack wrote:
>> On Thu, Apr 7, 2016 at 12:03 PM, Paolo Bonzini wrote:
Thank you :). Let me know how testing goes.
>>>
>>> It went well.
>>
>> Great! How
On Fri, Apr 8, 2016 at 9:50 AM, Paolo Bonzini wrote:
>
>
> On 08/04/2016 18:25, David Matlack wrote:
>> On Thu, Apr 7, 2016 at 12:03 PM, Paolo Bonzini wrote:
Thank you :). Let me know how testing goes.
>>>
>>> It went well.
>>
>> Great! How should we proceed?
>
> It will appear very
On 08/04/2016 18:25, David Matlack wrote:
> On Thu, Apr 7, 2016 at 12:03 PM, Paolo Bonzini wrote:
>>>
>>> Thank you :). Let me know how testing goes.
>>
>> It went well.
>
> Great! How should we proceed?
It will appear very soon on kvm/next and Radim will send the pull
On 08/04/2016 18:25, David Matlack wrote:
> On Thu, Apr 7, 2016 at 12:03 PM, Paolo Bonzini wrote:
>>>
>>> Thank you :). Let me know how testing goes.
>>
>> It went well.
>
> Great! How should we proceed?
It will appear very soon on kvm/next and Radim will send the pull
request to Linus next
On Thu, Apr 7, 2016 at 12:03 PM, Paolo Bonzini wrote:
>>
>> Thank you :). Let me know how testing goes.
>
> It went well.
Great! How should we proceed?
On Thu, Apr 7, 2016 at 12:03 PM, Paolo Bonzini wrote:
>>
>> Thank you :). Let me know how testing goes.
>
> It went well.
Great! How should we proceed?
- Original Message -
> >>> While running my acceptance tests, in one case I got one CPU whose xcr0
> >>> had leaked into the host. This showed up as a SIGILL in strncasecmp's
> >>> AVX code, and a simple program confirmed it:
> >>>
> >>> $ cat xgetbv.c
> >>> #include
> >>>
- Original Message -
> >>> While running my acceptance tests, in one case I got one CPU whose xcr0
> >>> had leaked into the host. This showed up as a SIGILL in strncasecmp's
> >>> AVX code, and a simple program confirmed it:
> >>>
> >>> $ cat xgetbv.c
> >>> #include
> >>>
On Thu, Apr 7, 2016 at 2:08 AM, Paolo Bonzini wrote:
>
>
> On 05/04/2016 17:56, David Matlack wrote:
>> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote:
>>>
>> ...
>>>
>>> While running my acceptance tests, in one case I got one CPU whose xcr0
>>>
On Thu, Apr 7, 2016 at 2:08 AM, Paolo Bonzini wrote:
>
>
> On 05/04/2016 17:56, David Matlack wrote:
>> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote:
>>>
>> ...
>>>
>>> While running my acceptance tests, in one case I got one CPU whose xcr0
>>> had leaked into the host. This showed up as
On 05/04/2016 17:56, David Matlack wrote:
> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote:
>>
> ...
>>
>> While running my acceptance tests, in one case I got one CPU whose xcr0
>> had leaked into the host. This showed up as a SIGILL in strncasecmp's
>> AVX code, and
On 05/04/2016 17:56, David Matlack wrote:
> On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote:
>>
> ...
>>
>> While running my acceptance tests, in one case I got one CPU whose xcr0
>> had leaked into the host. This showed up as a SIGILL in strncasecmp's
>> AVX code, and a simple program
On 05/04/2016 17:56, David Matlack wrote:
> > I'm going to rerun the tests without this patch, as it seems the most
> > likely culprit, and leave it out of the pull request if they pass.
>
> Agreed this is a very likely culprit. I think I see one way the
> guest's xcr0 can leak into the host. I
On 05/04/2016 17:56, David Matlack wrote:
> > I'm going to rerun the tests without this patch, as it seems the most
> > likely culprit, and leave it out of the pull request if they pass.
>
> Agreed this is a very likely culprit. I think I see one way the
> guest's xcr0 can leak into the host. I
On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote:
>
...
>
> While running my acceptance tests, in one case I got one CPU whose xcr0
> had leaked into the host. This showed up as a SIGILL in strncasecmp's
> AVX code, and a simple program confirmed it:
>
> $ cat
On Tue, Apr 5, 2016 at 4:28 AM, Paolo Bonzini wrote:
>
...
>
> While running my acceptance tests, in one case I got one CPU whose xcr0
> had leaked into the host. This showed up as a SIGILL in strncasecmp's
> AVX code, and a simple program confirmed it:
>
> $ cat xgetbv.c
> #include
>
On 30/03/2016 21:24, David Matlack wrote:
> An interrupt handler that uses the fpu can kill a KVM VM, if it runs
> under the following conditions:
> - the guest's xcr0 register is loaded on the cpu
> - the guest's fpu context is not loaded
> - the host is using eagerfpu
>
> Note that the
On 30/03/2016 21:24, David Matlack wrote:
> An interrupt handler that uses the fpu can kill a KVM VM, if it runs
> under the following conditions:
> - the guest's xcr0 register is loaded on the cpu
> - the guest's fpu context is not loaded
> - the host is using eagerfpu
>
> Note that the
On 30/03/2016 21:24, David Matlack wrote:
> An interrupt handler that uses the fpu can kill a KVM VM, if it runs
> under the following conditions:
> - the guest's xcr0 register is loaded on the cpu
> - the guest's fpu context is not loaded
> - the host is using eagerfpu
>
> Note that the
On 30/03/2016 21:24, David Matlack wrote:
> An interrupt handler that uses the fpu can kill a KVM VM, if it runs
> under the following conditions:
> - the guest's xcr0 register is loaded on the cpu
> - the guest's fpu context is not loaded
> - the host is using eagerfpu
>
> Note that the
An interrupt handler that uses the fpu can kill a KVM VM, if it runs
under the following conditions:
- the guest's xcr0 register is loaded on the cpu
- the guest's fpu context is not loaded
- the host is using eagerfpu
Note that the guest's xcr0 register and fpu context are not loaded as
part
An interrupt handler that uses the fpu can kill a KVM VM, if it runs
under the following conditions:
- the guest's xcr0 register is loaded on the cpu
- the guest's fpu context is not loaded
- the host is using eagerfpu
Note that the guest's xcr0 register and fpu context are not loaded as
part
28 matches
Mail list logo