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]
Date:   Tue, 11 Jul 2017 10:43:54 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kvm <kvm@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>,
        X86 ML <x86@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Yunhong Jiang <yunhong.jiang@...el.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH RFC 0/2] KVM: x86: Support using the VMX preemption timer
 for APIC Timer periodic/oneshot mode

2017-07-11 8:13 GMT+08:00 Andy Lutomirski <luto@...nel.org>:
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ