From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13E112F4321; Thu, 12 Jun 2025 11:59:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749729552; cv=none; b=VOJDk/rmIpZOnsNTaaIQadCZq9UpfJogZBWBTtw+hSIYpW+iOm4Uilze1hjYNVzDKKgmkmaIJUBxT6ifo0YtRT2+bAsMQseN2s3r02eYFB1tPyZ9jSWH8ohe4+ouge220eM8S+IKXbHp8hh/W1geiPvfjjhYJEM3NbW/V8q+kJ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749729552; c=relaxed/simple; bh=KwyfDAOUs8iXdBHsahZWDUxixFdgjL8coSsHcLU1FFc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Wp9mSU0/d4Lkx4d4X5xxqgiVaqzgEugFWBkS5L3rCgShiqzpJaBr1EWVZRo7HuNMRZYCX4DYllh76hXfIRVjLMmKlfCuNCp/EEdTORjMDX9MMUZkrpGzbF1T3K6z+tjHB9hgIf8EFB+Ugt8BTqwneCD20nJypoa/ajhR93jWn4I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hi8Tjgl5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hi8Tjgl5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91F7FC4CEEA; Thu, 12 Jun 2025 11:59:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749729551; bh=KwyfDAOUs8iXdBHsahZWDUxixFdgjL8coSsHcLU1FFc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hi8Tjgl5Xk3icFuGpyYyDFFfVzg1ypgjAOS3N0mkSgrnF2K7AqIzQ1hcEQ9AAF0Se wXOULqH4zKeq3IryH+iTq5zP4QmQQWG+nOXAxa5CzOtW7yF3B2CSnta4oHJ5VPSbXZ 17M6EUqQxkdp1qahy6SGN7OtNxJjEURyTpnGpZW7fnJWROTU0ve0kQPcyfANXs+vsa KP02ehjxy8WL9vP1SkJlesd9a/S1Q38qpVASTJgMBbNnxWoEvNFEooPWDZL7GCEjmM stO8RHsQ64JVC4Taq0CdWHVwI5oq4MZ5jTHaF0pQTt/n9ZIk0cBgtPg8Gcn00DGI2Z GxUPwzKoSNvhw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uPgaL-006E7f-55; Thu, 12 Jun 2025 12:59:09 +0100 Date: Thu, 12 Jun 2025 12:59:08 +0100 Message-ID: <86tt4lcgs3.wl-maz@kernel.org> From: Marc Zyngier To: Sean Christopherson Cc: Oliver Upton , Paolo Bonzini , Joerg Roedel , David Woodhouse , Lu Baolu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Sairaj Kodilkar , Vasant Hegde , Maxim Levitsky , Joao Martins , Francesco Lavra , David Matlack Subject: Re: [PATCH v3 02/62] KVM: arm64: WARN if unmapping vLPI fails In-Reply-To: <20250611224604.313496-4-seanjc@google.com> References: <20250611224604.313496-2-seanjc@google.com> <20250611224604.313496-4-seanjc@google.com> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: seanjc@google.com, oliver.upton@linux.dev, pbonzini@redhat.com, joro@8bytes.org, dwmw2@infradead.org, baolu.lu@linux.intel.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, sarunkod@amd.com, vasant.hegde@amd.com, mlevitsk@redhat.com, joao.m.martins@oracle.com, francescolavra.fl@gmail.com, dmatlack@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 11 Jun 2025 23:45:05 +0100, Sean Christopherson wrote: > > WARN if unmapping a vLPI in kvm_vgic_v4_unset_forwarding() fails, as > failure means an IRTE has likely been left in a bad state, i.e. IRQs > won't go where they should. I have no idea what an IRTE is. But not having an VLPI mapping for an interrupt at the point where we're tearing down the forwarding is pretty benign. IRQs *still* go where they should, and we don't lose anything. What it may mean is that userspace and the guest may have done things in the wrong order for KVM to accelerate interrupt delivery. That's silly, but also completely harmless. M. -- Without deviation from the norm, progress is not possible.