On 14/11/2017 07:59, Kang, Luwei wrote:
> Will add it in next version. This is use for live migration, is that right?
Yes.
> If use XSAVES and XRSTORS for context switch.
> 1. Before kvm_load_guest_fpu(vcpu), we need to save host RTIT_CTL, disable PT and restore the value of "vmx->pt_desc.guest.ctl" to GUEST_IA32_RTIT_CTL. Is that right?
The idea is to make the MSR get/set handlers operate on an XSAVES state
separate from the guest FPU state. RTIT_CTL in the XSAVES state is
special cased to always be zero.
Then you could do
if (!system mode) {
if (guest RTIT_CTL.TraceEn != 0) {
set PT in IA32_XSS
XSAVES the host PT state
// RTIT_CTL.TraceEn is now zero, and remains zero after XRSTORS
XRSTORS the guest PT state
clear PT in IA32_XSS
} else {
save host RTIT_CTL
}
// guest RTIT_CTL.TraceEn will be loaded by vmentry
}
on vmentry, and
if (!system mode) {
// RTIT_CTL.TraceEn is zero here
if (guest RTIT_CTL.TraceEn != 0) {
set PT in IA32_XSS
// no need to XSAVES guest state, all MSR writes cause a vmexit
XRSTORS the host PT state
clear PT in IA32_XSS
} else if (host RTIT_CTL.TraceEn != 0) {
restore host RTIT_CTL
}
}
on vmexit. It should still be cheaper than many rdmsr/wrmsr operations.
Paolo
> 2. After VM-exit (step out from kvm_x86_ops->run(vcpu)), we need to
> save the status of GUEST_IA32_RTIT_CTL . TRACEEN=0 and others MSRs are
> still in guest status. Where to enable PT if in host-guest mode. I think
> we should enable PT after vm-exit but it may cause #GP. " If XRSTORS
> would restore (or initialize) PT state and IA32_RTIT_CTL.TraceEn = 1,
> the instruction causes a general-protection exception. SDM 13.5.6". if
> enable after kvm_put_guest_fpu() I think it too late.)
