Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp328360pxb; Sat, 21 Aug 2021 03:59:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKvSOEhpjuT0GAz4C5wq71nnpcW+c8H8tElhWfctlzGuf2AaxBixqav+UbNMCbIeTQjVXI X-Received: by 2002:a05:6e02:78d:: with SMTP id q13mr16974376ils.262.1629543569932; Sat, 21 Aug 2021 03:59:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629543569; cv=none; d=google.com; s=arc-20160816; b=k98uRiZrPUWFGRIApF78tzIyHszEVwESahhpsaemd/WxUKTbnJyNHPD1IKl9JdVzEx fY10PKp/q1G/89luNvVeCBhBETX+LOfvugAR4BovkwzibwUhJWLUpV3KC4jQxqxK4aL9 1TGJNrMs6vuAxVq3fRDzstLtupPNSCFVAmaG+gJPAHo2hlDxaONpBe49gkftuy+Q0qGC SBucwmeinUd8T0axXX2+A/Y4521VBi/GYPXDZGkQ87INbZSjQoPZ/BRHfacEBd2HVzP7 eQVMB6ZMQbz+CDNwuFWLe4QOkP/rIHTis+CeNZFH6ZA7lGCCV7OdDxjAxaG5z6EHK38w 4/mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=FetVRtt027wb2E/9XQuQ4O6kG6d1krNbnVpMXWxTFTQ=; b=fPTO49SBg/F6ML4XDpiIycYLy/F4jXkYNYFcF6YmJobNRL7ASAfnHwre+DTuu47UB5 xsEgjglQYqHb9ZS4W5vAFWL1LpQd0DMYIcMFfZpxavEiwyUMNZ9eIZ7uUZdRJ++PLrQr mIIsLBQdFtPCPCTzMFnqs0auamzbGXqyML+wV0arW9IyE1jakU4vJXgSDKldsWl/hmbN XXH4gyz9Q6QfTjgHKEoEMR1M704BEKFVHELrBv4YDAWkxSq+tVsEe6eGK5g+6L5Gx81f LsqRub/KsO9P3ZVQrZ6QZw5B6+yDyltPiC2U8wiL74G1HcYjvVkfShgqJoB6Eqn240W+ vTXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d12si10209981ilg.105.2021.08.21.03.59.10; Sat, 21 Aug 2021 03:59:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234096AbhHUK52 (ORCPT + 99 others); Sat, 21 Aug 2021 06:57:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:38150 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229968AbhHUK51 (ORCPT ); Sat, 21 Aug 2021 06:57:27 -0400 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 92BB16113E; Sat, 21 Aug 2021 10:56:48 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mHOgA-006MEI-Gc; Sat, 21 Aug 2021 11:56:46 +0100 Date: Sat, 21 Aug 2021 11:56:46 +0100 Message-ID: <875yvzqd5d.wl-maz@kernel.org> From: Marc Zyngier To: Raghavendra Rao Ananta Cc: Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Oliver Upton , Reiji Watanabe , Jing Zhang , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Ratelimit error log during guest debug exception In-Reply-To: References: <20210819223406.1132426-1-rananta@google.com> <87sfz4qx9r.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") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: rananta@google.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, pshier@google.com, ricarkol@google.com, oupton@google.com, reijiw@google.com, jingzhangos@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 21 Aug 2021 00:01:24 +0100, Raghavendra Rao Ananta wrote: > > [1 ] > On Fri, Aug 20, 2021 at 2:29 AM Marc Zyngier wrote: > > > > On Thu, 19 Aug 2021 23:34:06 +0100, > > Raghavendra Rao Ananta wrote: > > > > > > Potentially, the guests could trigger a debug exception that's > > > outside the exception class range. > > > > How? All the exception classes that lead to this functions are already > > handled in the switch/case statement. > > > I guess I didn't think this through. Landing into kvm_handle_guest_debug() > itself is not possible :) Exactly. > > My take on this is that this code isn't reachable, and that it could > > be better rewritten as: > > > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > > index 6f48336b1d86..ae7ec086827b 100644 > > --- a/arch/arm64/kvm/handle_exit.c > > +++ b/arch/arm64/kvm/handle_exit.c > > @@ -119,28 +119,14 @@ static int kvm_handle_guest_debug(struct kvm_vcpu > *vcpu) > > { > > struct kvm_run *run = vcpu->run; > > u32 esr = kvm_vcpu_get_esr(vcpu); > > - int ret = 0; > > > > run->exit_reason = KVM_EXIT_DEBUG; > > run->debug.arch.hsr = esr; > > > > - switch (ESR_ELx_EC(esr)) { > > - case ESR_ELx_EC_WATCHPT_LOW: > > + if (ESR_ELx_EC(esr) == ESR_ELx_EC_WATCHPT_LOW) > > run->debug.arch.far = vcpu->arch.fault.far_el2; > > - fallthrough; > > - case ESR_ELx_EC_SOFTSTP_LOW: > > - case ESR_ELx_EC_BREAKPT_LOW: > > - case ESR_ELx_EC_BKPT32: > > - case ESR_ELx_EC_BRK64: > > - break; > > - default: > > - kvm_err("%s: un-handled case esr: %#08x\n", > > - __func__, (unsigned int) esr); > > - ret = -1; > > - break; > > - } > > > > - return ret; > > + return 0; > > } > > > This looks better, but do you think we would be compromising on readability? I don't think so. The exit handler table is, on its own, pretty explicit about what we route to this handler, and the comment above the function clearly states that we exit to userspace for all the debug ECs. M. -- Without deviation from the norm, progress is not possible.