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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id C56CFC4332F for ; Thu, 3 Nov 2022 08:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FijVZA2yhFzl+h7pm/5KgUTmiTsYU2vQNCCQqEgK0tQ=; b=EvT+v4IJmD8AU+ uPLgZ9dxSJV4kv4MjoyvTqtHcDLrFlPLbwr/eiaL6fPlAHJghTPmzVsES/avVHRayUGTpXRipqxZX ngEzHpcxr6QeEZ1Fkc9Vge8sEcKzhFs7n/xZxfC77nbJZ7APB6y42rHBm8+U/XFY185f3MJHJm4QR Ql861bkmEF4JBQtXAxLJ9WcN8pg1RPGhk3LEnkhNFmFoN2NU1nznEH4NnNiqwD9PpMq5ol/OHrQek Zz8H5xe1HoqsB0jTJg/UOhVKUf5fR4VT+q2V0MYVZwdQaY9ZfO+LEM1fY4k2oYAi9zj+8ose8Vche 2ApF1rgvaiQlMsDdS5ug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqVqE-00GlIE-EZ; Thu, 03 Nov 2022 08:44:50 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqVqA-00GlH9-Ts for linux-arm-kernel@lists.infradead.org; Thu, 03 Nov 2022 08:44:48 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 06F5161DB3; Thu, 3 Nov 2022 08:44:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58B01C433C1; Thu, 3 Nov 2022 08:44:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667465084; bh=6HC9cTjR3pmiIrioiO/OBwZqM/LEtqKSCEjcsbP+fGI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=G2/kSK4Y8xOTxpDstBuax/vzYlsm6ACyl6drdUdvPiCcyPostYlvl2G6kg/6jbHwJ Z+RjHZOpW6HrHWOpzc4vgS81QiYKFtobUuq7FUHtDq+Qp8CCRTew21RstOr5e+Sukl pLkzt3fUn++0dcQAUwmGDrtBU/+hJMnkInHSV6qI10kuSWR+Qth3QjB6Kcr+JUX9kR aM+qJ6d5s/+f5JvE4LMK0PrA0MwybSqa+YTM1z8UWfOsrk/YoWnT8uuAGPXOEFSXev U2rYpnlRwGh/z/7M0ztjfFFpJzzEVND0GC2f1jBMk2n/XILEgKT4XfEihaDm9FkHtd PRRTq8pSauVNQ== Received: from 82-132-225-179.dab.02.net ([82.132.225.179] helo=wait-a-minute.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 1oqVq4-003S3p-Ue; Thu, 03 Nov 2022 08:44:41 +0000 Date: Thu, 03 Nov 2022 08:44:04 +0000 Message-ID: <87v8nwfmwb.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Alexandru Elisei , Oliver Upton , Ricardo Koller Subject: Re: [PATCH v2 10/14] KVM: arm64: PMU: Move the ID_AA64DFR0_EL1.PMUver limit to VM creation In-Reply-To: References: <20221028105402.2030192-1-maz@kernel.org> <20221028105402.2030192-11-maz@kernel.org> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 82.132.225.179 X-SA-Exim-Rcpt-To: reijiw@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, oliver.upton@linux.dev, ricarkol@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221103_014447_082876_4995527F X-CRM114-Status: GOOD ( 26.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Reiji, On Thu, 03 Nov 2022 04:55:52 +0000, Reiji Watanabe wrote: > > Hi Marc, > > On Fri, Oct 28, 2022 at 4:16 AM Marc Zyngier wrote: > > > > case SYS_ID_DFR0_EL1: > > - /* Limit guests to PMUv3 for ARMv8.4 */ > > - val = cpuid_feature_cap_perfmon_field(val, > > - ID_DFR0_PERFMON_SHIFT, > > - kvm_vcpu_has_pmu(vcpu) ? ID_DFR0_PERFMON_8_4 : 0); > > + val &= ~ARM64_FEATURE_MASK(ID_DFR0_PERFMON); > > + val |= FIELD_PREP(ARM64_FEATURE_MASK(ID_DFR0_PERFMON), > > + pmuver_to_perfmon(vcpu_pmuver(vcpu))); > > Shouldn't KVM expose the sanitized value as it is when AArch32 is > not supported at EL0 ? Since the register value is UNKNOWN when AArch32 > is not supported at EL0, I would think this code might change the PERFMON > field value on such systems (could cause live migration to fail). I'm not sure this would cause anything to fail as we now treat all AArch32 idregs as RAZ/WI when AArch32 isn't supported (and the visibility callback still applies here). But it doesn't hurt to make pmuver_to_perfmon() return 0 when AArch32 isn't supported, and it will at least make the ID register consistent from a guest perspective. I plan to squash the following (untested) hack in: diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 8f4412cd4bf6..3b28ef48a525 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1094,6 +1094,10 @@ static u8 perfmon_to_pmuver(u8 perfmon) static u8 pmuver_to_perfmon(u8 pmuver) { + /* If no AArch32, make the field RAZ */ + if (!kvm_supports_32bit_el0()) + return 0; + switch (pmuver) { case ID_AA64DFR0_EL1_PMUVer_IMP: return ID_DFR0_PERFMON_8_0; @@ -1302,10 +1306,9 @@ static int set_id_dfr0_el1(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, u64 val) { - u8 perfmon, host_perfmon = 0; + u8 perfmon, host_perfmon; - if (system_supports_32bit_el0()) - host_perfmon = pmuver_to_perfmon(kvm_arm_pmu_get_pmuver_limit()); + host_perfmon = pmuver_to_perfmon(kvm_arm_pmu_get_pmuver_limit()); /* * Allow DFR0_EL1.PerfMon to be set from userspace as long as > I should have noticed this with the previous version... No worries, thanks a lot for having had a look! Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel