All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: yunhong jiang <yunhong.jiang@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	"Wanpeng Li" <kernellwp@gmail.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Yunhong Jiang" <yunhong.jiang@intel.com>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Haozhong Zhang" <haozhong.zhang@intel.com>
Subject: Re: [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution
Date: Fri, 8 Jul 2016 17:39:22 -0400 (EDT)	[thread overview]
Message-ID: <450057441.5389401.1468013962741.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20160708143011.4837cf86@jnakajim-build>

> > > > @@ -10727,8 +10732,14 @@ static void nested_vmx_vmexit(struct
> > > > kvm_vcpu *vcpu, u32 exit_reason,
> > > >  	load_vmcs12_host_state(vcpu, vmcs12);
> > > >  
> > > > -	/* Update TSC_OFFSET if TSC was changed while L2 ran */
> > > > +	/* Update any VMCS fields that might have changed while
> > > > L2 ran */ vmcs_write64(TSC_OFFSET, vmx->nested.vmcs01_tsc_offset);
> > > > +	if (vmx->hv_deadline_tsc == -1)
> > > > +		vmcs_clear_bits(PIN_BASED_VM_EXEC_CONTROL,
> > > > +				PIN_BASED_VMX_PREEMPTION_TIMER);
> > > > +	else
> > > > +		vmcs_set_bits(PIN_BASED_VM_EXEC_CONTROL,
> > > > +			      PIN_BASED_VMX_PREEMPTION_TIMER);
> > >
> > > Why do we need change the vmcs01 here? Per my understanding, the
> > > vmcs01 is not changed when the L2 guest is running thus the
> > > PIN_BASED_VM_EXEC_CONTROL should not be changed?
> > 
> > This is the point where we are updating the vmcs01 after exiting.  If
> > vmx->hv_deadline_tsc has changed (for example because of a preemption
> 
> Thanks for the explaination. I try to go through the code and still
> have one question. I'd describe below and hope get your input.
> 
> When the L2 guest running while the VMX Preemption timer triggered, the
> vcpu_enter_guest() will trigger vmx_handle_exit(), with the CPU vmcs as
> vmcs02. On the vmx_handle_exit(), the nested_vmx_exit_handled() return
> false as the 1st patch did, thus the vmcs is not switched. The
> kvm_lapic_expired_hv_timer() will be called with vmcs02, instead of
> vmcs01. Is it something we wanted? I assume we should use vmcs01 there
> since we will clear the preemption timer VMCS bit there.

Actually we want both.  For whatever reason, the interrupt might not
cause a vmexit---for example if the L0 PPR is masking the LVTT vector.
In this case, we need to cancel the preemption timer in the vmcs02
(done by kvm_lapic_expired_hv_timer) and keep running L2.  On the next
vmexit, nested_vmx_vmexit will load the vmcs01 and clear the preemption
timer bit.

Of course this is only theory until Wanpeng confirms that my patch works
for him. :)

Paolo

  reply	other threads:[~2016-07-08 21:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08 12:02 [RFT PATCH v5 0/3] Fix preemption timer optimization while nested guests run Paolo Bonzini
2016-07-08 12:02 ` [RFT PATCH v5 1/3] KVM: nVMX: avoid incorrect preemption timer vmexit in nested guest Paolo Bonzini
2016-07-08 12:02 ` [RFT PATCH v5 2/3] KVM: VMX: reflect broken preemption timer in vmcs_config Paolo Bonzini
2016-07-08 12:02 ` [RFT PATCH v5 3/3] KVM: nVMX: keep preemption timer enabled during L2 execution Paolo Bonzini
2016-07-08 17:29   ` yunhong jiang
2016-07-08 17:41     ` Paolo Bonzini
2016-07-08 21:30       ` yunhong jiang
2016-07-08 21:39         ` Paolo Bonzini [this message]
2016-07-08 23:18           ` yunhong jiang
2016-07-11  4:56 ` [RFT PATCH v5 0/3] Fix preemption timer optimization while nested guests run Wanpeng Li
2016-07-11  7:29   ` 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=450057441.5389401.1468013962741.JavaMail.zimbra@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=haozhong.zhang@intel.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kernellwp@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rkrcmar@redhat.com \
    --cc=yunhong.jiang@intel.com \
    --cc=yunhong.jiang@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.