mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: yunhong jiang <yunhong.jiang@linux.intel.com>
To: Paolo Bonzini <pbonzini@redhat.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 14:30:11 -0700	[thread overview]
Message-ID: <20160708143011.4837cf86@jnakajim-build> (raw)
In-Reply-To: <0070888f-06b8-db53-3400-5ce8b35c9021@redhat.com>

On Fri, 8 Jul 2016 19:41:48 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> 
> 
> On 08/07/2016 19:29, yunhong jiang wrote:
> > >  
> > >  	exec_control = vmcs12->pin_based_vm_exec_control;
> > > -	exec_control |= vmcs_config.pin_based_exec_ctrl;
> > > +
> > > +	/* Preemption timer setting is only taken from vmcs01.
> > > */ exec_control &= ~PIN_BASED_VMX_PREEMPTION_TIMER;
> >
> > Do we still keep this clear here with followed changes?
> 
> Yes.  If L1 wants to use the preemption timer the bit will be set in
> vmcs12->pin_based_vm_exec_control  In this case, however, KVM uses an
> hrtimer to emulate L1's preemption timer, so we must not copy the bit
> into the vmcs02 (i.e. the VMCS that L0 uses to run L2).  Thus the
> preemption timer control of the vmcs02 must come exclusively from
> vmx->hv_deadline_tsc.

Thanks for the clarification.

> 
> > > +	exec_control |= vmcs_config.pin_based_exec_ctrl;
> > > +	if (vmx->hv_deadline_tsc == -1)
> > > +		exec_control &= ~PIN_BASED_VMX_PREEMPTION_TIMER;
> > >  
> > > +	/* Posted interrupts setting is only taken from vmcs12.
> > > */ if (nested_cpu_has_posted_intr(vmcs12)) {
> > >  		/*
> > >  		 * Note that we use L0's vector here and in
> > > @@ -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.

Thanks
--jyh

> timer vmexit, or because L2 did a HLT and L1 is not intercepting HLT)
> we need to update the preemption timer control to synchronize it with
> vmx->hv_deadline_tsc.
> 
> > I'm not familiar with nested VMX, sorry if this is a naive question.
> 
> It's not naive, don't worry! :)
> 
> Paolo

  reply	other threads:[~2016-07-08 21:34 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 [this message]
2016-07-08 21:39         ` Paolo Bonzini
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=20160708143011.4837cf86@jnakajim-build \
    --to=yunhong.jiang@linux.intel.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=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=yunhong.jiang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®