From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B75CC433DB for ; Tue, 23 Mar 2021 18:38:09 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F16E061963 for ; Tue, 23 Mar 2021 18:38:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F16E061963 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:Cc:To: From:Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ezqvsgS36iQJ1YccBl9I8hPxF9FNv7iVKjnK8YT2KhU=; b=UDgLSuhc1FngylAtsgPBXUC2W 9tZ/+2HR/mqxiU5WZk1wSoSHKDDFRo81ZRQqGspM61HJngayn9j8xoKVRx27NCbo9adXsnTIUwfJO VobUHjZMXtJ1XsiCFb3i1zz4WKQpboawrRq66QVaKaXv4pcRT+ApsvRZx/toBd6QsnuNiS6znsO52 qd+rDBH+r4U35uWc84qVrdlQlOTaRVB5oUV9O/Yt3vXnLlVuAOBbMaulJzQrXjbfoqEdaOrU0tJu8 xnJA/G47hbYtHtVkVI+G7UB49wT2BxbLKS051bkTcYEVHv35PNzlMvFSPH0CpBsrN4+iBIwQ1XrlK r3UVTKhcg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lOltT-00FX25-KR; Tue, 23 Mar 2021 18:36:43 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lOltO-00FX1K-Qv for linux-arm-kernel@lists.infradead.org; Tue, 23 Mar 2021 18:36:40 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DB8D461963; Tue, 23 Mar 2021 18:36:33 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lOltH-003MqI-UI; Tue, 23 Mar 2021 18:36:32 +0000 Date: Tue, 23 Mar 2021 18:36:31 +0000 Message-ID: <87ft0lk98w.wl-maz@kernel.org> From: Marc Zyngier To: Yoan Picchi Cc: james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, catalin.marinas@arm.com, will@kernel.org Subject: Re: [PATCH 7/7] KVM: arm64: Add irq_inject counter for kvm_stat In-Reply-To: References: <20210319161711.24972-1-yoan.picchi@arm.com> <20210319161711.24972-8-yoan.picchi@arm.com> <87lfadkbyz.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: yoan.picchi@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, catalin.marinas@arm.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210323_183639_232990_19E7EA48 X-CRM114-Status: GOOD ( 27.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 23 Mar 2021 17:53:42 +0000, Yoan Picchi wrote: > > Hi Mark. s/k/c/, please! > > Thanks for all the reviews. I am a beginner and you gave me a lot to > learn about. I will reply to the other patch progressively once I > understand better the issues. I think you should consider what I said in my reply to the cover letter before going all out on every counter you have introduced in this series. [...] > >> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c > >> index 1c597c988..9e504243b 100644 > >> --- a/arch/arm64/kvm/vgic/vgic.c > >> +++ b/arch/arm64/kvm/vgic/vgic.c > >> @@ -458,6 +458,8 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid, > >> raw_spin_lock_irqsave(&irq->irq_lock, flags); > >> + kvm->stat.irq_inject++; > >> + > >> if (!vgic_validate_injection(irq, level, owner)) { > > So even if the injection failed, you report an injection? And what > > about injection that occur via the MMIO interface? What about direct > > injection? What about a level interrupt that is forever high? > > > > M. > > > This one I actually started to fix this afternoon by moving the > counter into vgic_queue_irq_unlock(). This way it is only > incremented when the interrupt is inserted into a vcpu, and it also > takes care of the vgic_mmio injections. I also fixed the issue with > the interrupt line so it only increment when the line change of > level. But if you do that, you start counting interrupts the guest itself generates. What is the exact semantic of this counter? userspace injected interrupts? Acked interrupts? Any interrupt? Take my level interrupt example. The interrupt will be forever pending, the guest will take as many interrupt as it can process, and yet your counter will have been incremented *once*. What does your counter mean then? > I'm not sure about what you mean by direct injection yet though. GICv4.{0,1}, where an interrupt gets directly delivered to the guest without (too much) SW intervention. With this, directly injected LPIs will never result in the counter being incremented, and yet can pin the guest to the ground under interrupt load. Again, defining the exact behaviour of the counter would avoid me ranting away... M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel