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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD25AE7C4E2 for ; Wed, 4 Oct 2023 17:48:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243502AbjJDRsr (ORCPT ); Wed, 4 Oct 2023 13:48:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233239AbjJDRsq (ORCPT ); Wed, 4 Oct 2023 13:48:46 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B078D9E for ; Wed, 4 Oct 2023 10:48:42 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 581F4C433C8; Wed, 4 Oct 2023 17:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696441722; bh=EZOLoYCmDWEQ7sfMyWL89qK2JKi3r9x1fsbt4TT3AFY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZNCz6vYVOwqSKFLbWCoRZdjUEFu8haUoBnTzcvpqZAekcU6ddBdY7202hlgvo2xII cd7VE4n5VyPyH0s7c13/knNz1T/KBog5dO9FzKEqwU+ZQUAbDIz5GQxWtQuCXp1Z+p OvZY2SVZxkpuKebx3EdpKKTuqs7kRX66WaHHpmtqpxPCZVyEqGHLdm2RR4z6d4zd+f zsIvMIsFDC3K1i5qfvCKU+RFheKM+/Uf2rb9xWV3PfDVx9isfWz6yeukrN8lOX75L5 pzV3peigKKEsHuFhKq6AvLn7+bbiJtAHhOWsL8Tv93hu2M+Efsmbdfwm87QgJVxYWn Xs6kg5qNAGlkQ== 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 1qo5zD-0019Kp-PL; Wed, 04 Oct 2023 18:48:39 +0100 Date: Wed, 04 Oct 2023 18:48:38 +0100 Message-ID: <86a5synurt.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Zenghui Yu , Jing Zhang , Cornelia Huck Subject: Re: [PATCH v11 10/12] KVM: arm64: Document vCPU feature selection UAPIs In-Reply-To: References: <20231003230408.3405722-1-oliver.upton@linux.dev> <20231003230408.3405722-11-oliver.upton@linux.dev> <86o7heohjh.wl-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/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) 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: oliver.upton@linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, jingzhangos@google.com, cohuck@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 04 Oct 2023 17:52:08 +0100, Oliver Upton wrote: > > On Wed, Oct 04, 2023 at 10:36:50AM +0100, Marc Zyngier wrote: > > On Wed, 04 Oct 2023 00:04:06 +0100, > > Oliver Upton wrote: > > [...] > > > > +The ID Registers > > > +================ > > > + > > > +The Arm architecture specifies a range of *ID Registers* that describe the set > > > +of architectural features supported by the CPU implementation. KVM initializes > > > +the guest's ID registers to the maximum set of CPU features supported by the > > > +system. The ID register values are VM-scoped in KVM, meaning that the values > > > +are identical for all vCPUs in a VM. > > > > I'm a bit reluctant to give this guarantee. Case in point: MPIDR_EL1 > > is part of the Feature ID space, and is definitely *not* a register > > that we can make global, even on a fully homogeneous system. > > Oh, very good point. > > > I'd also like to give us more flexibility to change the implementation > > in the future without having to change the API again. IMO, the fact > > that we make our life simpler by only tracking a single copy is an > > implementation detail, not something that userspace should rely on. > > > > I would simply turn the "The ID register values are VM-scoped" into > > "The ID register values may be VM-scoped", which gives us that > > flexibility. > > Agreed, I'm happy to duck behind some vague language here :) > > > > + > > > +KVM allows userspace to *opt-out* of certain CPU features described by the ID > > > +registers by writing values to them via the ``KVM_SET_ONE_REG`` ioctl. The ID > > > +registers are mutable until the VM has started, i.e. userspace has called > > > +``KVM_RUN`` on at least one vCPU in the VM. Userspace can discover what fields > > > +are mutable in the ID registers using the ``KVM_ARM_GET_REG_WRITABLE_MASKS``. > > > +See the :ref:`ioctl documentation ` for more > > > +details. > > > + > > > +Userspace is allowed to *limit* or *mask* CPU features according to the rules > > > +outlined by the architecture in DDI0487J 'D19.1.3 Principles of the ID scheme > > > > nit: consider spelling out the *full* version of the ARM ARM (DDI > > 0487J.a), just in case we get a J.b this side of Xmas and that this > > reference is renumbered... > > Going to fix both of these with the following diff: > > diff --git a/Documentation/virt/kvm/arm/vcpu-features.rst b/Documentation/virt/kvm/arm/vcpu-features.rst > index 2d2f89c5781f..f7cc6d8d8b74 100644 > --- a/Documentation/virt/kvm/arm/vcpu-features.rst > +++ b/Documentation/virt/kvm/arm/vcpu-features.rst > @@ -24,8 +24,8 @@ The ID Registers > The Arm architecture specifies a range of *ID Registers* that describe the set > of architectural features supported by the CPU implementation. KVM initializes > the guest's ID registers to the maximum set of CPU features supported by the > -system. The ID register values are VM-scoped in KVM, meaning that the values > -are identical for all vCPUs in a VM. > +system. The ID register values may be VM-scoped in KVM, meaning that the > +values could be shared for all vCPUs in a VM. > > KVM allows userspace to *opt-out* of certain CPU features described by the ID > registers by writing values to them via the ``KVM_SET_ONE_REG`` ioctl. The ID > @@ -36,9 +36,9 @@ See the :ref:`ioctl documentation ` for more > details. > > Userspace is allowed to *limit* or *mask* CPU features according to the rules > -outlined by the architecture in DDI0487J 'D19.1.3 Principles of the ID scheme > -for fields in ID register'. KVM does not allow ID register values that exceed > -the capabilities of the system. > +outlined by the architecture in DDI0487J.a D19.1.3 'Principles of the ID > +scheme for fields in ID register'. KVM does not allow ID register values that > +exceed the capabilities of the system. > > .. warning:: > It is **strongly recommended** that userspace modify the ID register values > Yup, looks good. M. -- Without deviation from the norm, progress is not possible.