From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f170.google.com ([209.85.192.170]:34243 "EHLO mail-pd0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751087AbbGBEGT (ORCPT ); Thu, 2 Jul 2015 00:06:19 -0400 Received: by pdbep18 with SMTP id ep18so37266709pdb.1 for ; Wed, 01 Jul 2015 21:06:19 -0700 (PDT) Message-ID: <5594B8B5.1040103@linaro.org> Date: Thu, 02 Jul 2015 12:06:13 +0800 From: Shannon Zhao MIME-Version: 1.0 To: Greg KH CC: stable@vger.kernel.org, christoffer.dall@linaro.org Subject: Re: [PATCH for 3.14.y stable 18/22] arm/arm64: KVM: Require in-kernel vgic for the arch timers References: <1435661350-8060-1-git-send-email-shannon.zhao@linaro.org> <1435661350-8060-19-git-send-email-shannon.zhao@linaro.org> <20150701183647.GA1873@kroah.com> In-Reply-To: <20150701183647.GA1873@kroah.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 2015/7/2 2:36, Greg KH wrote: > On Tue, Jun 30, 2015 at 06:49:06PM +0800, shannon.zhao@linaro.org wrote: >> From: Christoffer Dall >> >> commit 05971120fca43e0357789a14b3386bb56eef2201 upstream. >> >> It is curently possible to run a VM with architected timers support >> without creating an in-kernel VGIC, which will result in interrupts from >> the virtual timer going nowhere. >> >> To address this issue, move the architected timers initialization to the >> time when we run a VCPU for the first time, and then only initialize >> (and enable) the architected timers if we have a properly created and >> initialized in-kernel VGIC. >> >> When injecting interrupts from the virtual timer to the vgic, the >> current setup should ensure that this never calls an on-demand init of >> the VGIC, which is the only call path that could return an error from >> kvm_vgic_inject_irq(), so capture the return value and raise a warning >> if there's an error there. >> >> We also change the kvm_timer_init() function from returning an int to be >> a void function, since the function always succeeds. >> >> Reviewed-by: Marc Zyngier >> Signed-off-by: Christoffer Dall >> Signed-off-by: Shannon Zhao > > {sigh} > > You modified this patch and didn't say you modified it, despite me > asking you to do so. I don't think so. If you really have a look at this patch, you should recognize that this patch is doing the same thing as the original patch does. > Why should I trust that the other patches you sent Trust? Don't say that please. I never felt your trust even from the beginning of this backport. > weren't also modified? > > Ugh. I've stopped here in the series, and I'm really annoyed at this > whole series and just how long it's taken to get this right for a > feature that almost no one cares about... > > greg k-h > -- Shannon