From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8604B43155 for ; Tue, 13 Aug 2024 18:20:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723573258; cv=none; b=bnGTYd3b7/gDK3vsA9O1zy0pGdIpWoWVKJSlBZwBXtzMUJVDTIQp08UOxEpqCMaP49xDoUCcIO0rQHiFnqtp0jxrB9aLrZRfIKFbyifpqbrLH6nLkIoHaOcDQOWL/qfZwbNDVRu7TXAkF1K8qx2v/qCjNC8gOxAcjSe4Krw1Z9U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723573258; c=relaxed/simple; bh=orNml0EfHsL/20Fp8OD1Gy6lh554X4vQdFDgJ8ulL20=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Rv3PtkPoLFbrfHHSGtBb4WIwhSnymSQMI+9q8QinjyUdmW9y2z1FbM4BVLLm4MR3b9Oxzdl85R7CfMdN5s/49j9g+k2T5Tb6Ah3a+Xfz64L0nGdJdzjM/whO/hXVueDErH2RnaryucK6OquCpTYZw1d6UH9VMSt9E3SXXbOJIBY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UM7Y7TF5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UM7Y7TF5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6F7DC32782; Tue, 13 Aug 2024 18:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723573258; bh=orNml0EfHsL/20Fp8OD1Gy6lh554X4vQdFDgJ8ulL20=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UM7Y7TF5TNKAvq/YvqpldIP67N0nknWdDTuQ6rnZGOtKNadHqVPbgGOy3Mn1i6kgw llmCOjP/kx7iTD0mxkyfW1UDjyvCqL4Q1JEcLa/lDH0ASt5F8bI2NZImvjMvBYbmkj wJ2/ml7zVA+4ZQoHuoseiwa8PaFEMS9eYWhLPwMyYCi+09/3fOWGIej2lhXqa7/Sl5 /TVQi+gsJQiJxtUOIP6eVAsJIqaJ9YA75/uH50F3Agpbm6Lr8Qm82eky1xhBMs1AqN yPVEZJrO1UeOV+EnShOvoOX1XR8FNhsQjM+YQdCLEhb4Kc6A4CJXvOgDWPr/KMb8LW hMa1JZGcLW1AQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1sdw8d-003Rae-Ex; Tue, 13 Aug 2024 19:20:55 +0100 Date: Tue, 13 Aug 2024 19:20:55 +0100 Message-ID: <86v804z3lk.wl-maz@kernel.org> From: Marc Zyngier To: Shameer Kolothum Cc: , , , , , , , , , Subject: Re: [PATCH] KVM: arm64: Make the exposed feature bits in AA64DFR0_EL1 writable from userspace In-Reply-To: <20240813142835.77180-1-shameerali.kolothum.thodi@huawei.com> References: <20240813142835.77180-1-shameerali.kolothum.thodi@huawei.com> 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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: shameerali.kolothum.thodi@huawei.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, catalin.marinas@arm.com, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, wangzhou1@hisilicon.com, linuxarm@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 13 Aug 2024 15:28:35 +0100, Shameer Kolothum wrote: > > KVM exposes the OS double lock feature bit to Guests but returns > RAZ/WI on Guest OSDLR_EL1 access. This breaks Guest migration between > systems where this feature support differ. Add support to make this > feature writable from userspace by setting the mask bit. While at it, > set the mask bits for other exposed features in the AA64DFR0_EL1 > register as well. > > Also update the selftest to cover these fields. > > Signed-off-by: Shameer Kolothum > --- > This is based on the discussion here(Thanks to Oliver), > https://lore.kernel.org/all/ZrVSlbVwnaMDShah@linux.dev/ > --- > arch/arm64/kvm/sys_regs.c | 6 +++++- > tools/testing/selftests/kvm/aarch64/set_id_regs.c | 4 ++++ > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index c90324060436..adb49d681052 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -2376,7 +2376,11 @@ static const struct sys_reg_desc sys_reg_descs[] = { > .get_user = get_id_reg, > .set_user = set_id_aa64dfr0_el1, > .reset = read_sanitised_id_aa64dfr0_el1, > - .val = ID_AA64DFR0_EL1_PMUVer_MASK | > + .val = ID_AA64DFR0_EL1_DoubleLock_MASK | > + ID_AA64DFR0_EL1_CTX_CMPs_MASK | > + ID_AA64DFR0_EL1_WRPs_MASK | > + ID_AA64DFR0_EL1_BRPs_MASK | I think this is going to cause some troubles. The issue is that context-aware breakpoints are the highest-numbered breakpoints, right after the normal breakpoints (D2.8.3 "Breakpoint types and linking of breakpoints"). So if you reduce the number of normal breakpoints, you shift the context-aware ones down, and everything breaks. I really don't see how you can safely do that without completely changing the way we handle the debug registers. Thanks, M. -- Without deviation from the norm, progress is not possible.