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 0CA31C433F5 for ; Thu, 24 Mar 2022 23:01:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347894AbiCXXDJ (ORCPT ); Thu, 24 Mar 2022 19:03:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244324AbiCXXDG (ORCPT ); Thu, 24 Mar 2022 19:03:06 -0400 Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04C2FBB092 for ; Thu, 24 Mar 2022 16:01:34 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id i1so4191447ila.0 for ; Thu, 24 Mar 2022 16:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gFsgyLr9ZtY3CsTFCFwPED/ZztahOm1f0K0B19xBX3w=; b=kH0v456Gt3P/aaiK1WD+pFZmD9Gp500hFIgXBeuKEOsibDtVkcQ5MS5bkseEn3PwHO lMRAf8PprVMJiIsuTtIjMPYVLd178OLFNq5YXov60sLQbgTcptsgHQ71qQWKxpXJ+ZkR gFh9oC6cAbkt3OR5dp4jsY32eonP7c6a8U88vxJUKD2tXRWR0Xl6tWSPCXYEmL2nC6dj HHyWjN+DMwyjhUHiOlPaEoNqs4n5eXaX/dXqyKMw8f5Tig2q7G8un89ZsicqjxlcTNlF ZfFplWKPp+SZ0xzaIW6fpNVEFoGAk91tasISQvMSIcCRWvHzzdDKwXmgV4CsJ566xWx4 FQPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gFsgyLr9ZtY3CsTFCFwPED/ZztahOm1f0K0B19xBX3w=; b=5kMek21arBxGZ6w91hB0uclUJ48thGKLmBfT1RFEF2KfTCaE8YrYGMZMruoTnsY9d2 otOdK0ttBNHNSvqjyglqcoX0WZejpdwPmb2DudnGekxYM0bAuqjSJaVMfna/cwb3BgjP fgiv7jO1ynjsdM7FUm04FOG/QwxmaQZMITVlmU4dZNs6GWQW4D1O9586GJpgKBwAEarQ DgW/H2JEjri6MtOfdElEEJlQWTyHK+7yBeAeRYOKokrm/oHRdOPeh8ffjbay+/x0cat8 +n43DYjDr3tzQ76qwHNTrpwvwt5DFB7WkopQtyVWNNRPHDvoFmR5ickbyFuyxcz1bCuR h3AQ== X-Gm-Message-State: AOAM530cf32PMj1vVEX7bmLzctBW/m6slghXi1v9w2TGh2DOGoRA/iKA sNGBx/29OQWLQbYjHxgiSUj/yA== X-Google-Smtp-Source: ABdhPJx2bRtFRweMkEdLStxBpCpfXVRg/31TxuTxppv+RqiYB6T4/Iszjoin9ITToDSMnv+L9FMkEw== X-Received: by 2002:a05:6e02:1ba8:b0:2c8:218a:24bd with SMTP id n8-20020a056e021ba800b002c8218a24bdmr3897140ili.198.1648162893098; Thu, 24 Mar 2022 16:01:33 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id q9-20020a5edb09000000b00645c7a00cbbsm1978604iop.20.2022.03.24.16.01.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 16:01:32 -0700 (PDT) Date: Thu, 24 Mar 2022 23:01:29 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Fuad Tabba , Peng Liang , Peter Shier , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-12-reijiw@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Mar 24, 2022 at 01:23:42PM -0700, Reiji Watanabe wrote: > Hi Oliver, > > On Wed, Mar 23, 2022 at 12:53 PM Oliver Upton wrote: > > > > Hi Reiji, > > > > On Thu, Mar 10, 2022 at 08:47:57PM -0800, Reiji Watanabe wrote: > > > Add hidden or reserved ID registers, and remaining ID registers, > > > which don't require special handling, to id_reg_desc_table. > > > Add 'flags' field to id_reg_desc, which is used to indicates hiddden > > > or reserved registers. Since now id_reg_desc_init() is called even > > > for hidden/reserved registers, change it to not do anything for them. > > > > > > Signed-off-by: Reiji Watanabe > > > > I think there is a very important detail of the series that probably > > should be highlighted. We are only allowing AArch64 feature registers to > > be configurable, right? AArch32 feature registers remain visible with > > their default values passed through to the guest. If you've already > > stated this as a precondition elsewhere then my apologies for the noise. > > > > I don't know if adding support for this to AArch32 registers is > > necessarily the right step forward, either. 32 bit support is working > > just fine and IMO its OK to limit new KVM features to AArch64-only so > > long as it doesn't break 32 bit support. Marc of course is the authority > > on that, though :-) > > > > If for any reason a guest uses a feature present in the AArch32 feature > > register but hidden from the AArch64 register, we could be in a > > particularly difficult position. Especially if we enabled traps based on > > the AArch64 value and UNDEF the guest. > > > > One hack we could do is skip trap configuration if AArch32 is visible at > > either EL1 or EL0, but that may not be the most elegant solution. > > Otherwise, if we are AArch64-only at every EL then the definition of the > > AArch32 feature registers is architecturally UNKNOWN, so we can dodge > > the problem altogether. What are your thoughts? > > Thank you so much for your review, Oliver! > > For aarch32 guests (when KVM_ARM_VCPU_EL1_32BIT is configured), > yes, the current series is problematic as you mentioned... > I am thinking of disallowing configuring ID registers (keep ID > registers immutable) for the aarch32 guests for now at least. > (will document that) That fixes it halfway, but the AArch64 views of the AArch32 feature registers have meaning even if AArch32 is defined at EL0. The only time they are architecturally UNKNOWN is if AArch32 is not implemented at any EL visible to the guest. So, given that: > For aarch64 guests that support EL0 aarch32, it would generally > be a userspace bug if userspace sets inconsistent values in 32bit > and 64bit ID registers. KVM doesn't provide a complete consistency > checking for ID registers, but this could be added later as needed. I completely agree that there is a large set of things that can be swept under the rug of userspace bugs. If we are going to do that, we need to strongly assert that configurable feature registers is only for fully AArch64-only guests. Additionally, strong documentation around these expectations is required. Mind you, these opinions are my own and IDK how others or Marc feel about it. My read of the situation w.r.t. the AArch32 registers is that it will become a mess to implement on top of the AArch64 registers. Given the fact that we aren't breaking AArch32 VMs, only augmenting behavior for AArch64, it seems OK. But I would genuinely love to be wrong on this topic too. I just don't have perspective on AArch32 users so it is hard to really say whether this is something they need as well. -- Thanks, Oliver 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id CEAAEC433EF for ; Thu, 24 Mar 2022 23:01:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2E3FB49EAA; Thu, 24 Mar 2022 19:01:37 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L4qv5mWBn4T; Thu, 24 Mar 2022 19:01:35 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DB50149F21; Thu, 24 Mar 2022 19:01:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2DE8649EAA for ; Thu, 24 Mar 2022 19:01:35 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo89jf8ILh9w for ; Thu, 24 Mar 2022 19:01:34 -0400 (EDT) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 0AAB749E44 for ; Thu, 24 Mar 2022 19:01:33 -0400 (EDT) Received: by mail-il1-f175.google.com with SMTP id j15so4151008ila.13 for ; Thu, 24 Mar 2022 16:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gFsgyLr9ZtY3CsTFCFwPED/ZztahOm1f0K0B19xBX3w=; b=kH0v456Gt3P/aaiK1WD+pFZmD9Gp500hFIgXBeuKEOsibDtVkcQ5MS5bkseEn3PwHO lMRAf8PprVMJiIsuTtIjMPYVLd178OLFNq5YXov60sLQbgTcptsgHQ71qQWKxpXJ+ZkR gFh9oC6cAbkt3OR5dp4jsY32eonP7c6a8U88vxJUKD2tXRWR0Xl6tWSPCXYEmL2nC6dj HHyWjN+DMwyjhUHiOlPaEoNqs4n5eXaX/dXqyKMw8f5Tig2q7G8un89ZsicqjxlcTNlF ZfFplWKPp+SZ0xzaIW6fpNVEFoGAk91tasISQvMSIcCRWvHzzdDKwXmgV4CsJ566xWx4 FQPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gFsgyLr9ZtY3CsTFCFwPED/ZztahOm1f0K0B19xBX3w=; b=lk7cFwpKikQS3R6TxsS0zFbLBGMJjHlUDMHIdaiJCV/wbY9iDbrat9X3pZWvnBBcvv Jr1TcZkGmPMpWvpveLAohtPouISmo2bG8t/gK07c7ABq3s0ZUl63Nlj2r2HbQ0qZYF78 kegkdjxv7bPqt353V11qXKPF4mfG6lw7tyuEPasl127j6S6jSihxJtuaP7ThQ3FHMn7a Ec+cmFGORbKtsTBGpbkmr6diFoT7oKPr0Kgq3DK9izJQ9At3xzvWv104i26fuNW0GbZ+ infFJKt7AGsBbhcgTZ9bLM7NQlkd72CWQdqZjrJgu+fQwTSjoo6WCLJdBBrDeGu0zMT+ NGOw== X-Gm-Message-State: AOAM532rS40+UWqb2VEH6pAvb6YsVfboUnEjGKio/a5J4lEyTO3e55Dt mGgJfxUPtThyzwfC5cEAA0v56w== X-Google-Smtp-Source: ABdhPJx2bRtFRweMkEdLStxBpCpfXVRg/31TxuTxppv+RqiYB6T4/Iszjoin9ITToDSMnv+L9FMkEw== X-Received: by 2002:a05:6e02:1ba8:b0:2c8:218a:24bd with SMTP id n8-20020a056e021ba800b002c8218a24bdmr3897140ili.198.1648162893098; Thu, 24 Mar 2022 16:01:33 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id q9-20020a5edb09000000b00645c7a00cbbsm1978604iop.20.2022.03.24.16.01.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 16:01:32 -0700 (PDT) Date: Thu, 24 Mar 2022 23:01:29 +0000 From: Oliver Upton To: Reiji Watanabe Subject: Re: [PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-12-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Will Deacon , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, Linux ARM X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, Mar 24, 2022 at 01:23:42PM -0700, Reiji Watanabe wrote: > Hi Oliver, > > On Wed, Mar 23, 2022 at 12:53 PM Oliver Upton wrote: > > > > Hi Reiji, > > > > On Thu, Mar 10, 2022 at 08:47:57PM -0800, Reiji Watanabe wrote: > > > Add hidden or reserved ID registers, and remaining ID registers, > > > which don't require special handling, to id_reg_desc_table. > > > Add 'flags' field to id_reg_desc, which is used to indicates hiddden > > > or reserved registers. Since now id_reg_desc_init() is called even > > > for hidden/reserved registers, change it to not do anything for them. > > > > > > Signed-off-by: Reiji Watanabe > > > > I think there is a very important detail of the series that probably > > should be highlighted. We are only allowing AArch64 feature registers to > > be configurable, right? AArch32 feature registers remain visible with > > their default values passed through to the guest. If you've already > > stated this as a precondition elsewhere then my apologies for the noise. > > > > I don't know if adding support for this to AArch32 registers is > > necessarily the right step forward, either. 32 bit support is working > > just fine and IMO its OK to limit new KVM features to AArch64-only so > > long as it doesn't break 32 bit support. Marc of course is the authority > > on that, though :-) > > > > If for any reason a guest uses a feature present in the AArch32 feature > > register but hidden from the AArch64 register, we could be in a > > particularly difficult position. Especially if we enabled traps based on > > the AArch64 value and UNDEF the guest. > > > > One hack we could do is skip trap configuration if AArch32 is visible at > > either EL1 or EL0, but that may not be the most elegant solution. > > Otherwise, if we are AArch64-only at every EL then the definition of the > > AArch32 feature registers is architecturally UNKNOWN, so we can dodge > > the problem altogether. What are your thoughts? > > Thank you so much for your review, Oliver! > > For aarch32 guests (when KVM_ARM_VCPU_EL1_32BIT is configured), > yes, the current series is problematic as you mentioned... > I am thinking of disallowing configuring ID registers (keep ID > registers immutable) for the aarch32 guests for now at least. > (will document that) That fixes it halfway, but the AArch64 views of the AArch32 feature registers have meaning even if AArch32 is defined at EL0. The only time they are architecturally UNKNOWN is if AArch32 is not implemented at any EL visible to the guest. So, given that: > For aarch64 guests that support EL0 aarch32, it would generally > be a userspace bug if userspace sets inconsistent values in 32bit > and 64bit ID registers. KVM doesn't provide a complete consistency > checking for ID registers, but this could be added later as needed. I completely agree that there is a large set of things that can be swept under the rug of userspace bugs. If we are going to do that, we need to strongly assert that configurable feature registers is only for fully AArch64-only guests. Additionally, strong documentation around these expectations is required. Mind you, these opinions are my own and IDK how others or Marc feel about it. My read of the situation w.r.t. the AArch32 registers is that it will become a mess to implement on top of the AArch64 registers. Given the fact that we aren't breaking AArch32 VMs, only augmenting behavior for AArch64, it seems OK. But I would genuinely love to be wrong on this topic too. I just don't have perspective on AArch32 users so it is hard to really say whether this is something they need as well. -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 836EFC433F5 for ; Thu, 24 Mar 2022 23:02:59 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XKhkoxcgtafR2qUIDKyiJeu0Zw6qXSBRHOoTsI1sNJs=; b=uGL4ONJx7uIgYt nHZA45o2UnVp5jNU+FAYtpuI4SKQdylNuuJMliJDs4/dyHZ9n0DwE0+NuXnYNMKPWeae1a18QtueX 7MaoyiXWwbX5lvGnEYonXhEgjdT/KCvEEzkl40T56SXTsVMIXXatsMpLtWNxWUJyi3RiQz/caqsIv Ctkx+QLoCEzV+4S8hubIiL87pdfVdC1JOjVn2lj0PsG4uUVK64lkJwTRnBwRsHdVhi6/khhPmIzQQ 1mCHuHDBtJ+xxdwTgC/x7dDSozmDsRcf8ebjB5373Ml3kPaEYUrL6cOuE5ueTn5v9if8XtYh5ou/+ MNPjlMjLk2KQ818e7hCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nXWSb-000Ve5-ND; Thu, 24 Mar 2022 23:01:41 +0000 Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nXWSY-000VdG-2A for linux-arm-kernel@lists.infradead.org; Thu, 24 Mar 2022 23:01:39 +0000 Received: by mail-il1-x133.google.com with SMTP id i12so4175396ilu.5 for ; Thu, 24 Mar 2022 16:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gFsgyLr9ZtY3CsTFCFwPED/ZztahOm1f0K0B19xBX3w=; b=kH0v456Gt3P/aaiK1WD+pFZmD9Gp500hFIgXBeuKEOsibDtVkcQ5MS5bkseEn3PwHO lMRAf8PprVMJiIsuTtIjMPYVLd178OLFNq5YXov60sLQbgTcptsgHQ71qQWKxpXJ+ZkR gFh9oC6cAbkt3OR5dp4jsY32eonP7c6a8U88vxJUKD2tXRWR0Xl6tWSPCXYEmL2nC6dj HHyWjN+DMwyjhUHiOlPaEoNqs4n5eXaX/dXqyKMw8f5Tig2q7G8un89ZsicqjxlcTNlF ZfFplWKPp+SZ0xzaIW6fpNVEFoGAk91tasISQvMSIcCRWvHzzdDKwXmgV4CsJ566xWx4 FQPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gFsgyLr9ZtY3CsTFCFwPED/ZztahOm1f0K0B19xBX3w=; b=eKLO60vma1UQ4cJcquC9ACnKrtPV1U3+3RESzAfBS+7iZrvqfpxXVqJkyVxVoSvXuZ tGIzgWgK+Yah5oSnNBlPPlT5u0z66aynhBrizICDCWlwmiXLttUctGKrC599pXiGTT3P /ZGTECFTfrs+SOTZmfpp7gbZa3jq5oq0BesjRm3iuhAeQYN/m3DOMt0JfmwVX2+MVxtd z8US+LpccMD3+eGK0s8ZJYpWxeElDi0CfVQMYyNEjfpoijkogTeR8XZI8EgYOE/lglkM 8uUforVSQ53QdK8JxIGlpDhVb/B9QNZaf7dXWa4lgsvC1RQGvrY3IkAFY4CRIo1DxyDs S1xQ== X-Gm-Message-State: AOAM532djeQTfEBsmxy2Ie5zkSwiiIzI8VXC+2/vi6AXaIWQfMHtC4GM c6qxzc+JXE1M+gqc70/bNdE6Ag== X-Google-Smtp-Source: ABdhPJx2bRtFRweMkEdLStxBpCpfXVRg/31TxuTxppv+RqiYB6T4/Iszjoin9ITToDSMnv+L9FMkEw== X-Received: by 2002:a05:6e02:1ba8:b0:2c8:218a:24bd with SMTP id n8-20020a056e021ba800b002c8218a24bdmr3897140ili.198.1648162893098; Thu, 24 Mar 2022 16:01:33 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id q9-20020a5edb09000000b00645c7a00cbbsm1978604iop.20.2022.03.24.16.01.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 16:01:32 -0700 (PDT) Date: Thu, 24 Mar 2022 23:01:29 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Fuad Tabba , Peng Liang , Peter Shier , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-12-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220324_160138_116794_9D0B8D4D X-CRM114-Status: GOOD ( 38.75 ) 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 On Thu, Mar 24, 2022 at 01:23:42PM -0700, Reiji Watanabe wrote: > Hi Oliver, > > On Wed, Mar 23, 2022 at 12:53 PM Oliver Upton wrote: > > > > Hi Reiji, > > > > On Thu, Mar 10, 2022 at 08:47:57PM -0800, Reiji Watanabe wrote: > > > Add hidden or reserved ID registers, and remaining ID registers, > > > which don't require special handling, to id_reg_desc_table. > > > Add 'flags' field to id_reg_desc, which is used to indicates hiddden > > > or reserved registers. Since now id_reg_desc_init() is called even > > > for hidden/reserved registers, change it to not do anything for them. > > > > > > Signed-off-by: Reiji Watanabe > > > > I think there is a very important detail of the series that probably > > should be highlighted. We are only allowing AArch64 feature registers to > > be configurable, right? AArch32 feature registers remain visible with > > their default values passed through to the guest. If you've already > > stated this as a precondition elsewhere then my apologies for the noise. > > > > I don't know if adding support for this to AArch32 registers is > > necessarily the right step forward, either. 32 bit support is working > > just fine and IMO its OK to limit new KVM features to AArch64-only so > > long as it doesn't break 32 bit support. Marc of course is the authority > > on that, though :-) > > > > If for any reason a guest uses a feature present in the AArch32 feature > > register but hidden from the AArch64 register, we could be in a > > particularly difficult position. Especially if we enabled traps based on > > the AArch64 value and UNDEF the guest. > > > > One hack we could do is skip trap configuration if AArch32 is visible at > > either EL1 or EL0, but that may not be the most elegant solution. > > Otherwise, if we are AArch64-only at every EL then the definition of the > > AArch32 feature registers is architecturally UNKNOWN, so we can dodge > > the problem altogether. What are your thoughts? > > Thank you so much for your review, Oliver! > > For aarch32 guests (when KVM_ARM_VCPU_EL1_32BIT is configured), > yes, the current series is problematic as you mentioned... > I am thinking of disallowing configuring ID registers (keep ID > registers immutable) for the aarch32 guests for now at least. > (will document that) That fixes it halfway, but the AArch64 views of the AArch32 feature registers have meaning even if AArch32 is defined at EL0. The only time they are architecturally UNKNOWN is if AArch32 is not implemented at any EL visible to the guest. So, given that: > For aarch64 guests that support EL0 aarch32, it would generally > be a userspace bug if userspace sets inconsistent values in 32bit > and 64bit ID registers. KVM doesn't provide a complete consistency > checking for ID registers, but this could be added later as needed. I completely agree that there is a large set of things that can be swept under the rug of userspace bugs. If we are going to do that, we need to strongly assert that configurable feature registers is only for fully AArch64-only guests. Additionally, strong documentation around these expectations is required. Mind you, these opinions are my own and IDK how others or Marc feel about it. My read of the situation w.r.t. the AArch32 registers is that it will become a mess to implement on top of the AArch64 registers. Given the fact that we aren't breaking AArch32 VMs, only augmenting behavior for AArch64, it seems OK. But I would genuinely love to be wrong on this topic too. I just don't have perspective on AArch32 users so it is hard to really say whether this is something they need as well. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel