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 70015C433FE for ; Tue, 1 Feb 2022 14:14:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239121AbiBAOOa (ORCPT ); Tue, 1 Feb 2022 09:14:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239105AbiBAOO3 (ORCPT ); Tue, 1 Feb 2022 09:14:29 -0500 Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F08DC061714 for ; Tue, 1 Feb 2022 06:14:29 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id 4so9048285oil.11 for ; Tue, 01 Feb 2022 06:14:29 -0800 (PST) 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=1hzC5kA94MkC0GLnHZxQLOF3z9T2okGq6QSaPNCp6Bs=; b=L2rrAtc5Bxp1kiX/SmSs9h7mN4kqGARLQxGoLX7jPAkXCmRSfJBQH5H0sBqdQlsgE5 Og1UXoJb/lM+neYYXkS628jfo8p7TU1oQGNmBzw9MOB1AGiMuTh2Rl7Dmt0eE/WE7fqK KHQ1cX/6w79LsiyETQ8xapa+MEdHkJGtRxJISJc53WMvb5ycMhRPfDG2+gQ+Kvny+dP2 tnal53P+Se0y2F+vdwm3H3S7k3T37KHiD0w4nJfzGZnf2ctfncFrYWFHU17whfIU4FX0 y2U+Kcs+cRj/cZrZ2PeI35Wamsky4mnF61gWO/zgnjLZ1QggLCtFQ47yZOwBSlxJiEKM DKDw== 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=1hzC5kA94MkC0GLnHZxQLOF3z9T2okGq6QSaPNCp6Bs=; b=iEPtG1kvtipcC+o8DRjInzuFHFMrVMw8gmyfDEOSkLm6dLu/9//3AdwYs489M8xotf xqiNVainTC6YXriC/0p0jSKMU1Cadgsl3++BbLmRnK5QCMLC+BbjGPkI2fiPSakKVbJo Ke/lDc91VMUEWG5limhTJRPKF6ChNXmAklN486LKESspUWVvVQho1J/8sIvVde3Oz3Qp RIybB0WFr95x2OpsCg6bfCJdIJtieguTZScU5WbNgQzLnW3nBLmTKhhMhYkKrOwiL6uw YJtxF47RPkuL4uxBjC6c336GBjLnfZrVgWNWytCeoEXnV4G0onEOyCXlxStPDSiwm6RJ C6FQ== X-Gm-Message-State: AOAM532DEkO6DLH9u2Ast31F7ccSLNHUd6Y5rSdJCItRufvBKD5+06ir gRdcjF0oS8BT+NBRixkA8qP32VSTYXDKK21hDOpYEg== X-Google-Smtp-Source: ABdhPJyc+gLrzhK5McV1s3POSFDxJ0vZgQau3r0WA3lSzrJGO3Z4Wz+mvnT9IX4AKiE4COwrk9DKb/JyvxPHTu676A0= X-Received: by 2002:a05:6808:2394:: with SMTP id bp20mr1251698oib.171.1643724868554; Tue, 01 Feb 2022 06:14:28 -0800 (PST) MIME-Version: 1.0 References: <20220106042708.2869332-1-reijiw@google.com> <20220106042708.2869332-4-reijiw@google.com> In-Reply-To: From: Fuad Tabba Date: Tue, 1 Feb 2022 14:13:52 +0000 Message-ID: Subject: Re: [RFC PATCH v4 03/26] KVM: arm64: Introduce struct id_reg_info To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Will Deacon , Peter Shier , Paolo Bonzini , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Reiji, ... > > > @@ -2862,11 +3077,12 @@ void set_default_id_regs(struct kvm *kvm) > > > u32 id; > > > const struct sys_reg_desc *rd; > > > u64 val; > > > + struct id_reg_info *idr; > > > > > > for (i = 0; i < ARRAY_SIZE(sys_reg_descs); i++) { > > > rd = &sys_reg_descs[i]; > > > if (rd->access != access_id_reg) > > > - /* Not ID register, or hidden/reserved ID register */ > > > + /* Not ID register or hidden/reserved ID register */ > > > continue; > > > > > > id = reg_to_encoding(rd); > > > @@ -2874,7 +3090,8 @@ void set_default_id_regs(struct kvm *kvm) > > > /* Shouldn't happen */ > > > continue; > > > > > > - val = read_sanitised_ftr_reg(id); > > > - kvm->arch.id_regs[IDREG_IDX(id)] = val; > > > + idr = GET_ID_REG_INFO(id); > > > + val = idr ? idr->vcpu_limit_val : read_sanitised_ftr_reg(id); > > > + (void)write_kvm_id_reg(kvm, id, val); > > > > Rather than ignoring the return value of write_kvm_id_reg(), wouldn't > > it be better if set_default_id_regs were to propagate it back to > > kvm_arch_init_vm in case there's a problem? > > Since write_kvm_id_reg() should never return an error for this > case, returning an error to kvm_arch_init_vm() adds a practically > unnecessary error handling, which I would like to avoid. > So, how about putting WARN_ON_ONCE on its return value ? I think this makes sense in this case. Thanks, /fuad > 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EDE1C433EF for ; Tue, 1 Feb 2022 14:14:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EE02749F4E; Tue, 1 Feb 2022 09:14:31 -0500 (EST) 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 Kse+v8kUUrhs; Tue, 1 Feb 2022 09:14:30 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A574449F10; Tue, 1 Feb 2022 09:14:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4EC2149EFB for ; Tue, 1 Feb 2022 09:14:30 -0500 (EST) 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 9qloXIV-Ce19 for ; Tue, 1 Feb 2022 09:14:29 -0500 (EST) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 3226349EC2 for ; Tue, 1 Feb 2022 09:14:29 -0500 (EST) Received: by mail-oi1-f179.google.com with SMTP id x193so33629203oix.0 for ; Tue, 01 Feb 2022 06:14:29 -0800 (PST) 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=1hzC5kA94MkC0GLnHZxQLOF3z9T2okGq6QSaPNCp6Bs=; b=L2rrAtc5Bxp1kiX/SmSs9h7mN4kqGARLQxGoLX7jPAkXCmRSfJBQH5H0sBqdQlsgE5 Og1UXoJb/lM+neYYXkS628jfo8p7TU1oQGNmBzw9MOB1AGiMuTh2Rl7Dmt0eE/WE7fqK KHQ1cX/6w79LsiyETQ8xapa+MEdHkJGtRxJISJc53WMvb5ycMhRPfDG2+gQ+Kvny+dP2 tnal53P+Se0y2F+vdwm3H3S7k3T37KHiD0w4nJfzGZnf2ctfncFrYWFHU17whfIU4FX0 y2U+Kcs+cRj/cZrZ2PeI35Wamsky4mnF61gWO/zgnjLZ1QggLCtFQ47yZOwBSlxJiEKM DKDw== 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=1hzC5kA94MkC0GLnHZxQLOF3z9T2okGq6QSaPNCp6Bs=; b=lJzXx2xm+RYfYT5+KVoJQVRTLtIOrCd9mbxXscEPW8WvXXQtsFZ0srUy+5szpBrMSh gxrRe0S2weMyZKCT8hkS+WSbomHfaYztfjkuPomOZ6iQNIK2HxtoCkVMpMgdOBaA9Rrz CrSfQf4ycCNeyQ11IZeg4CaD8rMrVt7Gkxm/g74PklUMY0V7YfYiFo/yCpKJDOjSrLNI d9lyXRuYTewXH3KsYCUdtv0v8/PgtPnn9BSg/NR4DQVini1Z3e5NdN+Ju9WV/7L4uckj 6Dg/XjQ0ho3BuzWKCDWBDwJ3IfFcUXz1aSyC0C9YeKzDr4nU3bOv0Fv2jSKYV3J1JSEO ddjg== X-Gm-Message-State: AOAM533/l3i2aZQwLR8sUzsfHx1sO4e5EOsOnHANXlq8Jd+IQdYf1WcJ G6uMyQaOLlBUkTN/ZySrknJxIfy4qDOzo52x4mJSYg== X-Google-Smtp-Source: ABdhPJyc+gLrzhK5McV1s3POSFDxJ0vZgQau3r0WA3lSzrJGO3Z4Wz+mvnT9IX4AKiE4COwrk9DKb/JyvxPHTu676A0= X-Received: by 2002:a05:6808:2394:: with SMTP id bp20mr1251698oib.171.1643724868554; Tue, 01 Feb 2022 06:14:28 -0800 (PST) MIME-Version: 1.0 References: <20220106042708.2869332-1-reijiw@google.com> <20220106042708.2869332-4-reijiw@google.com> In-Reply-To: From: Fuad Tabba Date: Tue, 1 Feb 2022 14:13:52 +0000 Message-ID: Subject: Re: [RFC PATCH v4 03/26] KVM: arm64: Introduce struct id_reg_info To: Reiji Watanabe Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Paolo Bonzini , Will Deacon , 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 Hi Reiji, ... > > > @@ -2862,11 +3077,12 @@ void set_default_id_regs(struct kvm *kvm) > > > u32 id; > > > const struct sys_reg_desc *rd; > > > u64 val; > > > + struct id_reg_info *idr; > > > > > > for (i = 0; i < ARRAY_SIZE(sys_reg_descs); i++) { > > > rd = &sys_reg_descs[i]; > > > if (rd->access != access_id_reg) > > > - /* Not ID register, or hidden/reserved ID register */ > > > + /* Not ID register or hidden/reserved ID register */ > > > continue; > > > > > > id = reg_to_encoding(rd); > > > @@ -2874,7 +3090,8 @@ void set_default_id_regs(struct kvm *kvm) > > > /* Shouldn't happen */ > > > continue; > > > > > > - val = read_sanitised_ftr_reg(id); > > > - kvm->arch.id_regs[IDREG_IDX(id)] = val; > > > + idr = GET_ID_REG_INFO(id); > > > + val = idr ? idr->vcpu_limit_val : read_sanitised_ftr_reg(id); > > > + (void)write_kvm_id_reg(kvm, id, val); > > > > Rather than ignoring the return value of write_kvm_id_reg(), wouldn't > > it be better if set_default_id_regs were to propagate it back to > > kvm_arch_init_vm in case there's a problem? > > Since write_kvm_id_reg() should never return an error for this > case, returning an error to kvm_arch_init_vm() adds a practically > unnecessary error handling, which I would like to avoid. > So, how about putting WARN_ON_ONCE on its return value ? I think this makes sense in this case. Thanks, /fuad > 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 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 8B3B9C433EF for ; Tue, 1 Feb 2022 14:15:45 +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: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=L+ucO6LfMb+Q/HXcx9vO8RyyOSVFuHuzV6m3EE4ZDVs=; b=At+vuEcysbbW0I Yui09kPjwlmGBlTzrK3eD5T5OO/SstlH5tNHUL0zvbWTjapnZedZlXbjZ5I/DdP0yCPJ4418QnNwm J1ZWRlQj9krsYYHjY9B3VwSIZnLPQywWZ3Q4tZZzohLdhT7Gk2G3wbM1aUbJkT/icpOWvPtUKG98l KtG2JGCnebe8L/2DlTrrU4THeIkgFIwOBczE9Usb5VRf1MfVvxZ/DluYHFN9aTCeEgc3HPj9Ky/h3 xmsY7kzuufvD8x8YbtUcggSIFCkPU9+S3rWFqDdlOamxNv+b5qZw/8PdBA1F2/7kudx5eFDQvR5x6 l/QU0bjJ9TveqMqXNDZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nEtvU-00CPav-Ea; Tue, 01 Feb 2022 14:14:32 +0000 Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nEtvR-00CPa2-RY for linux-arm-kernel@lists.infradead.org; Tue, 01 Feb 2022 14:14:31 +0000 Received: by mail-oi1-x22e.google.com with SMTP id r27so11324615oiw.4 for ; Tue, 01 Feb 2022 06:14:29 -0800 (PST) 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=1hzC5kA94MkC0GLnHZxQLOF3z9T2okGq6QSaPNCp6Bs=; b=L2rrAtc5Bxp1kiX/SmSs9h7mN4kqGARLQxGoLX7jPAkXCmRSfJBQH5H0sBqdQlsgE5 Og1UXoJb/lM+neYYXkS628jfo8p7TU1oQGNmBzw9MOB1AGiMuTh2Rl7Dmt0eE/WE7fqK KHQ1cX/6w79LsiyETQ8xapa+MEdHkJGtRxJISJc53WMvb5ycMhRPfDG2+gQ+Kvny+dP2 tnal53P+Se0y2F+vdwm3H3S7k3T37KHiD0w4nJfzGZnf2ctfncFrYWFHU17whfIU4FX0 y2U+Kcs+cRj/cZrZ2PeI35Wamsky4mnF61gWO/zgnjLZ1QggLCtFQ47yZOwBSlxJiEKM DKDw== 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=1hzC5kA94MkC0GLnHZxQLOF3z9T2okGq6QSaPNCp6Bs=; b=017BAzgImFtRmki4TeJyTFvmeJGwki7jV0kgrRRVHJf7gcqxwbtDI5/x09O4KsiynN jDnPfLgY+Tj1ncDdlVy70I0NXHLhLGILG9pEC6K2ZWYcEQYICI4NWs3QFuWeVk/knJSc 14jKHHjmhkGVa5iqeXIlknyLVeG63uXXVXWiuJ7gF+TA5NwxzuxCgmZRCFkrC96xgFfm hNaFFiqEEbhS7057GPFXLT/Wk3AKuLGlynLB8WWwDreL25vDShavlTmAx0PV/ojfDggO 3i7ySBU6BGzL1pygdfQCszRFFHH7kJO8pK/3QNuXH2I7vthqFEExuJocqOxBo82kS4eT wyiQ== X-Gm-Message-State: AOAM530mHGS+FQ7+EUqzhF3Nh8b8VVAgA8SOcy2UmGuutrqDHmsLufWu Yn5eDMslOQzmqHhK+qJs3G0nlx/aE9ekANV+QoU6Lw== X-Google-Smtp-Source: ABdhPJyc+gLrzhK5McV1s3POSFDxJ0vZgQau3r0WA3lSzrJGO3Z4Wz+mvnT9IX4AKiE4COwrk9DKb/JyvxPHTu676A0= X-Received: by 2002:a05:6808:2394:: with SMTP id bp20mr1251698oib.171.1643724868554; Tue, 01 Feb 2022 06:14:28 -0800 (PST) MIME-Version: 1.0 References: <20220106042708.2869332-1-reijiw@google.com> <20220106042708.2869332-4-reijiw@google.com> In-Reply-To: From: Fuad Tabba Date: Tue, 1 Feb 2022 14:13:52 +0000 Message-ID: Subject: Re: [RFC PATCH v4 03/26] KVM: arm64: Introduce struct id_reg_info To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Will Deacon , Peter Shier , Paolo Bonzini , Linux ARM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220201_061429_916690_16F58D32 X-CRM114-Status: GOOD ( 16.51 ) 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, ... > > > @@ -2862,11 +3077,12 @@ void set_default_id_regs(struct kvm *kvm) > > > u32 id; > > > const struct sys_reg_desc *rd; > > > u64 val; > > > + struct id_reg_info *idr; > > > > > > for (i = 0; i < ARRAY_SIZE(sys_reg_descs); i++) { > > > rd = &sys_reg_descs[i]; > > > if (rd->access != access_id_reg) > > > - /* Not ID register, or hidden/reserved ID register */ > > > + /* Not ID register or hidden/reserved ID register */ > > > continue; > > > > > > id = reg_to_encoding(rd); > > > @@ -2874,7 +3090,8 @@ void set_default_id_regs(struct kvm *kvm) > > > /* Shouldn't happen */ > > > continue; > > > > > > - val = read_sanitised_ftr_reg(id); > > > - kvm->arch.id_regs[IDREG_IDX(id)] = val; > > > + idr = GET_ID_REG_INFO(id); > > > + val = idr ? idr->vcpu_limit_val : read_sanitised_ftr_reg(id); > > > + (void)write_kvm_id_reg(kvm, id, val); > > > > Rather than ignoring the return value of write_kvm_id_reg(), wouldn't > > it be better if set_default_id_regs were to propagate it back to > > kvm_arch_init_vm in case there's a problem? > > Since write_kvm_id_reg() should never return an error for this > case, returning an error to kvm_arch_init_vm() adds a practically > unnecessary error handling, which I would like to avoid. > So, how about putting WARN_ON_ONCE on its return value ? I think this makes sense in this case. Thanks, /fuad > Thanks, > Reiji _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel