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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 B8945C2D0C0 for ; Sun, 22 Dec 2019 11:24:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B6BB208C3 for ; Sun, 22 Dec 2019 11:24:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1577013862; bh=s/P9uI0VwTvGyMNCo3mOf06aSHq63arnkciTbL8Y6XA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=hYD5FKfNsVzHwAfAF3s/oR6ooHZm/NTM+vjBaibNxumgRRwDfUEzy3WqkgZfScNxR Wg7Nz9IpxJ3VRzuIJegSRNQK9BgNhnruXJSAWnJXBnZidooen8vXvz4vyfvISYyU+Z lAMxa+9qZAOyTNTFq9a3rbeiAq12bed7pwDo0iUI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726267AbfLVLYT (ORCPT ); Sun, 22 Dec 2019 06:24:19 -0500 Received: from inca-roads.misterjones.org ([213.251.177.50]:42757 "EHLO inca-roads.misterjones.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725977AbfLVLYT (ORCPT ); Sun, 22 Dec 2019 06:24:19 -0500 Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=big-swifty.misterjones.org) by cheepnis.misterjones.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.80) (envelope-from ) id 1iizLM-0006ag-LE; Sun, 22 Dec 2019 12:24:17 +0100 Date: Sun, 22 Dec 2019 11:24:13 +0000 Message-ID: <868sn4iowy.wl-maz@kernel.org> From: Marc Zyngier To: Andrew Murray Cc: Catalin Marinas , Will Deacon , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Sudeep Holla , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 13/18] perf: arm_spe: Add KVM structure for obtaining IRQ info In-Reply-To: <20191220143025.33853-14-andrew.murray@arm.com> References: <20191220143025.33853-1-andrew.murray@arm.com> <20191220143025.33853-14-andrew.murray@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-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: 62.31.163.78 X-SA-Exim-Rcpt-To: andrew.murray@arm.com, catalin.marinas@arm.com, will@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, 20 Dec 2019 14:30:20 +0000, Andrew Murray wrote: > > KVM requires knowledge of the physical SPE IRQ number such that it can > associate it with any virtual IRQ for guests that require SPE emulation. This is at best extremely odd. The only reason for KVM to obtain this IRQ number is if it has exclusive access to the device. This obviously isn't the case, as this device is shared between host and guest. > Let's create a structure to hold this information and an accessor that > KVM can use to retrieve this information. > > We expect that each SPE device will have the same physical PPI number > and thus will warn when this is not the case. > > Signed-off-by: Andrew Murray > --- > drivers/perf/arm_spe_pmu.c | 23 +++++++++++++++++++++++ > include/kvm/arm_spe.h | 6 ++++++ > 2 files changed, 29 insertions(+) > > diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c > index 4e4984a55cd1..2d24af4cfcab 100644 > --- a/drivers/perf/arm_spe_pmu.c > +++ b/drivers/perf/arm_spe_pmu.c > @@ -34,6 +34,9 @@ > #include > #include > > +#include > +#include > + > #include > #include > #include > @@ -1127,6 +1130,24 @@ static void arm_spe_pmu_dev_teardown(struct arm_spe_pmu *spe_pmu) > free_percpu_irq(spe_pmu->irq, spe_pmu->handle); > } > > +#ifdef CONFIG_KVM_ARM_SPE > +static struct arm_spe_kvm_info arm_spe_kvm_info; > + > +struct arm_spe_kvm_info *arm_spe_get_kvm_info(void) > +{ > + return &arm_spe_kvm_info; > +} How does this work when SPE is built as a module? > + > +static void arm_spe_populate_kvm_info(struct arm_spe_pmu *spe_pmu) > +{ > + WARN_ON_ONCE(arm_spe_kvm_info.physical_irq != 0 && > + arm_spe_kvm_info.physical_irq != spe_pmu->irq); > + arm_spe_kvm_info.physical_irq = spe_pmu->irq; What does 'physical' means here? It's an IRQ in the Linux sense, so it's already some random number that bears no relation to anything 'physical'. > +} > +#else > +static void arm_spe_populate_kvm_info(struct arm_spe_pmu *spe_pmu) {} > +#endif > + > /* Driver and device probing */ > static int arm_spe_pmu_irq_probe(struct arm_spe_pmu *spe_pmu) > { > @@ -1149,6 +1170,8 @@ static int arm_spe_pmu_irq_probe(struct arm_spe_pmu *spe_pmu) > } > > spe_pmu->irq = irq; > + arm_spe_populate_kvm_info(spe_pmu); > + > return 0; > } > > diff --git a/include/kvm/arm_spe.h b/include/kvm/arm_spe.h > index d1f3c564dfd0..9c65130d726d 100644 > --- a/include/kvm/arm_spe.h > +++ b/include/kvm/arm_spe.h > @@ -17,6 +17,12 @@ struct kvm_spe { > bool irq_level; > }; > > +struct arm_spe_kvm_info { > + int physical_irq; > +}; > + > +struct arm_spe_kvm_info *arm_spe_get_kvm_info(void); > + > #ifdef CONFIG_KVM_ARM_SPE > #define kvm_arm_spe_v1_ready(v) ((v)->arch.spe.ready) > #define kvm_arm_spe_irq_initialized(v) \ M. -- Jazz is not dead, it just smells funny.