From: Jan Kiszka <jan.kiszka@web.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Arthur Chunqi Li <yzt356@gmail.com>,
kvm@vger.kernel.org, gleb@redhat.com, "Zhang,
Yang Z" <yang.z.zhang@intel.com>
Subject: Re: [PATCH v5] KVM: nVMX: Fully support of nested VMX preemption timer
Date: Fri, 27 Sep 2013 08:37:14 +0200 [thread overview]
Message-ID: <5245279A.4090302@web.de> (raw)
In-Reply-To: <52449CBD.4010603@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
On 2013-09-26 22:44, Paolo Bonzini wrote:
> Il 26/09/2013 19:47, Paolo Bonzini ha scritto:
>>
>> If I only apply this hunk, which disables the preemption timer while
>> in L1:
>>
>> @@ -8396,6 +8375,8 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu)
>>
>> load_vmcs12_host_state(vcpu, vmcs12);
>>
>> + vmcs_write32(PIN_BASED_VM_EXEC_CONTROL, vmx_pin_based_exec_ctrl(vmx));
>> +
>> /* Update TSC_OFFSET if TSC was changed while L2 ran */
>> vmcs_write64(TSC_OFFSET, vmx->nested.vmcs01_tsc_offset);
>>
>> then the testcase works for somewhat larger values of the preemption timer
>> (up to ~1500000 TSC cycles), but then fails.
Err, does this mean we run L1 with PIN_BASED_VM_EXEC_CONTROL of L2?
Ouch. Should be fixed independently.
>
> I mean if I apply it on top of current kvm/next, without Arthur's patch.
>
> If I apply the hunk on top of Arthur's patch nothing changes and the
> timer testcase starts breaking around ~65000 TSC cycles.
So there are several overlapping issues.
>
> It is a bit problematic that adding printks changes something, so that
> the test starts passing. I haven't tried tracepoints yet.
Yeah, just convert to trace_printk.
>
> Jan, which L1 is using the preemption timer? Any reason why you added
> it?
The one I'm going to present in Edinburgh. Will publish code soon, but
it's unspectacular regard preemption timer usage: I'm only using it to
enforce immediate exits on next vmentry, i.e. set the timer value to 0.
> I wonder if it isn't better to revert it, since it is quite broken.
It's in upstream since 3.10, so reverting doesn't buy us anything, we
need to fix it anyway for long-term stable.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2013-09-27 6:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 8:11 [PATCH v5] KVM: nVMX: Fully support of nested VMX preemption timer Arthur Chunqi Li
2013-09-22 7:47 ` Gleb Natapov
2013-09-25 13:58 ` Paolo Bonzini
2013-09-26 15:04 ` Paolo Bonzini
2013-09-26 17:19 ` Jan Kiszka
2013-09-26 17:47 ` Paolo Bonzini
2013-09-26 20:44 ` Paolo Bonzini
2013-09-27 6:37 ` Jan Kiszka [this message]
2013-09-29 16:24 ` Jan Kiszka
2013-09-29 11:30 ` Gleb Natapov
2013-09-30 9:08 ` Jan Kiszka
2013-10-02 18:47 ` Jan Kiszka
2013-10-10 16:12 ` Jan Kiszka
2013-10-10 16:20 ` Paolo Bonzini
2013-10-25 9:56 ` Paolo Bonzini
2013-10-25 9:59 ` Jan Kiszka
2013-10-11 8:17 ` Arthur Chunqi Li
2013-10-03 8:09 ` Paolo Bonzini
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=5245279A.4090302@web.de \
--to=jan.kiszka@web.de \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yang.z.zhang@intel.com \
--cc=yzt356@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).