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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DCAEC433F5 for ; Sun, 17 Oct 2021 04:44:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4616360F9E for ; Sun, 17 Oct 2021 04:44:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241437AbhJQEqV (ORCPT ); Sun, 17 Oct 2021 00:46:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232228AbhJQEqS (ORCPT ); Sun, 17 Oct 2021 00:46:18 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 395C0C061765 for ; Sat, 16 Oct 2021 21:44:09 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id t11so9005942plq.11 for ; Sat, 16 Oct 2021 21:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y8hxkkjC59Lk20UqzTDUhRF4a3QLCPerXoGaMuMIfbA=; b=T+yExjczlNVce32AnKsOADeGvIvc9/hmv9tJkGiZ38+EWDlFw7dH0wi3W76abD1qyo 0kK2PgXS2Xxrlf4mC8oqUQNcm5dP5/Iq115Yus8QGdF+vhFKhVAFMffRLbv25M4OkojR QQfbYmm86orFpJ5wuDeeOqL9fhlXeXzK89Ijh2BW2FmI1a7X4LE1Wd8/XVSlQkDtXrhB /BWkmbswgoRE7nvPdb4MT129rJo0JtNFdJFEX40I2JxfBD5lPbWusu3UbbZGTRuyl1sD Mcl+oaeIjpHFsSe75mZFb12Gh8kP6yV+xCQxQVU3+LwC655JurIhP8Ygg8T+qGAkT9Kd akIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y8hxkkjC59Lk20UqzTDUhRF4a3QLCPerXoGaMuMIfbA=; b=YS3qV/p/6BqtYY4vHMGahRt5Y9EKm5Z6pyFdv/Ay7lnpnbU1/kZe8QWs3NTpmrum7P bsLVMMaVovYBXmBVtuzYbXIbViP7jwBN8wCCP55FUyykz1cWBVwQzuUrJSpbYUAbS8Ua fgMvxhC6o6nvFxJPu1Ytq0RvkhCpLGQ/Y1BteXD7NWwgb2qiHLVDWzJzY2/7tm6n/Q0s Lt98EZ8X4yTHoRyfTj7loZ2ibHzEENz1LDO8rWTkOZxpfZ0XV4mWO6nPLdVwWZZIqiro vkfNGvcjVFTML9HFE279wGqdw72h564iG/FFsdyhIKAQvh3DLX8LjsXRj9lbU9advjQ5 z5Ew== X-Gm-Message-State: AOAM530VM3F7E/bKiPGUz8b0SpTk7MRabzLcK1l3NIY9M1Z9aym4He20 9WBDo56c5xbrmXoX9GOikZbNf2FiSuXY8ZzAnm69RQ== X-Google-Smtp-Source: ABdhPJyKMiTmY39aaGR53moXzMQSfsCG990gr+68UwPJI39g1bF/oHnDrzgDbR9D57bdYzAnc0v/bWSYRHrmATRzOTM= X-Received: by 2002:a17:90b:38c3:: with SMTP id nn3mr25207656pjb.110.1634445848472; Sat, 16 Oct 2021 21:44:08 -0700 (PDT) MIME-Version: 1.0 References: <20211012043535.500493-1-reijiw@google.com> <20211012043535.500493-5-reijiw@google.com> <20211015134741.b7jahdmypu6tqkt2@gator> In-Reply-To: <20211015134741.b7jahdmypu6tqkt2@gator> From: Reiji Watanabe Date: Sat, 16 Oct 2021 21:43:52 -0700 Message-ID: Subject: Re: [RFC PATCH 04/25] KVM: arm64: Introduce struct id_reg_info To: Andrew Jones 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 , Peng Liang , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Raghavendra Rao Anata Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -263,6 +263,76 @@ static bool trap_raz_wi(struct kvm_vcpu *vcpu, > > return read_zero(vcpu, p); > > } > > > > +struct id_reg_info { > > + u32 sys_reg; /* Register ID */ > > + u64 sys_val; /* Sanitized system value */ > > + > > + /* > > + * Limit value of the register for a vcpu. The value is sys_val > > + * with bits cleared for unsupported features for the guest. > > + */ > > + u64 vcpu_limit_val; > > Maybe I'll see a need for both later, but at the moment I'd think we only > need sys_val with the bits cleared for disabled features. Uh, yes, sys_val is used in patch-15 and I should have introduced the field in the patch. I will fix it in v2. > > -static int __set_id_reg(const struct kvm_vcpu *vcpu, > > +static int __set_id_reg(struct kvm_vcpu *vcpu, > > const struct sys_reg_desc *rd, void __user *uaddr, > > bool raz) > > { > > const u64 id = sys_reg_to_index(rd); > > + u32 encoding = reg_to_encoding(rd); > > int err; > > u64 val; > > > > @@ -1252,10 +1327,18 @@ static int __set_id_reg(const struct kvm_vcpu *vcpu, > > if (err) > > return err; > > > > - /* This is what we mean by invariant: you can't change it. */ > > - if (val != read_id_reg(vcpu, rd, raz)) > > + /* Don't allow to change the reg unless the reg has id_reg_info */ > > + if (val != read_id_reg(vcpu, rd, raz) && !GET_ID_REG_INFO(encoding)) > > return -EINVAL; > > > > + if (raz) > > + return (val == 0) ? 0 : -EINVAL; > > This is already covered by the val != read_id_reg(vcpu, rd, raz) check. Yes, it can simply return 0 for raz case in this patch. I will fix this in v2. > > + err = validate_id_reg(vcpu, rd, val); > > + if (err) > > + return err; > > + > > + __vcpu_sys_reg(vcpu, IDREG_SYS_IDX(encoding)) = val; > > return 0; > > } > > > > @@ -2818,6 +2901,23 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) > > return write_demux_regids(uindices); > > } > > > > +static void id_reg_info_init_all(void) > > +{ > > + int i; > > + struct id_reg_info *id_reg; > > + > > + for (i = 0; i < ARRAY_SIZE(id_reg_info_table); i++) { > > + id_reg = (struct id_reg_info *)id_reg_info_table[i]; > > + if (!id_reg) > > + continue; > > + > > + if (id_reg->init) > > + id_reg->init(id_reg); > > + else > > + id_reg_info_init(id_reg); > > Maybe call id_reg->init(id_reg) from within id_reg_info_init() in case we > wanted to apply some common id register initialization at some point? Thank you for the nice suggestion. That sounds like a better idea. I'll look into fixing it in v2. Thanks, Reiji 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57C1BC433FE for ; Sun, 17 Oct 2021 04:44:14 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id BD51E610E8 for ; Sun, 17 Oct 2021 04:44:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BD51E610E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 351144B119; Sun, 17 Oct 2021 00:44:13 -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 Xe+g7jM-Y7Zk; Sun, 17 Oct 2021 00:44:12 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id F37A84B0F7; Sun, 17 Oct 2021 00:44:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CB3DD4B0E1 for ; Sun, 17 Oct 2021 00:44:10 -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 CL7295yQjm1u for ; Sun, 17 Oct 2021 00:44:09 -0400 (EDT) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id A00C24B0DF for ; Sun, 17 Oct 2021 00:44:09 -0400 (EDT) Received: by mail-pl1-f182.google.com with SMTP id 21so8994828plo.13 for ; Sat, 16 Oct 2021 21:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y8hxkkjC59Lk20UqzTDUhRF4a3QLCPerXoGaMuMIfbA=; b=T+yExjczlNVce32AnKsOADeGvIvc9/hmv9tJkGiZ38+EWDlFw7dH0wi3W76abD1qyo 0kK2PgXS2Xxrlf4mC8oqUQNcm5dP5/Iq115Yus8QGdF+vhFKhVAFMffRLbv25M4OkojR QQfbYmm86orFpJ5wuDeeOqL9fhlXeXzK89Ijh2BW2FmI1a7X4LE1Wd8/XVSlQkDtXrhB /BWkmbswgoRE7nvPdb4MT129rJo0JtNFdJFEX40I2JxfBD5lPbWusu3UbbZGTRuyl1sD Mcl+oaeIjpHFsSe75mZFb12Gh8kP6yV+xCQxQVU3+LwC655JurIhP8Ygg8T+qGAkT9Kd akIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y8hxkkjC59Lk20UqzTDUhRF4a3QLCPerXoGaMuMIfbA=; b=dqFJk/KYO8o5bkGTd0H+ZZaRMhNa3kz+H0qRppWs5051AnU2WdiAhLnJwX2wffcLAr K053v5VIaFAz9D9Pw2iGTUFESqXqm8LhObcZ3KqjYpMGlmRst/A53jpsxP0YHFJQAY1r DgHBWm6eZ/kVKElx4Swhn7ZY8b4xszCAIc6TwU29R1vBhMuhWBWVHW9494pa+0YmH08j KIpPX4wgvRpPMbmzsXxKDayD2GAWo3M+wCIdArXcwKx99AhX3n+qtOvbwyi/mSTEvLtp tY/6P5id1VIedn89jIFMeZiiRCY2vNDQ6kkrMFuDc1zLGqJzAtWf99GfWwzvWt6I5bBV ucSA== X-Gm-Message-State: AOAM533Z8R5PmtUdADyNs4NcIsia9X+tIEua6XArpJLKenCnWaiq76+b hkWHXcwnBytipDzODXootK+g4H1wsQNZG7rYf7hYzA== X-Google-Smtp-Source: ABdhPJyKMiTmY39aaGR53moXzMQSfsCG990gr+68UwPJI39g1bF/oHnDrzgDbR9D57bdYzAnc0v/bWSYRHrmATRzOTM= X-Received: by 2002:a17:90b:38c3:: with SMTP id nn3mr25207656pjb.110.1634445848472; Sat, 16 Oct 2021 21:44:08 -0700 (PDT) MIME-Version: 1.0 References: <20211012043535.500493-1-reijiw@google.com> <20211012043535.500493-5-reijiw@google.com> <20211015134741.b7jahdmypu6tqkt2@gator> In-Reply-To: <20211015134741.b7jahdmypu6tqkt2@gator> From: Reiji Watanabe Date: Sat, 16 Oct 2021 21:43:52 -0700 Message-ID: Subject: Re: [RFC PATCH 04/25] KVM: arm64: Introduce struct id_reg_info To: Andrew Jones 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 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -263,6 +263,76 @@ static bool trap_raz_wi(struct kvm_vcpu *vcpu, > > return read_zero(vcpu, p); > > } > > > > +struct id_reg_info { > > + u32 sys_reg; /* Register ID */ > > + u64 sys_val; /* Sanitized system value */ > > + > > + /* > > + * Limit value of the register for a vcpu. The value is sys_val > > + * with bits cleared for unsupported features for the guest. > > + */ > > + u64 vcpu_limit_val; > > Maybe I'll see a need for both later, but at the moment I'd think we only > need sys_val with the bits cleared for disabled features. Uh, yes, sys_val is used in patch-15 and I should have introduced the field in the patch. I will fix it in v2. > > -static int __set_id_reg(const struct kvm_vcpu *vcpu, > > +static int __set_id_reg(struct kvm_vcpu *vcpu, > > const struct sys_reg_desc *rd, void __user *uaddr, > > bool raz) > > { > > const u64 id = sys_reg_to_index(rd); > > + u32 encoding = reg_to_encoding(rd); > > int err; > > u64 val; > > > > @@ -1252,10 +1327,18 @@ static int __set_id_reg(const struct kvm_vcpu *vcpu, > > if (err) > > return err; > > > > - /* This is what we mean by invariant: you can't change it. */ > > - if (val != read_id_reg(vcpu, rd, raz)) > > + /* Don't allow to change the reg unless the reg has id_reg_info */ > > + if (val != read_id_reg(vcpu, rd, raz) && !GET_ID_REG_INFO(encoding)) > > return -EINVAL; > > > > + if (raz) > > + return (val == 0) ? 0 : -EINVAL; > > This is already covered by the val != read_id_reg(vcpu, rd, raz) check. Yes, it can simply return 0 for raz case in this patch. I will fix this in v2. > > + err = validate_id_reg(vcpu, rd, val); > > + if (err) > > + return err; > > + > > + __vcpu_sys_reg(vcpu, IDREG_SYS_IDX(encoding)) = val; > > return 0; > > } > > > > @@ -2818,6 +2901,23 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) > > return write_demux_regids(uindices); > > } > > > > +static void id_reg_info_init_all(void) > > +{ > > + int i; > > + struct id_reg_info *id_reg; > > + > > + for (i = 0; i < ARRAY_SIZE(id_reg_info_table); i++) { > > + id_reg = (struct id_reg_info *)id_reg_info_table[i]; > > + if (!id_reg) > > + continue; > > + > > + if (id_reg->init) > > + id_reg->init(id_reg); > > + else > > + id_reg_info_init(id_reg); > > Maybe call id_reg->init(id_reg) from within id_reg_info_init() in case we > wanted to apply some common id register initialization at some point? Thank you for the nice suggestion. That sounds like a better idea. I'll look into fixing it in v2. Thanks, Reiji _______________________________________________ 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD4ABC433EF for ; Sun, 17 Oct 2021 04:45:57 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 9980660F8F for ; Sun, 17 Oct 2021 04:45:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9980660F8F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hUf8CJPx+d/F6LiuCAz2xVriTQVJc6eLRU9NQKbSucQ=; b=nVbYXJnGVwpr91 Ez+/oyOWDnkAXGGbVb1hIyNr5QCgdx3tyAulmBm8y/Z+no05/J4smi7sEGhB//05ZhCRDwUavc3ra FvnB7EkAt4b9VJoeLj0nRXZNYG3dhlE2Jflie3lyWvxXUrDI870K4S3NM/kk7ani/y4hHXjpz+3rC 13TSvElj/VI2R0ESyBfgW3d8zMvxkx/dEUE/wegqLLP7T4IwsV2vOx9jwL/U0oI+WrquIU01RXVFu MhTItmoZwo1RBKispuFAQPfjgHSfNyGnJZnMXudqxgrSgdUENCe1JaNEUOstIMsoBUQ3oo5r0pI3Z sl1dTabKayRkn/a7B0UQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mby1t-00BkqA-3a; Sun, 17 Oct 2021 04:44:13 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mby1q-00Bkpl-3R for linux-arm-kernel@lists.infradead.org; Sun, 17 Oct 2021 04:44:11 +0000 Received: by mail-pj1-x102f.google.com with SMTP id q10-20020a17090a1b0a00b001a076a59640so9203549pjq.0 for ; Sat, 16 Oct 2021 21:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y8hxkkjC59Lk20UqzTDUhRF4a3QLCPerXoGaMuMIfbA=; b=T+yExjczlNVce32AnKsOADeGvIvc9/hmv9tJkGiZ38+EWDlFw7dH0wi3W76abD1qyo 0kK2PgXS2Xxrlf4mC8oqUQNcm5dP5/Iq115Yus8QGdF+vhFKhVAFMffRLbv25M4OkojR QQfbYmm86orFpJ5wuDeeOqL9fhlXeXzK89Ijh2BW2FmI1a7X4LE1Wd8/XVSlQkDtXrhB /BWkmbswgoRE7nvPdb4MT129rJo0JtNFdJFEX40I2JxfBD5lPbWusu3UbbZGTRuyl1sD Mcl+oaeIjpHFsSe75mZFb12Gh8kP6yV+xCQxQVU3+LwC655JurIhP8Ygg8T+qGAkT9Kd akIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y8hxkkjC59Lk20UqzTDUhRF4a3QLCPerXoGaMuMIfbA=; b=j/tFvV2NRXzhWdQuZ8bZ/F7jsmUWhUENK89dSFqkbA9SwAVqwed72cZr3BtSlI2jWI kb3KRf6p9HEk+wB4pln6AU1pA7BMcjBcltebx0jjcIcvsA205M+YwGottroxp3Vd02gZ 9pXMsWrIcXe0dZquZJkYkV9xSdLlhaCovDdmbwMdhf+lS88MvUt2OtqNx2MaTmBTUhwm Hy91oke1yNazE+FL/vW2vZkRVFXymvUfpx16KTWKKfYlanvFUUPLRw0kHbbhaqqk8SEY n7f1ekSSRh9jQNsQgfEpRrMztgkhO30TWprXakKVnil5tGgGOYEsqA6Zos/al1xZgTUq 99hA== X-Gm-Message-State: AOAM533VFP/YBvnSzNFCsQkkk9WXqCqz8vs6C+oGlrN6LM71VRaSi7GX urtaW6M/x0a4tBTEasvGqj5FOML7I/561gwlVHE0vg== X-Google-Smtp-Source: ABdhPJyKMiTmY39aaGR53moXzMQSfsCG990gr+68UwPJI39g1bF/oHnDrzgDbR9D57bdYzAnc0v/bWSYRHrmATRzOTM= X-Received: by 2002:a17:90b:38c3:: with SMTP id nn3mr25207656pjb.110.1634445848472; Sat, 16 Oct 2021 21:44:08 -0700 (PDT) MIME-Version: 1.0 References: <20211012043535.500493-1-reijiw@google.com> <20211012043535.500493-5-reijiw@google.com> <20211015134741.b7jahdmypu6tqkt2@gator> In-Reply-To: <20211015134741.b7jahdmypu6tqkt2@gator> From: Reiji Watanabe Date: Sat, 16 Oct 2021 21:43:52 -0700 Message-ID: Subject: Re: [RFC PATCH 04/25] KVM: arm64: Introduce struct id_reg_info To: Andrew Jones 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 , Peng Liang , Peter Shier , Ricardo Koller , Oliver Upton , Jing Zhang , Raghavendra Rao Anata X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211016_214410_212148_FEAE608E X-CRM114-Status: GOOD ( 25.00 ) 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 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -263,6 +263,76 @@ static bool trap_raz_wi(struct kvm_vcpu *vcpu, > > return read_zero(vcpu, p); > > } > > > > +struct id_reg_info { > > + u32 sys_reg; /* Register ID */ > > + u64 sys_val; /* Sanitized system value */ > > + > > + /* > > + * Limit value of the register for a vcpu. The value is sys_val > > + * with bits cleared for unsupported features for the guest. > > + */ > > + u64 vcpu_limit_val; > > Maybe I'll see a need for both later, but at the moment I'd think we only > need sys_val with the bits cleared for disabled features. Uh, yes, sys_val is used in patch-15 and I should have introduced the field in the patch. I will fix it in v2. > > -static int __set_id_reg(const struct kvm_vcpu *vcpu, > > +static int __set_id_reg(struct kvm_vcpu *vcpu, > > const struct sys_reg_desc *rd, void __user *uaddr, > > bool raz) > > { > > const u64 id = sys_reg_to_index(rd); > > + u32 encoding = reg_to_encoding(rd); > > int err; > > u64 val; > > > > @@ -1252,10 +1327,18 @@ static int __set_id_reg(const struct kvm_vcpu *vcpu, > > if (err) > > return err; > > > > - /* This is what we mean by invariant: you can't change it. */ > > - if (val != read_id_reg(vcpu, rd, raz)) > > + /* Don't allow to change the reg unless the reg has id_reg_info */ > > + if (val != read_id_reg(vcpu, rd, raz) && !GET_ID_REG_INFO(encoding)) > > return -EINVAL; > > > > + if (raz) > > + return (val == 0) ? 0 : -EINVAL; > > This is already covered by the val != read_id_reg(vcpu, rd, raz) check. Yes, it can simply return 0 for raz case in this patch. I will fix this in v2. > > + err = validate_id_reg(vcpu, rd, val); > > + if (err) > > + return err; > > + > > + __vcpu_sys_reg(vcpu, IDREG_SYS_IDX(encoding)) = val; > > return 0; > > } > > > > @@ -2818,6 +2901,23 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) > > return write_demux_regids(uindices); > > } > > > > +static void id_reg_info_init_all(void) > > +{ > > + int i; > > + struct id_reg_info *id_reg; > > + > > + for (i = 0; i < ARRAY_SIZE(id_reg_info_table); i++) { > > + id_reg = (struct id_reg_info *)id_reg_info_table[i]; > > + if (!id_reg) > > + continue; > > + > > + if (id_reg->init) > > + id_reg->init(id_reg); > > + else > > + id_reg_info_init(id_reg); > > Maybe call id_reg->init(id_reg) from within id_reg_info_init() in case we > wanted to apply some common id register initialization at some point? Thank you for the nice suggestion. That sounds like a better idea. I'll look into fixing it in v2. Thanks, Reiji _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel