Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp12498pxb; Fri, 15 Jan 2021 04:39:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJy8v3RfkqCTUA5wKzCvaRG79PdCUBK6sqrYr+FA1wH4DmmROdIWzJ7DR/HQYUip5pwapDin X-Received: by 2002:aa7:c707:: with SMTP id i7mr9378179edq.183.1610714383464; Fri, 15 Jan 2021 04:39:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610714383; cv=none; d=google.com; s=arc-20160816; b=YXPPDnhDTDJ32cIsMEHmS6T3tdo1lac/H3D136Hn9MAtHW2xqzocoBKIX9PKVRDkWL loVp+Q8O5VU4POQ5qngDFdxQH6zDycTv583QCStHa/0PNFdgayw7e8NVCpuTeilp3cJW 8LY5hBNI2veyyHq+9kBMpoVdkdHzr3qToevjFgMQnJEmjbqTazxbHMRFzn9MWzxQJsOz m7ScDhS68rGg8dsvWOPaizkMHo1ODuo7zzTeve2cRU/FzfNdM7BiWBFriNJC/HwaoY4O a+zyptUMPZzGn/HL3rAiC3q0ceUaa94MsDtok8+J6tL8uuugV38PkuBRAjmwHxN9BkGL iiiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=GdSDpue/syMMdKXWHwpjtGVX8ub39D+/tOL1YraY/ck=; b=ZWJlzjX2WhL4Cfned1h4cXknY7//uKN++5dcGPi0e+sLXtn85uadgv38Mm0lT2szJ0 xnbGHxOpX5AiyNc6GFWON0ivLDdd1fIBIBVWraeaOS2La/Zu7aUjSiyR9+2W+6YlEMPm tviIJJFWeSp3FDMz68y1K+jvh5gJEvMOgvA7uBGfTFytn4+doV+avFDuKCxy9kWA0hmc GoYnniHmlhGO0WSlNcXC1yQyHWEp+ABX5m/fByaund15N7uLxOZNwPgprq2t8mXQmHxt qFX9k6LZs//06T/TEqaVRRaqNUFxWrGO2L2kzDN82tCnSNkXmYtV+eOy53qtOWxpGqwU EWiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UN1CAjrb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i25si2119559ejc.587.2021.01.15.04.39.19; Fri, 15 Jan 2021 04:39:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UN1CAjrb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728652AbhAOMgY (ORCPT + 99 others); Fri, 15 Jan 2021 07:36:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:43256 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387828AbhAOMgH (ORCPT ); Fri, 15 Jan 2021 07:36:07 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id F0BE52336F; Fri, 15 Jan 2021 12:35:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1610714127; bh=f0uF12iWYdWqVFfYSAYT6oY8N3u3USLCdiO3LCSqxd0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UN1CAjrbUbCZ8tUlMwxUfrjYvr2KWQgUIk6ZTcQOuO//hodKvz2GURPTOb18ReSs7 euZgcVZzILanqEHJwNFUtZOWdA1UGkim0LDGjSb3w7e+iJmmuiSL+ul9vmKLaj5xYo +WNCBPxmdcUPrqCGBRDTwpyDgbe84MQnSCfAhDXs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alexandru Elisei , Marc Zyngier Subject: [PATCH 5.4 59/62] KVM: arm64: Dont access PMCR_EL0 when no PMU is available Date: Fri, 15 Jan 2021 13:28:21 +0100 Message-Id: <20210115122001.241016765@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210115121958.391610178@linuxfoundation.org> References: <20210115121958.391610178@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marc Zyngier commit 2a5f1b67ec577fb1544b563086e0377f095f88e2 upstream. We reset the guest's view of PMCR_EL0 unconditionally, based on the host's view of this register. It is however legal for an implementation not to provide any PMU, resulting in an UNDEF. The obvious fix is to skip the reset of this shadow register when no PMU is available, sidestepping the issue entirely. If no PMU is available, the guest is not able to request a virtual PMU anyway, so not doing nothing is the right thing to do! It is unlikely that this bug can hit any HW implementation though, as they all provide a PMU. It has been found using nested virt with the host KVM not implementing the PMU itself. Fixes: ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register") Reviewed-by: Alexandru Elisei Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20201210083059.1277162-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman --- arch/arm64/kvm/sys_regs.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -625,6 +625,10 @@ static void reset_pmcr(struct kvm_vcpu * { u64 pmcr, val; + /* No PMU available, PMCR_EL0 may UNDEF... */ + if (!kvm_arm_support_pmu_v3()) + return; + pmcr = read_sysreg(pmcr_el0); /* * Writable bits of PMCR_EL0 (ARMV8_PMU_PMCR_MASK) are reset to UNKNOWN