On Wed, Jul 20, 2011, Zachary Amsden wrote about "Re: Nested VMX - L1 hangs on running L2":
> > > No, both patches are wrong.
> >
>
> kvm_get_msr(vcpu, MSR_IA32_TSC, &tsc) should always return the L1 TSC,
> regardless of the setting of any MSR bitmap. The reason why is that it
> is being called by the L0 hypervisor kernel, which handles only
> interactions with the L1 MSRs.
guest_read_tsc() (called by the above get_msr) currently does this:
static u64 guest_read_tsc(void)
{
u64 host_tsc, tsc_offset;
rdtscll(host_tsc);
tsc_offset = vmcs_read64(TSC_OFFSET);
return host_tsc + tsc_offset;
}
I guess you'd want this to change to something like:
tsc_offset = is_guest_mode(vcpu) ?
vmx->nested.vmcs01_tsc_offset :
vmcs_read64(TSC_OFFSET);
But I still am not convinced that that would be right....
E.g., imagine the case where L1 uses TSC_OFFSETING and but doesn't
trap TSC MSR read. The SDM says (if I understand it correctly) that this TSC
MSR read will not exit (because L1 doesn't trap it) but *will* do the extra
offsetting. In this case, the original code (using vmcs02's TSC_OFFSET which
is the sum of that of vmcs01 and vmcs12), is correct, and the new code will
be incorrect. Or am I misunderstanding the SDM?
Can you tell me in which case the original code would return incorrect
results to a guest (L1 or L2) doing anything MSR-related?
I'm assuming that some code in KVM also uses kvm_read_msr and assumes it
gets the TSC value for L1, not for the guest currently running (L2 or L1).
I don't understand why it needs to assume that... Why would it be wrong to
return L2's TSC, and just remember that *changing* the L2 TSC really means
changing the L1 TSC offset (vmcs01_tsc_offset), not vmcs12.tsc_offset which
we can't touch?
Thanks,
Nadav.
--
Nadav Har'El | Wednesday, Jul 27 2011, 25 Tammuz 5771
nyh@xxxxxxxxxxxxxxxxxxx |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |You may only be one person to the world,
http://nadav.harel.org.il |but may also be the world to one person.
--
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
