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
| ||
|
Message-ID: <CANRm+CwwNhZCOn_Cu9UkfZcGNOE=fbdUJnzAKsXcXYdLxBdGMw@mail.gmail.com> Date: Tue, 24 May 2016 15:10:00 +0800 From: Wanpeng Li <kernellwp@...il.com> To: Christian Borntraeger <borntraeger@...ibm.com> Cc: David Matlack <dmatlack@...gle.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, kvm list <kvm@...r.kernel.org>, Wanpeng Li <wanpeng.li@...mail.com>, Paolo Bonzini <pbonzini@...hat.com>, Radim Krčmář <rkrcmar@...hat.com>, Yang Zhang <yang.zhang.wz@...il.com> Subject: Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon 2016-05-24 14:59 GMT+08:00 Christian Borntraeger <borntraeger@...ibm.com>: > On 05/24/2016 04:25 AM, Wanpeng Li wrote: >> 2016-05-24 10:19 GMT+08:00 Wanpeng Li <kernellwp@...il.com>: >>> 2016-05-24 2:01 GMT+08:00 David Matlack <dmatlack@...gle.com>: >>>> On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li <kernellwp@...il.com> wrote: >>>>> From: Wanpeng Li <wanpeng.li@...mail.com> >>>> >>>> I'm ok with this patch, but I'd like to better understand the target >>>> workloads. What type of workloads do you expect to benefit from this? >>> >>> dynticks guests I think is one of workloads which can get benefit, >>> there are lots of upcoming fire timers captured by my feature. Even >>> during TCP testing. And also the workload of Yang's. >> >> Do you think I should add an module parameter to enable/disable it >> during module insmod or current patch is fine? > > What about getting rid of this hunk > > - val = 10000; > + val = halt_poll_ns_base; > > > and then rename "halt_poll_ns_base" into "halt_poll_ns_timer" that > can be changed as module parameter? Good point, > > > I also experimented with an s390 implementation, which seems pretty straightforward. > It is probably something like the following (whitespace damaged due to pcopy/paste) > and needs more testing. > > diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h > index 38bbc98..a97739d 100644 > --- a/arch/s390/include/asm/kvm_host.h > +++ b/arch/s390/include/asm/kvm_host.h > @@ -682,6 +682,7 @@ void kvm_arch_async_page_present(struct kvm_vcpu *vcpu, > struct kvm_async_pf *work); > > extern int sie64a(struct kvm_s390_sie_block *, u64 *); > +extern u64 kvm_s390_timer_remaining(struct kvm_vcpu *vcpu); > extern char sie_exit; > > static inline void kvm_arch_hardware_disable(void) {} > @@ -699,7 +700,7 @@ static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {} > static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {} > static inline u64 kvm_arch_timer_remaining(struct kvm_vcpu *vcpu) > { > - return -1ULL; > + return kvm_s390_timer_remaining(vcpu); > } > > void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu); > diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c > index 5a80af7..5b209a2 100644 > --- a/arch/s390/kvm/interrupt.c > +++ b/arch/s390/kvm/interrupt.c > @@ -936,6 +936,17 @@ static u64 __calculate_sltime(struct kvm_vcpu *vcpu) > return sltime; > } > > + > +u64 kvm_s390_timer_remaining(struct kvm_vcpu *vcpu) > +{ > + u64 result; > + > + preempt_disable(); > + result = __calculate_sltime(vcpu); > + preempt_enable(); > + return result; > +} > + > int kvm_s390_handle_wait(struct kvm_vcpu *vcpu) > { > u64 sltime; > -- Regards, Wanpeng Li
Powered by blists - more mailing lists