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 4F29BC433EF for ; Wed, 23 Mar 2022 19:23:36 +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=uUs8cgxa7N7snMMp6eP/imAQhjBMeEmFWPwL4oMQFeQ=; b=nfrirbZJXPBcJb 8r/nDRXj+52wUWfIvH/xeqaTybYBeuCDpMmxl1HKvEnEVdfypvusx7AKaItRXFPe/pL8wjdr2XFAU LhQ+XzxaNYnZnz4ejv1bJUCH/K4P3/gAQexZDXkbG+UaM7JnS6S+552VZPHHREHrIyK2oPcGIDicE uM1j23rlXoxMLiqZTrKhsJUj2kG2zTlxP/XTUBkD4fnIwkeoVRDQq8/CFT7t2qnWyxrLcZ678h2Nv 0VAytUEmaT/ZMy0gXmXDu70UouE1n2Js3U6aD2gqosPY6PTW8ASnpWf/UKRc7tBoETk7of3S8PdK3 DEgPkNjUYA1H7mrIWFnw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nX6Yr-00EhcM-51; Wed, 23 Mar 2022 19:22:25 +0000 Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nX6Yo-00EhbN-32 for linux-arm-kernel@lists.infradead.org; Wed, 23 Mar 2022 19:22:23 +0000 Received: by mail-io1-xd32.google.com with SMTP id h63so2907174iof.12 for ; Wed, 23 Mar 2022 12:22:17 -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=JlMssrBS5MsWzr4IlAQ1DcKlCFmfRWojcGydLqsuTtY=; b=SMG6cDmX+eXpRQ94AqhVqDKxEoEuWDo5YwwCRBPkxeUSTJIBdfNA7sSU3zJkicwEgb aHqD6tW07HceqvJp6mNptONcqESdKtAJ4t4iK3VaQCsSF0JIO8nocEaUyLVKxno1lDKp 6jbLYrMGLdeGqdhZ7MJissy9yA8ijNrm81J9D8pA8iklFPVM1EdLrAGKIt4r+cOZDoq/ ZStvN0KQGX3lb7eNnqtliwowc3pZHjYv1PYJECBaXM0/o50dQdb25DOueNGYXNr9fPZp BMdZg0S7oX94Ty2B1QvUD17nhtXKWcKacDcl0Vr8Nix9ZDHa/GzSMHOmW+53X80mxxh1 lVgw== 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=JlMssrBS5MsWzr4IlAQ1DcKlCFmfRWojcGydLqsuTtY=; b=4beNRG1Ba35f9xpGLJ7Q3x3ywGUwC+j34PqFGyVhkn3B8db7gOpgQQPXR+GEvpKBzJ YcwiPuZlQIaOaD6g/i5lHziP9wptf8y6ApIv/tb4+/zggqm+iqASzy2WvPt1H6Fwa4A1 N4TOYsEZOiw4NjmAMoknhfMwCpb9AXuUTpXdGck2Y0/jhyAwe/rx1INmiUAMWG3WsbEx BnDTgfH64iTvaiLYIMTowb6zJlGCtD5K1YByhlPMB8TexJKEr4ninjWL5iafOGUsJGgu srhik+a8LhaaFryMEQ56QH6Tw76X6jPN+Z9Aa9qDqfze7QeOn/yztVw2SqwjoQso04wj Y2Mw== X-Gm-Message-State: AOAM532XHSXKL9i6laps0TnIt5RlcwURc8XyDPyJYFWFkOCkYxCrIznG EkPprnvoyk5AoCpAznkgbJ7ztQ== X-Google-Smtp-Source: ABdhPJwngJg/5LHhODSUq+zIVlvVV5bBB3J5MW1sVvzghvqD9c55m4X7Zxu6PadTGaeTnZhTx2kmgQ== X-Received: by 2002:a05:6602:1493:b0:649:1890:cffd with SMTP id a19-20020a056602149300b006491890cffdmr844378iow.167.1648063336566; Wed, 23 Mar 2022 12:22:16 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id d3-20020a056e020c0300b002c7b42b4b0esm422584ile.65.2022.03.23.12.22.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 12:22:15 -0700 (PDT) Date: Wed, 23 Mar 2022 19:22:12 +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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220311044811.1980336-3-reijiw@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220323_122222_162186_328B9404 X-CRM114-Status: GOOD ( 25.61 ) 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 10, 2022 at 08:47:48PM -0800, Reiji Watanabe wrote: > Introduce id_regs[] in kvm_arch as a storage of guest's ID registers, > and save ID registers' sanitized value in the array at KVM_CREATE_VM. > Use the saved ones when ID registers are read by the guest or > userspace (via KVM_GET_ONE_REG). > > Signed-off-by: Reiji Watanabe > --- > arch/arm64/include/asm/kvm_host.h | 12 ++++++ > arch/arm64/kvm/arm.c | 1 + > arch/arm64/kvm/sys_regs.c | 65 ++++++++++++++++++++++++------- > 3 files changed, 63 insertions(+), 15 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 2869259e10c0..c041e5afe3d2 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -101,6 +101,13 @@ struct kvm_s2_mmu { > struct kvm_arch_memory_slot { > }; > > +/* > + * (Op0, Op1, CRn, CRm, Op2) of ID registers is (3, 0, 0, crm, op2), > + * where 0<=crm<8, 0<=op2<8. Doesn't the Feature ID register scheme only apply to CRm={1-7}, op2={0-7}? I believe CRm=0, op2={1-4,7} are in fact UNDEFINED, not RAZ like the other ranges. Furthermore, the registers that are defined in that range do not go through the read_id_reg() plumbing. > + */ > +#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? [...] > + > +/* > + * Set the guest's ID registers that are defined in sys_reg_descs[] > + * with ID_SANITISED() to the host's sanitized value. > + */ > +void set_default_id_regs(struct kvm *kvm) nit, more relevant if you take the above suggestion: maybe call it kvm_init_id_regs()? > +{ > + int i; > + u32 id; > + const struct sys_reg_desc *rd; > + u64 val; > + > + for (i = 0; i < ARRAY_SIZE(sys_reg_descs); i++) { You could avoid walking the entire system register table, since we already know the start and end values for the Feature ID register range. maybe: #define FEATURE_ID_RANGE_START SYS_ID_PFR0_EL1 #define FEATURE_ID_RANGE_END sys_reg(3, 0, 0, 7, 7) u32 sys_reg; for (sys_reg = FEATURE_ID_RANGE_START; sys_reg <= FEATURE_ID_RANGE_END; sys_reg++) But, it depends on if this check is necessary: > + rd = &sys_reg_descs[i]; > + if (rd->access != access_id_reg) > + /* Not ID register, or hidden/reserved ID register */ > + continue; 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. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel