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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 E5F9EC43603 for ; Fri, 20 Dec 2019 17:55:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C5ADC206C3 for ; Fri, 20 Dec 2019 17:55:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727492AbfLTRz3 (ORCPT ); Fri, 20 Dec 2019 12:55:29 -0500 Received: from foss.arm.com ([217.140.110.172]:53762 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727421AbfLTRz2 (ORCPT ); Fri, 20 Dec 2019 12:55:28 -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 619A01FB; Fri, 20 Dec 2019 09:55:28 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D2C13F67D; Fri, 20 Dec 2019 09:55:27 -0800 (PST) Date: Fri, 20 Dec 2019 17:55:25 +0000 From: Mark Rutland To: Andrew Murray Cc: Marc Zyngier , Catalin Marinas , Will Deacon , Sudeep Holla , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 00/18] arm64: KVM: add SPE profiling support Message-ID: <20191220175524.GC25258@lakrids.cambridge.arm.com> References: <20191220143025.33853-1-andrew.murray@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191220143025.33853-1-andrew.murray@arm.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, On Fri, Dec 20, 2019 at 02:30:07PM +0000, Andrew Murray wrote: > This series implements support for allowing KVM guests to use the Arm > Statistical Profiling Extension (SPE). > > 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 What happens if I run perf record on the VMM, or on the CPU(s) that the VMM is running on? i.e. $ perf record -e arm_spe/ts_enable=1,pa_enable=1,pct_enable=1/ \ lkvm ${OPTIONS_FOR_GUEST_USING_SPE} ... or: $ perf record -a -c 0 -e arm_spe/ts_enable=1,pa_enable=1,pct_enable=1/ \ sleep 1000 & $ taskset -c 0 lkvm ${OPTIONS_FOR_GUEST_USING_SPE} & > 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. When not providing SPE to the guest, surely we should be trapping the registers and injecting an UNDEF? What happens today, without these patches? > 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. AFAICT these patches do not implement this. I assume that's what you're trying to point out here, but I just want to make sure that's explicit. Maybe this is a reason to trap+emulate if there's something more sensible that hyp can do if it sees a Stage-2 fault. Thanks, Mark. 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 8A66CC3F68F for ; Fri, 20 Dec 2019 17:55:34 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 1082F206C3 for ; Fri, 20 Dec 2019 17:55:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1082F206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 52C1C4ACD5; Fri, 20 Dec 2019 12:55:33 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2JhwNHI7A8c; Fri, 20 Dec 2019 12:55:32 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 27DD24AC88; Fri, 20 Dec 2019 12:55:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 494B64A95C for ; Fri, 20 Dec 2019 12:55:30 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXjiPaKPvZYj for ; Fri, 20 Dec 2019 12:55:29 -0500 (EST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0819A4A95B for ; Fri, 20 Dec 2019 12:55:28 -0500 (EST) 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 619A01FB; Fri, 20 Dec 2019 09:55:28 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D2C13F67D; Fri, 20 Dec 2019 09:55:27 -0800 (PST) Date: Fri, 20 Dec 2019 17:55:25 +0000 From: Mark Rutland To: Andrew Murray Subject: Re: [PATCH v2 00/18] arm64: KVM: add SPE profiling support Message-ID: <20191220175524.GC25258@lakrids.cambridge.arm.com> References: <20191220143025.33853-1-andrew.murray@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20191220143025.33853-1-andrew.murray@arm.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Cc: kvm@vger.kernel.org, Marc Zyngier , Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, Sudeep Holla , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Andrew, On Fri, Dec 20, 2019 at 02:30:07PM +0000, Andrew Murray wrote: > This series implements support for allowing KVM guests to use the Arm > Statistical Profiling Extension (SPE). > > 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 What happens if I run perf record on the VMM, or on the CPU(s) that the VMM is running on? i.e. $ perf record -e arm_spe/ts_enable=1,pa_enable=1,pct_enable=1/ \ lkvm ${OPTIONS_FOR_GUEST_USING_SPE} ... or: $ perf record -a -c 0 -e arm_spe/ts_enable=1,pa_enable=1,pct_enable=1/ \ sleep 1000 & $ taskset -c 0 lkvm ${OPTIONS_FOR_GUEST_USING_SPE} & > 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. When not providing SPE to the guest, surely we should be trapping the registers and injecting an UNDEF? What happens today, without these patches? > 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. AFAICT these patches do not implement this. I assume that's what you're trying to point out here, but I just want to make sure that's explicit. Maybe this is a reason to trap+emulate if there's something more sensible that hyp can do if it sees a Stage-2 fault. Thanks, Mark. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 7DBB6C2D0D2 for ; Fri, 20 Dec 2019 17:55:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4E6A02146E for ; Fri, 20 Dec 2019 17:55:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ld3KnKox" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E6A02146E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=B/TnI5q3TwW5WfD2EoY2qZRBbK+s5Th6X3YxhZ6XgBk=; b=Ld3KnKox59x14l R/17As+yHNiHX4O0gexyt9ISm/4eur4LbfqVXdbmoXMIJjaKo7Oo4fP5Qu81IOreQYybBhSt/aCNM ZPwaLYQZU1SEblXUHjoMFVDxkMiaS5guT5eHK2qQaaTFOtHyYp9xou94av46aAncqppVSlF+EsFv6 gGcvEqRPFOTDwfNySCtYLVS8UUfHohCOn2KOy2tjBLpWtyNRM6ga17VrhgZZoFuCpboeuOHhYcuNX 3tjASwOK3lnjN9TLYntJbAiBC6Im5mUcQ4OvYkyYrnNe202ImWlAOxx70+jbOXMSgvC5TADWhrEn7 0ZjJAOb6cAmuC/Hu8CkQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iiMUu-00085w-U4; Fri, 20 Dec 2019 17:55:32 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iiMUr-000852-M8 for linux-arm-kernel@lists.infradead.org; Fri, 20 Dec 2019 17:55:31 +0000 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 619A01FB; Fri, 20 Dec 2019 09:55:28 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D2C13F67D; Fri, 20 Dec 2019 09:55:27 -0800 (PST) Date: Fri, 20 Dec 2019 17:55:25 +0000 From: Mark Rutland To: Andrew Murray Subject: Re: [PATCH v2 00/18] arm64: KVM: add SPE profiling support Message-ID: <20191220175524.GC25258@lakrids.cambridge.arm.com> References: <20191220143025.33853-1-andrew.murray@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20191220143025.33853-1-andrew.murray@arm.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191220_095529_766728_4208676E X-CRM114-Status: GOOD ( 18.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, Marc Zyngier , Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, Sudeep Holla , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Andrew, On Fri, Dec 20, 2019 at 02:30:07PM +0000, Andrew Murray wrote: > This series implements support for allowing KVM guests to use the Arm > Statistical Profiling Extension (SPE). > > 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 What happens if I run perf record on the VMM, or on the CPU(s) that the VMM is running on? i.e. $ perf record -e arm_spe/ts_enable=1,pa_enable=1,pct_enable=1/ \ lkvm ${OPTIONS_FOR_GUEST_USING_SPE} ... or: $ perf record -a -c 0 -e arm_spe/ts_enable=1,pa_enable=1,pct_enable=1/ \ sleep 1000 & $ taskset -c 0 lkvm ${OPTIONS_FOR_GUEST_USING_SPE} & > 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. When not providing SPE to the guest, surely we should be trapping the registers and injecting an UNDEF? What happens today, without these patches? > 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. AFAICT these patches do not implement this. I assume that's what you're trying to point out here, but I just want to make sure that's explicit. Maybe this is a reason to trap+emulate if there's something more sensible that hyp can do if it sees a Stage-2 fault. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel