On 2017-11-16 12:21, Rik van Riel wrote:
On Thu, 2017-11-16 at 10:50 +0800, Quan Xu wrote:
On 2017-11-15 22:43, Rik van Riel wrote:
Can you explain why you believe that?
for example, a vcpu thread is running in kvm mode under cretical
condition to stop. QEMU send an IPI to cause a VM-exit to happen
immediately, and this IPI doesn't make vcpu return to QEMU. IIUC
this vcpu thread will still continue to run in kvm mode when is
waked up at targer machine. with your patch, I don't see a chance
to load guest FPU or XSTATE, until return to QEMU and run kvm mode
again.
then the FPU or XSTATE status is inconsistent for a small window,
what's
even
worse is that the vcpu is running.
Did I misunderstand?
At context switch time, the context switch code will save
the guest FPU state to current->thread.fpu when the
VCPU thread is scheduled out.
When the VCPU thread is scheduled back in, the context
switch code will restore current->thread.fpu to the FPU
registers.
good catch!
Also as your comment, PKRU is switched out separately at
VMENTER and VMEXIT time, but with a lots of IF conditions..
the pkru may be restored with host pkru after VMEXIT. when
vcpu thread is scheduled out, the pkru value in current->thread.fpu.state
may be the host pkru value, instead of guest pkru value (of course,
this _assumes_ that the pkru is in current->thread.fpu.state as well).
in this way, the pkru may be a coner case.
VM migration again, in case,
source_host_pkru_value != guest_pkru_value,
target_host_pkru_value == guest_pkru_value..
the pkru status would be inconsistent..
Quan
Alibaba Cloud
The VCPU thread will never run with anything else than
the guest FPU state, while inside the KVM_RUN code.
