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: <d9a5e0e0-3207-e5a6-b7c7-ed59aaf78ebe@kernel.org>
Date:   Mon, 10 Jul 2017 17:13:38 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        X86 ML <x86@...nel.org>
Cc:     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

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:

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.

--Andy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ