lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160706080901.ywlvgksrhpdyspmv@hz-desktop>
Date:	Wed, 6 Jul 2016 16:09:01 +0800
From:	Haozhong Zhang <haozhong.zhang@...el.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Wanpeng Li <kernellwp@...il.com>, kvm <kvm@...r.kernel.org>,
	Radim Krcmar <rkrcmar@...hat.com>,
	Yunhong Jiang <yunhong.jiang@...el.com>,
	Wanpeng Li <wanpeng.li@...mail.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jan Kiszka <jan.kiszka@...mens.com>
Subject: Re: [PATCH] KVM: VMX: switch to hrtimer for TSC deadline timer when
 L2 guest is running

On 07/06/16 16:01, Haozhong Zhang wrote:
> On 07/06/16 09:46, Paolo Bonzini wrote:
> > 
> > 
> > On 06/07/2016 08:05, Haozhong Zhang wrote:
> > >> > 
> > >> > Nested preemption timer is emulated by hrtimer, so it doesn't
> > >> > influence vmcs02, why this is needed?
> > > Nested (L2) preemption timer is not affected for sure, and this patch
> > > is to fix another problem caused by using L1 preemption timer for L1
> > > TSC deadline timer. When we use L1 VMX preemption timer for L1 TSC
> > > deadline timer, we intend to use the pin-based exec config and the VMX
> > > preemption timer value in vmcs01. However, when L2 guest is running,
> > > vmcs02 is loaded as the current VMCS so that a different VMX
> > > preemption timer config is used (i.e. VMX preemption timer is disabled
> > > in prepare_vmcs02()). If we still use preemption timer for L1 TSC
> > > deadline timer at this moment, then L1 TSC deadline timer will not be
> > > able to be triggered when L2 guest is running.
> > 
> > The right fix then is to set the pin-based controls in prepare_vmcs02,
> > based on vcpu->arch.hv_deadline_tsc.
> 
> Then KVM needs to distinguish L1 and L2 VMEXITs for preemption timer
> (or does KVM already have this?). The current implementation which
> uses a separate hrtimer for L2 preemption timer can easily distinguish
> them.
> 

And L1 hypervisor may also want to use preemption timer for L2
guest. In this case, L0 KVM can not reuse preemption timer for both L1
and L2.

Haozhong

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ