Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755202AbdGKCo0 (ORCPT ); Mon, 10 Jul 2017 22:44:26 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:33533 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755161AbdGKCoY (ORCPT ); Mon, 10 Jul 2017 22:44:24 -0400 MIME-Version: 1.0 In-Reply-To: References: <1476188240-3502-1-git-send-email-wanpeng.li@hotmail.com> From: Wanpeng Li Date: Tue, 11 Jul 2017 10:43:54 +0800 Message-ID: Subject: Re: [PATCH RFC 0/2] KVM: x86: Support using the VMX preemption timer for APIC Timer periodic/oneshot mode To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , kvm , Thomas Gleixner , X86 ML , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Yunhong Jiang , Wanpeng Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2982 Lines: 81 2017-07-11 8:13 GMT+08:00 Andy Lutomirski : > On 10/11/2016 05:17 AM, Wanpeng Li wrote: >> >> Most windows guests which I have on hand currently still utilize APIC >> Timer >> periodic/oneshot mode instead of APIC Timer tsc-deadline mode: >> - windows 2008 server r2 >> - windows 2012 server r2 >> - windows 7 >> - windows 10 >> >> This patchset adds the support using the VMX preemption timer for APIC >> Timer >> periodic/oneshot mode. >> >> I add a print in oneshot mode testcase of kvm-unit-tests/apic.flat and >> observed >> that w/ patch the latency is ~2% of w/o patch. I think maybe something is >> still >> not right in the patchset, in addition, tmcct in apic_get_tmcct() maybe is >> not >> calculated correctly. Your comments to improve the patchset is a great >> appreciated. >> >> Wanpeng Li (2): >> KVM: lapic: Extract start_sw_period() to handle oneshot/periodic mode >> KVM: x86: Support using the vmx preemption timer for APIC Timer >> periodic/one mode >> >> arch/x86/kvm/lapic.c | 162 >> ++++++++++++++++++++++++++++++--------------------- >> 1 file changed, 95 insertions(+), 67 deletions(-) >> > > I think this is a step in the right direction, but I think there's a > different approach that would be much, much faster: use the VMX preemption > timer for *host* preemption. Specifically, do this: Yeah, I agreed. > > 1. Refactor the host TSC deadline timer a bit to allow the TSC deadline > timer to be "borrow". It might look something like this: > > u64 borrow_tsc_deadline(void (*timer_callback)()); > > The caller is now permitted to use the TSC deadline timer for its own > nefarious purposes. The caller promises to call return_tsc_deadline() in a > timely manner if the TSC exceeds the return value while the deadline timer > is borrowed. > > If the TSC deadline fires while it's borrowed, timer_callback() will be > called. > > void return_tsc_deadline(bool timer_fired); > > The caller is done borrowing the TSC deadline timer. The caller need not > reset the TSC deadline timer MSR to its previous value before calling this. > It must be called with IRQs on and preemption off. > > Getting this to work cleanly without races may be a bit tricky. So be it. > > 2. Teach KVM to use the VMX preemption timer as a substitute deadline timer > while in guest mode. Specifically, KVM will borrow_tsc_deadline() (if TSC > deadline is enabled) when entering guest mode and return_tsc_deadline() when > returning out of guest mode. > > 3. Now KVM can change its MSR bitmaps to allow the guest to program the TSC > deadline MSR directly. No exit at all needed to handle guest writes to the > deadline timer. > > > Tglx, etc, would this be even remotely acceptable? I'm not personally > touching this code with a ten-foot pole, but there seem to be plenty of > people who really care about performance here. Sigh, I heard the same idea from a company called Huawei, they applied the patent for the idea. Regard, Wanpeng Li