Leaving the data registers (i.e. XMM) aside -- the FP stack remains
unchanged -- the mxcsr is changing in the following way:
59143906000: system.cpu0: T0 : syscall clock_getres called w/arguments
4, 140737488348384, 140737488350520, 140737488347808, 140737341873792,
140737341867960
info: mxcsr: 0x1f80
(enter VM)
info: mxcsr: 0x1f80
(exit VM)
info: mxcsr: 0x1f80
(enter VM)
info: mxcsr: 0x1f84
(exit VM)
info: mxcsr: 0x1f84
(enter VM)
info: mxcsr: 0x1f84
(exit VM)
59282397000: system.cpu0: T0 : syscall clock_gettime called
w/arguments 4, 140737488348304, 140737488350520, 140737488347728,
140737341873792, 14073734186796
info: mxcsr: 0x1f84
(enter VM)
info: mxcsr: 0x1f84
(exit VM)
59324467500: system.cpu0: T0 : syscall clock_gettime called
w/arguments 4, 140737488348304, 0, 140737488347728, 140737341873792,
140737341867960
info: mxcsr: 0x1f84
(enter VM)
info: mxcsr: 0x1fa4
(exit VM)
59366650500: system.cpu0: T0 : syscall clock_gettime called
w/arguments 4, 140737488348304, 0, 140737488347728, 140737341873792,
140737341867960
info: mxcsr: 0x1fa4
(enter VM)
info: mxcsr: 0x1fa5
(exit VM)
Each of these mxcsr prints represent the content of mxcsr on entering
and exiting the VM, the first one being before entering. It seems that
bogus floting point results appear after the mxcsr is switched to
0x1f84, from 0x1f80 -- which is the default machine state used from
the begining of the execution. We can notice that all changes occur
when executing inside the VM. I will detail what seems to be happening
with the floating point unit based on these changes in the MXCSR:
0x1f80 -> 0x1f84 - overflow exception
0x1f84 -> 0x1fa4 - precision exception
0x1fa4 -> 0x1fa5 - invalid operand exception
I will be curious to know more about the interaction of KVM's eager
FPU context saving strategy and these changes in the FPU state. Please
let me know if you need more details.
Thank you,
Alex
On Thu, Aug 11, 2016 at 6:18 PM, Yang Zhang <yang.zhang.wz@xxxxxxxxx> wrote:
> On 2016/8/11 0:38, Alexandru Duţu wrote:
>>
>> Hi Yang,
>>
>> Yes, I have. In particular the FPU state is the following:
>
>
> I mean is the state same with the one after vmexit?
>
>
>>
>> FPU registers (XSave):
>> fcw: 0x0
>> fsw: 0x0 (top: 0, conditions: , exceptions: )
>> ftwx: 0xff
>> last_opcode: 0x0
>> last_ip: 0x0
>> last_dp: 0x0
>> mxcsr_mask: 0x0
>> mxcsr: 0x1f80
>> FP Stack:
>> ST0/0: 0x00000000000000000000 (0)
>> ST1/1: 0x00000000000000000000 (0)
>> ST2/2: 0x00000000000000000000 (0)
>> ST3/3: 0x00000000000000000000 (0)
>> ST4/4: 0x00000000000000000000 (0)
>> ST5/5: 0x00000000000000000000 (0)
>> ST6/6: 0x00000000000000000000 (0)
>> ST7/7: 0x00000000000000000000 (0)
>> XMM registers:
>> 0: 0x00000000000000400000000000000000
>> 1: 0x00000000000000000000000000000000
>> 2: 0x00000000000000000000000000000000
>> 3: 0x00000000000000000000000000000000
>> 4: 0x00000000000000000000000000000000
>> 5: 0x00000000000000000000000000000000
>> 6: 0x00000000000000000000000000000000
>> 7: 0x00000000000000000000000000000000
>> 8: 0x00000000000000000000000000000000
>> 9: 0x00000000000000000000000000000000
>> 10: 0x00000000000000000000000000000000
>> 11: 0x00000000000000000000000000000000
>> 12: 0x00000000000000000000000000000000
>> 13: 0x00000000000000000000000000000000
>> 14: 0x00000000000000000000000000000000
>> 15: 0x00000000000000000000000000000000
>>
>> Do you have particular registers you are wondering about?
>>
>> Thank you,
>> Alex
>>
>> On Sun, Aug 7, 2016 at 7:26 PM, Yang Zhang <yang.zhang.wz@xxxxxxxxx>
>> wrote:
>>>
>>> On 2016/8/5 4:40, Alexandru Duţu wrote:
>>>>
>>>>
>>>> Hi everyone,
>>>>
>>>> I am using KVM to run a virtual machine (x86) without having a guest
>>>> OS. So the machine state is set for long mode before calling KVM_RUN
>>>> and I am trapping out of KVM on every syscall to emulate the syscall
>>>> in the program that uses KVM. Also I am trapping out of KVM on
>>>> pagefaults to deal with stack growth.
>>>>
>>>> This has been working great for integer workloads, however I have
>>>> encoutered some workloads which are using floating point instructions,
>>>> for example cvtsi2sd to cast an integer to a double, and their result
>>>> is incorrect.
>>>>
>>>> Recently I have discovered that KVM does FPU context save on-demand,
>>>> meaning when the virtual machine actually uses the FPU [1]. I am
>>>
>>>
>>>
>>> Latest KVM will use eagerfpu if host is using eagerfpu.
>>>
>>>> wondering if this machanism has some baked in assumptions about
>>>> running a virtual machine with a guest OS and if a guest OS is not
>>>> present the FPU state might be altered? Also I have not seen any #NM
>>>> exceptions, these usually trap out of KVM.
>>>
>>>
>>>
>>> #NM exceptions will trap into KVM only when current hardware FPU state
>>> not
>>> belongs to the running VCPU, i.e. first access to FPU.
>>>
>>>>
>>>> The FPU state that I am using [2] seems valid and it does not change
>>>> when trapping out of KVM for syscalls and pagefaults. In addition, I
>>>
>>>
>>>
>>> Have you check the state before vm entry?
>>>
>>>> have tried running with multiple linux versions 2.6.29, 3.13 and 4.0.4
>>>> and all of them give incorrect floating point instructions result,
>>>> however for different instructions.
>>>>
>>>> Thank you,
>>>>
>>>
>>>
>>> --
>>> Yang
>>> Alibaba Cloud Computing
>>
>>
>>
>>
>
>
> --
> Yang
> Alibaba Cloud Computing
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
