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 381BCC433EF for ; Thu, 24 Mar 2022 17:54:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8DD134B119; Thu, 24 Mar 2022 13:54:56 -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 hqqGeLXCZpyF; Thu, 24 Mar 2022 13:54:55 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 498394B0E6; Thu, 24 Mar 2022 13:54:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2204F4B0D6 for ; Thu, 24 Mar 2022 13:54:54 -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 3zhsbRYwOwPM for ; Thu, 24 Mar 2022 13:54:53 -0400 (EDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 0CB7E49E44 for ; Thu, 24 Mar 2022 13:54:52 -0400 (EDT) Received: by mail-io1-f43.google.com with SMTP id d62so6243796iog.13 for ; Thu, 24 Mar 2022 10:54:52 -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=gpG1idH+Yq/AlWXjwzOnwn1kVIZQXLkaIHYX97/MawQ=; b=MYpAl0OQXl6DvwrVD7oy+bSQQqNg8SzP7VXOO84WaYazJhr9XS2f5kxDw24CAaifTr XYAEnoOIj46wwuvT0rRDJAfb1aoGKUamh9vzpKSzPEOEY+bJYsaPhBoaINOBXhEmOAiw KiedNaBLZ3jdwTBxaM/VKdEvZdBAryD3zg3fpOvnZ4cB81KKHHb+eJhpWqpsj7Hn7cjJ m1i4GTvG4gz6KPMJIEu7blaa1fXR1yDB7K4DH0wCvMfRckd60AUbHwP+/DWoye89eoQc I7I5cSKenjipPbDxDB1h2Jg2wbo79tKxwivIUKIr25hGbyxwtosPkudzXi5SCnSnMA6G evRw== 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=gpG1idH+Yq/AlWXjwzOnwn1kVIZQXLkaIHYX97/MawQ=; b=4PJZH2Bz85jwhkr7jx9w/TVYzZgQJtAanQu7W03WK/xnp04Mg1JX1iKF9dUuP4X2/c cy3qIUYID21HxB3+SUl2cirlcpD8HLKJm9QhizxPYaDFs2y9d3HMArn/8+tGpFBDwU0S PXhSzWB8sGQXKwF0HxURx8Cec0I6yX7TTaS0jcSkzzzd3+8wJQ1ZpZ+G4HU7fzGHeBpC CTm1WFS3lbH1ZNOGW9LiSJBDgM5U4KYGwZ0QMJPErmVtQ30G/KOxtZl4kDbXQc58pe5D J/aFYCfc1zww3OlCSsgIr/C37gynAMsZXwWtOoGhva8uHEpQuagLywpVE4Gtlq1inW+W KIZg== X-Gm-Message-State: AOAM533KAKWPaMCOafIgc5RHHe1z/KHyNWCKFhdSSb6Ii6C1WD+EkACa yr1KHk18LYSlJleg+FfbnBPyNw== X-Google-Smtp-Source: ABdhPJzbnF79TQYRTFkOeaXA/rSl336nRsKoUTSPeMgbge7b88rutsAZOrGq0gv9kjT12x/P/sclOg== X-Received: by 2002:a05:6638:2651:b0:321:64e1:ef44 with SMTP id n17-20020a056638265100b0032164e1ef44mr3392957jat.202.1648144492021; Thu, 24 Mar 2022 10:54:52 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id i81-20020a6bb854000000b00649c1b67a6csm1740776iof.28.2022.03.24.10.54.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 10:54:51 -0700 (PDT) Date: Thu, 24 Mar 2022 17:54:48 +0000 From: Oliver Upton To: Reiji Watanabe Subject: Re: [PATCH v6 02/25] KVM: arm64: Save ID registers' sanitized value per guest Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-3-reijiw@google.com> <8adf6145-085e-9868-b2f8-65dfbdb5d88f@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8adf6145-085e-9868-b2f8-65dfbdb5d88f@google.com> Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Will Deacon , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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 Hi Reiji, On Thu, Mar 24, 2022 at 09:23:10AM -0700, Reiji Watanabe wrote: [...] > > > + */ > > > +#define KVM_ARM_ID_REG_MAX_NUM 64 > > > +#define IDREG_IDX(id) ((sys_reg_CRm(id) << 3) | sys_reg_Op2(id)) > > > + > > > struct kvm_arch { > > > struct kvm_s2_mmu mmu; > > > @@ -137,6 +144,9 @@ struct kvm_arch { > > > /* Memory Tagging Extension enabled for the guest */ > > > bool mte_enabled; > > > bool ran_once; > > > + > > > + /* ID registers for the guest. */ > > > + u64 id_regs[KVM_ARM_ID_REG_MAX_NUM]; > > > > This is a decently large array. Should we embed it in kvm_arch or > > allocate at init? > > > What is the reason why you think you might want to allocate it at init ? Well, its a 512 byte array of mostly cold data. We're probably convinced that the guest is going to access these registers at most once per vCPU at boot. For the vCPU context at least, we only allocate space for registers we actually care about (enum vcpu_sysreg). My impression of the feature register ranges is that there are a lot of registers which are RAZ, so I don't believe we need to make room for uninteresting values. Additionally, struct kvm is visible to EL2 if running nVHE. I don't believe hyp will ever need to look at these register values. [...] > > Which itself is dependent on whether KVM is going to sparsely or > > verbosely define its feature filtering tables per the other thread. So > > really only bother with this if that is the direction you're going. > > Even just going through for ID register ranges, we should do the check > to skip hidden/reserved ID registers (not to call read_sanitised_ftr_reg). > > Yes, it's certainly possible to avoid walking the entire system register, > and I will fix it. The reason why I didn't care it so much was just > because the code (walking the entire system register) will be removed by > the following patches:) Let me go through the series again and see how this flows. If there is a way to avoid rewriting code introduced earlier in the series I would suggest going that route. -- 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 2EDCEC433F5 for ; Thu, 24 Mar 2022 17:57:30 +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=sfkIAZFp6QyjSc55mKSyh9hRbHKUxynqRZuvTtiqgxc=; b=MqAIWCqmH6VdH1 Cxu843LgD7KH7J1bhN5c5l6x8wOlUdfKkyaAw3o5BKJRphql3pFJISQXUQebpLohFqPuztSHWmLDY ffgxAzaq/4ZOiPZlgL1/cNDcL7YNtH5fGRWYNgx9qloX1J+MU89I0gsoZo9eZ4sk3yQnXmY4iB2A1 /VuTwlmrmPVCs5UnYb4geQlZxrdF3d+E5umjlYWB6gLQhGCpeXKkbOHRzzCvaYHpNda8XSDfZtNOu MAxD0m1Yeat6RnChYgmNGrl2SUvcSCdZF9OtUL7M9DWmoo2at02L63XnBZRZ0cBL+1ldOTJfibuwY k50N7f7BneocYqB93FiA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nXRh3-00HTSQ-Bv; Thu, 24 Mar 2022 17:56:17 +0000 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nXRfh-00HSwf-Je for linux-arm-kernel@lists.infradead.org; Thu, 24 Mar 2022 17:54:55 +0000 Received: by mail-io1-xd2b.google.com with SMTP id b16so6300832ioz.3 for ; Thu, 24 Mar 2022 10:54:52 -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=gpG1idH+Yq/AlWXjwzOnwn1kVIZQXLkaIHYX97/MawQ=; b=MYpAl0OQXl6DvwrVD7oy+bSQQqNg8SzP7VXOO84WaYazJhr9XS2f5kxDw24CAaifTr XYAEnoOIj46wwuvT0rRDJAfb1aoGKUamh9vzpKSzPEOEY+bJYsaPhBoaINOBXhEmOAiw KiedNaBLZ3jdwTBxaM/VKdEvZdBAryD3zg3fpOvnZ4cB81KKHHb+eJhpWqpsj7Hn7cjJ m1i4GTvG4gz6KPMJIEu7blaa1fXR1yDB7K4DH0wCvMfRckd60AUbHwP+/DWoye89eoQc I7I5cSKenjipPbDxDB1h2Jg2wbo79tKxwivIUKIr25hGbyxwtosPkudzXi5SCnSnMA6G evRw== 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=gpG1idH+Yq/AlWXjwzOnwn1kVIZQXLkaIHYX97/MawQ=; b=ZYmzA6krG0GkQdmdpc1HESFy6MrmCGlS2c4pE56hvfbB8KmRP4wZz+kQNKnp/UTuxv jhGrPC1+Ec1rP1+jelPHFvdPeQctMfzXggUKaNimCPsqv+Wwt+GPpdV/BJ9Bu8Py9pu7 /WlCh+PasEmYFfwOXa/3UWZDeXKhaj2nrWaFXa3YlKrkdnJb/HBHPLp5ly0feuKS+iXl T4JBd7q2R5pxhLywsoOu4t3OMKT8hQRltzfvBizniAL14Ior/YNmLRqzoJF8mijUqtZ8 pmlJsn8aYcdePOVhziA53/OCZyBPgYRaawIMZxXSV24Zd2xNdwchsQlpzRhpImE90Gqt 6yEQ== X-Gm-Message-State: AOAM53137AdakQtsBALlBOEfw+IpDUwcM0XOVeoUu3WUVuwB8XowFlEz GrE0BYiwJ6esvSoGU5PT15TzJQ== X-Google-Smtp-Source: ABdhPJzbnF79TQYRTFkOeaXA/rSl336nRsKoUTSPeMgbge7b88rutsAZOrGq0gv9kjT12x/P/sclOg== X-Received: by 2002:a05:6638:2651:b0:321:64e1:ef44 with SMTP id n17-20020a056638265100b0032164e1ef44mr3392957jat.202.1648144492021; Thu, 24 Mar 2022 10:54:52 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id i81-20020a6bb854000000b00649c1b67a6csm1740776iof.28.2022.03.24.10.54.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 10:54:51 -0700 (PDT) Date: Thu, 24 Mar 2022 17:54:48 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 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 02/25] KVM: arm64: Save ID registers' sanitized value per guest Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-3-reijiw@google.com> <8adf6145-085e-9868-b2f8-65dfbdb5d88f@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8adf6145-085e-9868-b2f8-65dfbdb5d88f@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220324_105453_703318_AAD07FE5 X-CRM114-Status: GOOD ( 24.90 ) 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 Hi Reiji, On Thu, Mar 24, 2022 at 09:23:10AM -0700, Reiji Watanabe wrote: [...] > > > + */ > > > +#define KVM_ARM_ID_REG_MAX_NUM 64 > > > +#define IDREG_IDX(id) ((sys_reg_CRm(id) << 3) | sys_reg_Op2(id)) > > > + > > > struct kvm_arch { > > > struct kvm_s2_mmu mmu; > > > @@ -137,6 +144,9 @@ struct kvm_arch { > > > /* Memory Tagging Extension enabled for the guest */ > > > bool mte_enabled; > > > bool ran_once; > > > + > > > + /* ID registers for the guest. */ > > > + u64 id_regs[KVM_ARM_ID_REG_MAX_NUM]; > > > > This is a decently large array. Should we embed it in kvm_arch or > > allocate at init? > > > What is the reason why you think you might want to allocate it at init ? Well, its a 512 byte array of mostly cold data. We're probably convinced that the guest is going to access these registers at most once per vCPU at boot. For the vCPU context at least, we only allocate space for registers we actually care about (enum vcpu_sysreg). My impression of the feature register ranges is that there are a lot of registers which are RAZ, so I don't believe we need to make room for uninteresting values. Additionally, struct kvm is visible to EL2 if running nVHE. I don't believe hyp will ever need to look at these register values. [...] > > Which itself is dependent on whether KVM is going to sparsely or > > verbosely define its feature filtering tables per the other thread. So > > really only bother with this if that is the direction you're going. > > Even just going through for ID register ranges, we should do the check > to skip hidden/reserved ID registers (not to call read_sanitised_ftr_reg). > > Yes, it's certainly possible to avoid walking the entire system register, > and I will fix it. The reason why I didn't care it so much was just > because the code (walking the entire system register) will be removed by > the following patches:) Let me go through the series again and see how this flows. If there is a way to avoid rewriting code introduced earlier in the series I would suggest going that route. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 141DAC433EF for ; Thu, 24 Mar 2022 17:54:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351059AbiCXR4Z (ORCPT ); Thu, 24 Mar 2022 13:56:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343825AbiCXR4Z (ORCPT ); Thu, 24 Mar 2022 13:56:25 -0400 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC4F8B53F3 for ; Thu, 24 Mar 2022 10:54:52 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id c23so6281568ioi.4 for ; Thu, 24 Mar 2022 10:54:52 -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=gpG1idH+Yq/AlWXjwzOnwn1kVIZQXLkaIHYX97/MawQ=; b=MYpAl0OQXl6DvwrVD7oy+bSQQqNg8SzP7VXOO84WaYazJhr9XS2f5kxDw24CAaifTr XYAEnoOIj46wwuvT0rRDJAfb1aoGKUamh9vzpKSzPEOEY+bJYsaPhBoaINOBXhEmOAiw KiedNaBLZ3jdwTBxaM/VKdEvZdBAryD3zg3fpOvnZ4cB81KKHHb+eJhpWqpsj7Hn7cjJ m1i4GTvG4gz6KPMJIEu7blaa1fXR1yDB7K4DH0wCvMfRckd60AUbHwP+/DWoye89eoQc I7I5cSKenjipPbDxDB1h2Jg2wbo79tKxwivIUKIr25hGbyxwtosPkudzXi5SCnSnMA6G evRw== 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=gpG1idH+Yq/AlWXjwzOnwn1kVIZQXLkaIHYX97/MawQ=; b=4vvDtqTcbOkCPwZJdt9BwbPWDiNBrmHsWsbzIz26N328CI7WEUzG/pM354+eRDxchZ BM92UFOMTu6jFlKxc8yVK0rjziz4UbQRKLm/nF9IAV6ncnhMNLE07qQgqB2lD6JVlxr4 vy1rmPwNTamsg47vs3P1eBKbWxl5lo4+gLAc+TBP+Lof9p6r5bEWSdiSyAaeAmudHlRr sfOdeCx+jFkVjilv8lnOSCdyMSt0rAPJxx0wD5xgszFDOrfT/3zlaSSFrV87ZGW7Y91/ v1ukpVHYYJ6Md4li99UG4AQEX9vDmijeXdqnmKG+HnZ/ip5qJsqi/GSzp+Qd4biHa3PX R1Mw== X-Gm-Message-State: AOAM531wTvtKvi/zCBeHgiZhGYsf8pbeLVtg6+dF3bsgtN/NqpN6eN2k MWpoZxmfmF1rwTMreKtCwLkC8g== X-Google-Smtp-Source: ABdhPJzbnF79TQYRTFkOeaXA/rSl336nRsKoUTSPeMgbge7b88rutsAZOrGq0gv9kjT12x/P/sclOg== X-Received: by 2002:a05:6638:2651:b0:321:64e1:ef44 with SMTP id n17-20020a056638265100b0032164e1ef44mr3392957jat.202.1648144492021; Thu, 24 Mar 2022 10:54:52 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id i81-20020a6bb854000000b00649c1b67a6csm1740776iof.28.2022.03.24.10.54.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 10:54:51 -0700 (PDT) Date: Thu, 24 Mar 2022 17:54:48 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 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 02/25] KVM: arm64: Save ID registers' sanitized value per guest Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-3-reijiw@google.com> <8adf6145-085e-9868-b2f8-65dfbdb5d88f@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8adf6145-085e-9868-b2f8-65dfbdb5d88f@google.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Reiji, On Thu, Mar 24, 2022 at 09:23:10AM -0700, Reiji Watanabe wrote: [...] > > > + */ > > > +#define KVM_ARM_ID_REG_MAX_NUM 64 > > > +#define IDREG_IDX(id) ((sys_reg_CRm(id) << 3) | sys_reg_Op2(id)) > > > + > > > struct kvm_arch { > > > struct kvm_s2_mmu mmu; > > > @@ -137,6 +144,9 @@ struct kvm_arch { > > > /* Memory Tagging Extension enabled for the guest */ > > > bool mte_enabled; > > > bool ran_once; > > > + > > > + /* ID registers for the guest. */ > > > + u64 id_regs[KVM_ARM_ID_REG_MAX_NUM]; > > > > This is a decently large array. Should we embed it in kvm_arch or > > allocate at init? > > > What is the reason why you think you might want to allocate it at init ? Well, its a 512 byte array of mostly cold data. We're probably convinced that the guest is going to access these registers at most once per vCPU at boot. For the vCPU context at least, we only allocate space for registers we actually care about (enum vcpu_sysreg). My impression of the feature register ranges is that there are a lot of registers which are RAZ, so I don't believe we need to make room for uninteresting values. Additionally, struct kvm is visible to EL2 if running nVHE. I don't believe hyp will ever need to look at these register values. [...] > > Which itself is dependent on whether KVM is going to sparsely or > > verbosely define its feature filtering tables per the other thread. So > > really only bother with this if that is the direction you're going. > > Even just going through for ID register ranges, we should do the check > to skip hidden/reserved ID registers (not to call read_sanitised_ftr_reg). > > Yes, it's certainly possible to avoid walking the entire system register, > and I will fix it. The reason why I didn't care it so much was just > because the code (walking the entire system register) will be removed by > the following patches:) Let me go through the series again and see how this flows. If there is a way to avoid rewriting code introduced earlier in the series I would suggest going that route. -- Thanks, Oliver