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 D54CBC48260 for ; Tue, 13 Feb 2024 14:53:49 +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=Q2j+CgfRXzR89kw0d6Q+GrbIU23yw4LpohOnxR0B2Ss=; b=BFwJpA51RoT6Cs cjnHrNs2lx5Jqpjo8/vYoIcDNPLk7iNPcZyBHjAWR0DMBsNOr5q789O8Gd/xazXfoJqm+8UMeouKm I5YIsgJP8QwwRwPmgPoCXmZzw5PsGiwbNBsmynyKvKc2Y+nDhSwLYWeXcKHGE52oVyjWvbAy3BRJ3 4Zc1tRyCwdYI26W7FKzAyyCOnroKfckhbt5wcwitRNA/fy2TSEgu7cz8N6UsXD2CyoPENUBVOrMbX PYjV1K4M2XHcTMT2di48Do86IaduDALiSSGYRgbi5l24j6pQleu3BO9fe94lXqLOCIbrgwxFX9doE VvA5aZ1OiRP9I2Dd4Eog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rZuAG-00000009arY-3ksN; Tue, 13 Feb 2024 14:53:40 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rZuAC-00000009apJ-2sVT for linux-arm-kernel@lists.infradead.org; Tue, 13 Feb 2024 14:53:39 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 19E15CE1C97; Tue, 13 Feb 2024 14:53:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49692C433C7; Tue, 13 Feb 2024 14:53:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707836014; bh=ljQZdVGWJEpWfmO6ZylQWXmSd4XObpE6ZnEzEXs+2eU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kOW8HNlwig356NaVhnMKvG5L9/uvgEo7oVieXYlekvBUwu94crOOHFLyGJLVhBYzS RqLWS1e8OlAt5u6fm/k9Wq8ABC37uCh0I6iBOTVetiwhxzw0qMyC+tk8R7NV8s3LEp Rb3Bjt67Bj1loq8tNg8SWettwgTVvYDPtfKXpYti1k9YFd/vFm9KYL/dYoCS2HH0Ej pfrfm+emRF/L3f/W9gXlNySqM3BkcdWEL6rJSzY0NsudtudyimrSYqawK0z/VYmlfD HRc//HVHCYV8vy4tmp4TP4Z15jN543Dz8mwtdO23XZHmQL4lkj6kJvh2NS1z47bEmT 18KgucW5WFIkQ== 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 1rZuA7-002oJK-T0; Tue, 13 Feb 2024 14:53:31 +0000 Date: Tue, 13 Feb 2024 14:53:31 +0000 Message-ID: <86a5o45sb8.wl-maz@kernel.org> From: Marc Zyngier To: Eric Auger Cc: Jing Zhang , KVM , KVMARM , ARMLinux , Oliver Upton , Will Deacon , Paolo Bonzini , James Morse , Alexandru Elisei , Suzuki K Poulose , Fuad Tabba , Suraj Jitindar Singh , Cornelia Huck , Shaoqin Huang , Sebastian Ott Subject: Re: [PATCH v1 2/4] KVM: arm64: Document KVM_ARM_GET_REG_WRITABLE_MASKS In-Reply-To: <82b72bd2-c079-40c3-90b8-30174f2a8fe0@redhat.com> References: <20230919175017.538312-1-jingzhangos@google.com> <20230919175017.538312-3-jingzhangos@google.com> <82b72bd2-c079-40c3-90b8-30174f2a8fe0@redhat.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.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: eauger@redhat.com, jingzhangos@google.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, will@kernel.org, pbonzini@redhat.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, tabba@google.com, surajjs@amazon.com, cohuck@redhat.com, shahuang@redhat.com, sebott@redhat.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-20240213_065337_102997_90139FA9 X-CRM114-Status: GOOD ( 35.45 ) 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 Hey Eric, On Tue, 13 Feb 2024 13:59:31 +0000, Eric Auger wrote: > > Hi, > > On 9/19/23 19:50, Jing Zhang wrote: > > Add some basic documentation on how to get feature ID register writable > > masks from userspace. > > > > Signed-off-by: Jing Zhang > > --- > > Documentation/virt/kvm/api.rst | 42 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index 21a7578142a1..2defb5e198ce 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -6070,6 +6070,48 @@ writes to the CNTVCT_EL0 and CNTPCT_EL0 registers using the SET_ONE_REG > > interface. No error will be returned, but the resulting offset will not be > > applied. > > > > +4.139 KVM_ARM_GET_REG_WRITABLE_MASKS > > +------------------------------------------- > > + > > +:Capability: KVM_CAP_ARM_SUPPORTED_FEATURE_ID_RANGES > > +:Architectures: arm64 > > +:Type: vm ioctl > > +:Parameters: struct reg_mask_range (in/out) > > +:Returns: 0 on success, < 0 on error > > + > > + > > +:: > > + > > + #define ARM64_FEATURE_ID_SPACE_SIZE (3 * 8 * 8) > > + #define ARM64_FEATURE_ID_RANGE_IDREGS BIT(0) > > + > > + struct reg_mask_range { > > + __u64 addr; /* Pointer to mask array */ > > + __u32 range; /* Requested range */ > > + __u32 reserved[13]; > > + }; > > + > > +This ioctl copies the writable masks for Feature ID registers to userspace. > > +The Feature ID space is defined as the AArch64 System register space with > > +op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}. > when attempting a migration between Ampere Altra and ThunderXv2 the > first hurdle is to handle a failure when writing ICC_CTLR_EL1 > (3.0.12.12.4) on dest. This reg is outside of the scope of the above > single range (BIT(0)). Indeed. But more importantly, this isn't really an ID register. Plenty of variable bits in there. > This may be questionable if we want to migrate between those types of > machines but the goal is to exercise different scenarios to have a > gloval view of the problems. I think this is a valuable experiment, and we should definitely explore this sort of things (as I cannot see the diversity of ARM system slowing down any time soon). > > This reg exposes some RO capabilities such as ExtRange, A3V, SEIS, > IDBits, ... > So to get the migration going further I would need to tweek this on the > source - for instance I guess SEIS could be reset despite the host HW > cap - without making too much trouble. I'm not sure SEIS is such an easy one: if you promised the guest that it would never get an SError doing the most stupid things (SEIS=0), it really shouldn't get one after migration. If you advertised it on the source HW (Altra), a migration to TX2 would be fine. The other bits are possible to change depending on the requirements of the VM (aff3, IDBits), and ExtRange should always be set to 0 (because our GIC implementation doesn't support EPPI/ESPI). The really ugly part here is that if you want to affect these bits, you will need to trap and emulate the access. Not a big deal, but in the absence of FGT, you will need to handle the full Common trap group, which is going to slow things down (you will have to trap ICV_PMR_EL1, for example). > What would you recommend, adding a new range? But I guess we need to > design ranges carefully otherwise we may be quickly limited by the > number of flag bits. I can see a need to adding a range that would cover non-ID registers that have RO fields. But we also need to consider the case of EL2 registers that take part in this. For example, ICV_CTLR_EL1 and ICH_VTR_EL2 and deeply linked, and share some fields. Without NV, no need to expose HCR_VTR_EL2. With NV, this register actually drives ICV_CTLR_EL1. So careful planning is required here, and the impact of this measured. 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