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