Hi,
I noticed that the TSC handling code has recently changed, and since it
wasn't done correctly in the nested VMX patch, I wanted to take the opportunity
to fix it.
I looked at what nested SVM does about TSC, and most of it I think I
understand, but a couple of other things I don't understand.
The basic point is that when L1 starts L2 with some vmcs12.tsc_offset
(nested_vmcb->control.tsc_offset in SVM nomenclature), the TSC that L1
actually thinks it is offsetting from is already the hardware TSC plus
the vmcs01.tsc_offset. So when L0 runs L2, it needs to use the offset
vmcs01.tsc_offset + vmcs12.tsc_offset.
This explains the line
svm->vmcb->control.tsc_offset += nested_vmcb->control.tsc_offset;
in nested_svm_vmrun().
In svm_adjust_tsc_offset(), when the hardware TSC changes (e.g., when moving
cores?) and the TSC offset is changed to keep the guest TSC unchanged,
when in nested mode we need to update both the currently running L2's tsc
offset, but also also L1's when we eventually return to it, which explains
the code in that function.
But there are two things I don't understand:
1. in svm_get_msr(), MSR_IA32_TSC, there is a special is_nested() case which
basically ignores the above mentioned addition and uses just the L0->L1
tsc offset. why? Why isn't svm->vmcb->control.tsc_offset + native_read_tsc()
the correct thing in both cases?
2. In svm_write_tsc_offset(), when in a nested guest, we don't write the offset
given to us, but (if I understand correctly) set this offset for the *L1*
guest (and set the L2's tsc offset accordingly, adding to it vmcs12's
tsc offset). Why was this done? Why was the simple code
svm->vmcb->control.tsc_offset = offset;
and that's it, not the right thing to do in this function?
I'd be thankful if anyone can shed some light on these questions.
Nadav.
--
Nadav Har'El | Friday, Oct 1 2010, 23 Tishri 5771
nyh@xxxxxxxxxxxxxxxxxxx |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |The space between my ears was
http://nadav.harel.org.il |intentionally left blank.
--
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
