Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7563917ybl; Tue, 24 Dec 2019 04:57:57 -0800 (PST) X-Google-Smtp-Source: APXvYqxx2bodu16PoRyUxlKdEcoQ5WRg6vqeNUf/lB+EKMHrOt001wt71GXtn5Elxo0+Xg+Xwok1 X-Received: by 2002:a9d:3f61:: with SMTP id m88mr22871561otc.56.1577192277175; Tue, 24 Dec 2019 04:57:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577192277; cv=none; d=google.com; s=arc-20160816; b=AL0wrCfhuGp3XljegDE92MY3rYOHh5G7uTQyItBq9BbsxF8ERZIbRS3QpbmB0SZ7dZ YagYr3PNqC++s+u9oYLgZkGQ0BYj+piXgCdGBY0mtnkKh6zVrUOUIznxAEt2gk8tYVl8 JcQEZqH53KtJc3AEmFZf4DcYVFJPavHL0iGXIrktUU/YMhkSnXkuxfrnal7n8klSKyEN hrtmEEsGCSQaYdw8ThMrfQduhGfDhtPjdb9fRXvkQ2Kamww7WwbBx/9GA51WMO5ltgEH JQpq87ncUm2VbVJ5rUmBKWPm1AWRmsyN+0AMmEsdDm8ZpmlivTFoY21tvPTrZpJ0ZHQ+ EOBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=dvERP6lsufQNgGj1FDAIin8fr84KwWIXn2Wp2HavORs=; b=fyyRFfeWcur8BSm1ED44ksBNJ7b1+CCemMFS+iZvrUBChl25+LcT2lK/FAGz4Y2pgG 50Zhhac7vwQQ4bq2P6HWymNir9gKLwLc2VSTVY8EdXErMrq7d+2Mpg9O+IT9pvl/kvTt 3tpeyjCdeHXc7/TZaGBPSW5B0WtGB5e/BrFmbpSTSWDGKHoE9WQn4ZJnPGWtXqMKF7hb YjgtK71ggzBWH8SBDFCEpIOEGzHf7PPJJM8UMe9t5wPuz6IoYddGm8Rg52GggEHlm5sh uG3BsYuB5g9ZSjP2KSCdqVjn5/VTQcxsgfreaWKFHcJ0mmSxPnXVnrHUiXkFT3IRxKHG +mmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w9si12205325otl.138.2019.12.24.04.57.45; Tue, 24 Dec 2019 04:57:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726853AbfLXM4z (ORCPT + 99 others); Tue, 24 Dec 2019 07:56:55 -0500 Received: from foss.arm.com ([217.140.110.172]:51938 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726157AbfLXM4y (ORCPT ); Tue, 24 Dec 2019 07:56:54 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CC4991FB; Tue, 24 Dec 2019 04:56:53 -0800 (PST) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 446093F534; Tue, 24 Dec 2019 04:56:53 -0800 (PST) Date: Tue, 24 Dec 2019 12:56:51 +0000 From: Andrew Murray To: Marc Zyngier Cc: kvm@vger.kernel.org, Catalin Marinas , linux-kernel@vger.kernel.org, Sudeep Holla , will@kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 00/18] arm64: KVM: add SPE profiling support Message-ID: <20191224125651.GM42593@e119886-lin.cambridge.arm.com> References: <20191220143025.33853-1-andrew.murray@arm.com> <864kxsim8d.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <864kxsim8d.wl-maz@kernel.org> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 22, 2019 at 12:22:10PM +0000, Marc Zyngier wrote: > On Sat, 21 Dec 2019 10:48:16 +0000, > Marc Zyngier wrote: > > > > [fixing email addresses] > > > > Hi Andrew, > > > > On 2019-12-20 14:30, Andrew Murray wrote: > > > This series implements support for allowing KVM guests to use the Arm > > > Statistical Profiling Extension (SPE). > > > > Thanks for this. In future, please Cc me and Will on email addresses > > we can actually read. > > > > > It has been tested on a model to ensure that both host and guest can > > > simultaneously use SPE with valid data. E.g. > > > > > > $ perf record -e arm_spe/ts_enable=1,pa_enable=1,pct_enable=1/ \ > > > dd if=/dev/zero of=/dev/null count=1000 > > > $ perf report --dump-raw-trace > spe_buf.txt > > > > > > As we save and restore the SPE context, the guest can access the SPE > > > registers directly, thus in this version of the series we remove the > > > trapping and emulation. > > > > > > In the previous series of this support, when KVM SPE isn't > > > supported (e.g. via CONFIG_KVM_ARM_SPE) we were able to return a > > > value of 0 to all reads of the SPE registers - as we can no longer > > > do this there isn't a mechanism to prevent the guest from using > > > SPE - thus I'm keen for feedback on the best way of resolving > > > this. > > > > Surely there is a way to conditionally trap SPE registers, right? You > > should still be able to do this if SPE is not configured for a given > > guest (as we do for other feature such as PtrAuth). > > > > > It appears necessary to pin the entire guest memory in order to > > > provide guest SPE access - otherwise it is possible for the guest > > > to receive Stage-2 faults. > > > > Really? How can the guest receive a stage-2 fault? This doesn't fit > > what I understand of the ARMv8 exception model. Or do you mean a SPE > > interrupt describing a S2 fault? Yes the latter. > > > > And this is not just pinning the memory either. You have to ensure that > > all S2 page tables are created ahead of SPE being able to DMA to guest > > memory. This may have some impacts on the THP code... > > > > I'll have a look at the actual series ASAP (but that's not very soon). > > I found some time to go through the series, and there is clearly a lot > of work left to do: > > - There so nothing here to handle memory pinning whatsoever. If it > works, it is only thanks to some side effect. > > - The missing trapping is deeply worrying. Given that this is an > optional feature, you cannot just let the guest do whatever it wants > in an uncontrolled manner. Yes I'll add this. > > - The interrupt handling is busted. You mix concepts picked from both > the PMU and the timer code, while the SPE device doesn't behave like > any of these two (it is neither a fully emulated device, nor a > device that is exclusively owned by a guest at any given time). > > I expect some level of discussion on the list including at least Will > and myself before you respin this. Thanks for the quick feedback. Andrew Murray > > M. > > -- > Jazz is not dead, it just smells funny.