Hi Jan,
On Sat, Jun 11, 2011 at 11:23:31AM +0200, Jan Kiszka wrote:
> These FPU states are properly maintained by KVM but not yet by TCG. So
> far we unconditionally set them to 0 in the guest which may cause
> state corruptions - not only during migration.
I can't judge whether the patch is corr
On 2011-06-15 13:33, Avi Kivity wrote:
> On 06/15/2011 02:32 PM, Jan Kiszka wrote:
>>>
>>> If it isn't zero, there's still a good chance fopcode will be zero
>>> (64-bit userspace, thread that hasn't used the fpu since the last
>>> context switch, last opcode happened to be zero).
>>
>> I do not
On 06/15/2011 02:32 PM, Jan Kiszka wrote:
>
> If it isn't zero, there's still a good chance fopcode will be zero
> (64-bit userspace, thread that hasn't used the fpu since the last
> context switch, last opcode happened to be zero).
I do not yet find "if fopcode is invalid, it is zero, just a
On 2011-06-15 13:26, Avi Kivity wrote:
> On 06/15/2011 01:20 PM, Jan Kiszka wrote:
>> >
>> > So fopcode will usually be clear.
>> >
>>
>> OK. So if bit 2 of IA32_MISC_ENABLE MSR, we must save that fields. But
>> if it's off, how to test for that other condition "last non-transparent
>> FP instruct
On 06/15/2011 01:20 PM, Jan Kiszka wrote:
>
> So fopcode will usually be clear.
>
OK. So if bit 2 of IA32_MISC_ENABLE MSR, we must save that fields. But
if it's off, how to test for that other condition "last non-transparent
FP instruction ... had an unmasked exception" from the host?
We sav
On 2011-06-15 12:20, Jan Kiszka wrote:
> On 2011-06-15 11:10, Avi Kivity wrote:
>> On 06/14/2011 09:10 AM, Jan Kiszka wrote:
>>> On 2011-06-13 10:45, Avi Kivity wrote:
On 06/11/2011 12:23 PM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> These FPU states are properly maintained by KV
On 2011-06-15 11:10, Avi Kivity wrote:
> On 06/14/2011 09:10 AM, Jan Kiszka wrote:
>> On 2011-06-13 10:45, Avi Kivity wrote:
>> > On 06/11/2011 12:23 PM, Jan Kiszka wrote:
>> >> From: Jan Kiszka
>> >>
>> >> These FPU states are properly maintained by KVM but not yet by
>> TCG. So
>> >> far we u
On 06/14/2011 09:10 AM, Jan Kiszka wrote:
On 2011-06-13 10:45, Avi Kivity wrote:
> On 06/11/2011 12:23 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> These FPU states are properly maintained by KVM but not yet by TCG. So
>> far we unconditionally set them to 0 in the guest which may cause
>>
On 2011-06-14 10:23, Avi Kivity wrote:
> On 06/14/2011 09:10 AM, Jan Kiszka wrote:
>> On 2011-06-13 10:45, Avi Kivity wrote:
>> > On 06/11/2011 12:23 PM, Jan Kiszka wrote:
>> >> From: Jan Kiszka
>> >>
>> >> These FPU states are properly maintained by KVM but not yet by
>> TCG. So
>> >> far we u
On 06/14/2011 09:10 AM, Jan Kiszka wrote:
On 2011-06-13 10:45, Avi Kivity wrote:
> On 06/11/2011 12:23 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> These FPU states are properly maintained by KVM but not yet by TCG. So
>> far we unconditionally set them to 0 in the guest which may cause
>>
On 2011-06-13 10:45, Avi Kivity wrote:
> On 06/11/2011 12:23 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> These FPU states are properly maintained by KVM but not yet by TCG. So
>> far we unconditionally set them to 0 in the guest which may cause
>> state corruptions - not only during migration.
On 06/11/2011 12:23 PM, Jan Kiszka wrote:
From: Jan Kiszka
These FPU states are properly maintained by KVM but not yet by TCG. So
far we unconditionally set them to 0 in the guest which may cause
state corruptions - not only during migration.
-#define CPU_SAVE_VERSION 12
+#define CPU_SAVE_VERS
From: Jan Kiszka
These FPU states are properly maintained by KVM but not yet by TCG. So
far we unconditionally set them to 0 in the guest which may cause
state corruptions - not only during migration.
Signed-off-by: Jan Kiszka
---
target-i386/cpu.h |6 +-
target-i386/kvm.c |
13 matches
Mail list logo
