Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp2475108rdb; Mon, 5 Feb 2024 07:42:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IEE+iIP+0mivdMXQJt9OhSSthT0JpjD7/wNexWcJin2ApdYf6iFrHLiRsmVRPJVNXeedbIz X-Received: by 2002:a92:d4c9:0:b0:363:bf82:763e with SMTP id o9-20020a92d4c9000000b00363bf82763emr45348ilm.27.1707147727274; Mon, 05 Feb 2024 07:42:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707147727; cv=pass; d=google.com; s=arc-20160816; b=rtYcHxW6CS5Ipohmu9jKtznEEpCX5mCR8tuhEdmJqTd+UbzQ8oxEbkqXoBs6+mgnN3 wNDevn0wrGitK3yBQ9L/OCpeZ3mruRF3zTdg2mZ8L5Gfv9dzgWY1I0OE3eVPNUWGg2JU Wsl3MNh5/9qpN9cAmb9GxqXLPklLEHgXK6XUXgDwnlNmQ4ZVzhpyGLJOVas8dmKuZi9A BL6aFERUmOh96GsqgQ2SZ23OrVthqhQSphRlO99h2hdXQa0NhORtGkGjMCJRKx2MTJRl cP8BV4bggK3EKWnqivDccCxKss8QMpFMh5OC0SGUjy51gvA0WMnrTUYg3a/cLSLQBF44 slMA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=EV/40LdK1BmXdVz8H9XENaEz6tkCtMv4bP4zvUWXmVM=; fh=4PE+Xw1khVO1hRRPIYD5U6dv7xDdGqRSq8/DEnMvGD8=; b=ipsZ1Xqcj+T6tCU+SZAdS+lJwA1ex4k9Dd3/0yRDMh1o/ftsYsjXNlkG7ThoNJ5Ko0 WfrYJug0m+IeO68eOtCY6DNzIq6bowULUq7pBuFrnfUcXn2YGYbEoqykR7NPp34o3x14 Ll5TOrtXkfjUAu610gexanzv96XPnGfbLpeSt0G/kZWb9e46RieyMgICtPAPOfzqEdH5 WzRiuRGMBgbXQJscC6BHmGUsH7KiNddF5O1t6eRpQnysZzQ8d+51X2RMYYRl2Vo187jI BoecynuMXt7kll789uBAPua5kRiGY1Q72g15LPodWeG9QBNtYNhIgonoFCDjLgTlmyvi jfvA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-52937-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-52937-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com X-Forwarded-Encrypted: i=1; AJvYcCWEJ3u1LI/uQbUZ8b8dE3Wc2rTr423UCgYRkYQUR03eFyWrhWbrI6/5oTSm6sA7zp4CYmOgvLh+RI1OdWnoGnODjy727oy4qare1dOk2A== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id ca39-20020a056a0206a700b005dc0b1b0116si57559pgb.119.2024.02.05.07.42.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Feb 2024 07:42:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-52937-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-52937-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-52937-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id BAB3028868C for ; Mon, 5 Feb 2024 15:39:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 80A3733CCC; Mon, 5 Feb 2024 15:37:45 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6785A32C90 for ; Mon, 5 Feb 2024 15:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707147465; cv=none; b=biBF89Bt3r59tmW7hZGcKYaaVj4+gHlInszpzFqI6gpwO0lRtyXxSquacln7wB9xlXJnwR84ravtNSW3CSfGCmu6i5SUfpkPRyRIu0Nv2j4XfJjlyXPfxsF5yWTvH7CDZ8yFuoTNE38K9jAvFywhnYjtKy3o4ZXZp3WQsw3Q8Lc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707147465; c=relaxed/simple; bh=NAOhCgljajhu9rlMaYcMai/ExO7gay4hX8crqnQPk9k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s6mE2jUWR3oElwE7gqVgqmRnawUE7WMaL9E/O1L3Qt/QPrMUWxE00bP/iUVJR1G7zqERoALbzllFVn1MLXxLbuw9ejX1Vzon4IQl3dTjbdvHDDIm69mKBQK8rKuyOAoF7Ge6V/IySbWAti40MFy9xcH8krUbw/t2PEqG33eKeZg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 618601FB; Mon, 5 Feb 2024 07:38:25 -0800 (PST) Received: from [192.168.1.100] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4D6B63F5A1; Mon, 5 Feb 2024 07:37:39 -0800 (PST) Message-ID: Date: Mon, 5 Feb 2024 15:37:34 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v4 2/7] arm64: KVM: Use shared area to pass PMU event state to hypervisor Content-Language: en-US To: Marc Zyngier Cc: Oliver Upton , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, broonie@kernel.org, suzuki.poulose@arm.com, acme@kernel.org, James Morse , Zenghui Yu , Catalin Marinas , Will Deacon , Mike Leach , Leo Yan , Alexander Shishkin , Anshuman Khandual , Rob Herring , Miguel Luis , Jintack Lim , Ard Biesheuvel , Mark Rutland , Arnd Bergmann , Vincent Donnefort , Kristina Martsenko , Fuad Tabba , Joey Gouly , Akihiko Odaki , Jing Zhang , linux-kernel@vger.kernel.org References: <20240104162714.1062610-1-james.clark@arm.com> <20240104162714.1062610-3-james.clark@arm.com> <8a908ee8-620a-d9c2-734b-5a6402950072@arm.com> <867cjj6ohz.wl-maz@kernel.org> <864jen6k0i.wl-maz@kernel.org> From: James Clark In-Reply-To: <864jen6k0i.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05/02/2024 14:52, Marc Zyngier wrote: > On Mon, 05 Feb 2024 14:17:10 +0000, > James Clark wrote: >> >> On 05/02/2024 13:21, Oliver Upton wrote: >>> On Mon, Feb 05, 2024 at 01:15:36PM +0000, Marc Zyngier wrote: >>>> On Mon, 05 Feb 2024 13:04:51 +0000, >>>> Oliver Upton wrote: >>>>> >>>>> Unless someone has strong opinions about making this work in protected >>>>> mode, I am happy to see tracing support limited to the 'normal' nVHE >>>>> configuration. The protected feature as a whole is just baggage until >>>>> upstream support is completed. >>>> >>>> Limiting tracing to non-protected mode is a must IMO. Allowing tracing >>>> when pKVM is enabled is a sure way to expose secrets that should >>>> stay... secret. The only exception I can think of is when >>>> CONFIG_NVHE_EL2_DEBUG is enabled, at which point all bets are off. >>> >>> Zero argument there :) I left off the "and PMU" part of what I was >>> saying, because that was a feature that semi-worked in protected mode >>> before VM/VCPU shadowing support landed. >>> >> >> In that case I can hide all this behind CONFIG_NVHE_EL2_DEBUG for pKVM. >> This will also have the effect of disabling PMU again for pKVM because I >> moved that into this new shared area. > > I'm not sure what you have in mind, but dropping PMU support for > non-protected guests when protected-mode is enabled is not an > acceptable outcome. > > Hiding the trace behind a debug option is fine as this is a global > setting that has no userspace impact, but impacting guests isn't. > > M. > Hmmm in that case if there's currently no way to distinguish between normal VMs and pVMs in protected-mode then what I was thinking of probably won't work. I'll actually just leave PMU as it is and only have tracing disabled in protected-mode. My only question now is whether to: * Keep this new shared area and use it for both PMU and trace status (well, for PMU only in protected mode as trace would always be disabled and doesn't actually need any state) * Delete patch 2, add a new normal per-cpu struct just for trace status that's only used in non-protected mode and revert to copying the PMU status into the vCPU on guest switch as it was previously.