From: "Nadav Har'El" <nyh@math.technion.ac.il>
To: kvm@vger.kernel.org
Cc: joro@8bytes.org
Subject: TSC in nested SVM and VMX
Date: Fri, 1 Oct 2010 00:50:58 +0200 [thread overview]
Message-ID: <20100930225058.GA10452@fermat.math.technion.ac.il> (raw)
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@math.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |The space between my ears was
http://nadav.harel.org.il |intentionally left blank.
next reply other threads:[~2010-09-30 22:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 22:50 Nadav Har'El [this message]
2010-10-01 4:38 ` TSC in nested SVM and VMX Zachary Amsden
2010-10-01 11:21 ` Nadav Har'El
2010-10-01 14:46 ` Alexander Graf
2010-10-01 19:22 ` Zachary Amsden
2010-10-02 1:56 ` Alexander Graf
2010-10-02 11:19 ` Alexander Graf
2010-10-02 22:46 ` Zachary Amsden
2010-10-03 0:01 ` Alexander Graf
2010-10-03 8:35 ` Nadav Har'El
2010-10-03 9:01 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100930225058.GA10452@fermat.math.technion.ac.il \
--to=nyh@math.technion.ac.il \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox