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 1C278C433F5 for ; Wed, 3 Nov 2021 20:00:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F401C6109F for ; Wed, 3 Nov 2021 20:00:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231288AbhKCUCs (ORCPT ); Wed, 3 Nov 2021 16:02:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230248AbhKCUCr (ORCPT ); Wed, 3 Nov 2021 16:02:47 -0400 Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A904BC061203 for ; Wed, 3 Nov 2021 13:00:10 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id x64so3507054pfd.6 for ; Wed, 03 Nov 2021 13:00:10 -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=KsEvoPiFtl6bqNouQ+fGJ/sS+WphUQOBaAHxMhk3DGA=; b=YrJyFwWp4grOY1mPXnQnE+Hg0CdtJ9GnY15cK8Z+OkAURPeGDQU9vhCR3iWinmvMxu eircPif344srajRe1A7ME4omZYYSKP6lb2gpcbGF/fNpmsEYia772dhvYgiSkWHr2nNp 1uIv2yYv7LiawmDTAeTFGEor+MbVXu9FPGqS0TysHRSYA/nZsV+MtC/D4IWZ/eUZzT5b e0cilCc559JgOeQuEGuBNUYx/f5GjZ5fEbgpZKWBmB3A4aw9m/idmSvzXlB75bzjmjEW 2akZacI0oiOu+xg/hTDuJlLl4diKlqhZ0iWowZ+6tTMpPiEH6PAJ1nnTkvG7nrkvMQsU Yrkg== 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=KsEvoPiFtl6bqNouQ+fGJ/sS+WphUQOBaAHxMhk3DGA=; b=f0DLMJXibO0f6pa5HAwEXLGu3Fhr6CkcHyfIyECN16OTwwYdDvw3DOOfA/OOCM4sTF nG2U3penaakXVtMbSFqqPbPweCf9XooEJbBgGRY6bsx6pbmvhbfvSZqh296ym9ZYxJfb IaKpwo45ODMxnnjAMFu9vKK8mX+6wZPnXCWuIBTAWQczOKiy13rREXkxKSWDfunRCoz8 mA0qBoIsI/tkxQgOlil1Wvyjbgqlc7LbZQNDliFN1VDxBYqwQcEqZlZxrMww2ozuPm1J p4zEwptDcYPOT/FN9hb2/v6+UM7kHmHc5sW2+2boYpH4bwY6rx3zNUj6EROKwlxddhzd b+oA== X-Gm-Message-State: AOAM530yHyyPrAel0aD7DPFA2ErPiGbDaGtdiykUu1ciOprX2/F8dK7X ckTlOFdvfSMB68DRSfo9oRZvOA== X-Google-Smtp-Source: ABdhPJwBiTa8ecNTn5rCGLRr0uGC3m4OVyK7YALZosFLuZqUjO7nFr2X1bzBQDcNmWw0mlHEb/TsNA== X-Received: by 2002:a65:62d1:: with SMTP id m17mr35112758pgv.370.1635969610032; Wed, 03 Nov 2021 13:00:10 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id y9sm5801708pjt.27.2021.11.03.13.00.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Nov 2021 13:00:09 -0700 (PDT) Date: Wed, 3 Nov 2021 20:00:05 +0000 From: Sean Christopherson To: Vipin Sharma Cc: pbonzini@redhat.com, jmattson@google.com, dmatlack@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] KVM: Move INVPCID type check from vmx and svm to the common kvm_handle_invpcid() Message-ID: References: <20211103183232.1213761-1-vipinsh@google.com> <20211103183232.1213761-3-vipinsh@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211103183232.1213761-3-vipinsh@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 03, 2021, Vipin Sharma wrote: > This check will be done in switch statement of kvm_handle_invpcid(), Please make the changelog a stand on its own, i.e. don't rely on the shortlog for context. > used by both VMX and SVM. It also removes (type > 3) check. Use imperative mood, i.e. state what you're doing as a "command", don't refer to the patch from a third-person point of view. The changelog also needs to call out that, unlike INVVPID and INVEPT, INVPCID is not explicitly documented as checking the "type" before reading the operand from memory. I.e. there's a subtle, undocumented functional change in this patch. Something like: Handle #GP on INVCPID due to an invalid type in the common switch statement instead of relying on callers to manually verify the type is valid. Unlike INVVPID and INVPET, INVPCID is not explicitly documented as checking the type before reading the operand from memory, so deferring the type validity check until after that point is architecturally allowed. For the code: Reviewed-by: Sean Christopherson