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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F75EC35640 for ; Fri, 21 Feb 2020 06:56:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4E837208C4 for ; Fri, 21 Feb 2020 06:56:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727145AbgBUG4Z convert rfc822-to-8bit (ORCPT ); Fri, 21 Feb 2020 01:56:25 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:2589 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726045AbgBUG4Z (ORCPT ); Fri, 21 Feb 2020 01:56:25 -0500 Received: from DGGEMM403-HUB.china.huawei.com (unknown [172.30.72.54]) by Forcepoint Email with ESMTP id B20BF4D47865EEE93B49; Fri, 21 Feb 2020 14:56:14 +0800 (CST) Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by DGGEMM403-HUB.china.huawei.com (10.3.20.211) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 21 Feb 2020 14:56:14 +0800 Received: from dggeme753-chm.china.huawei.com (10.3.19.99) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 21 Feb 2020 14:56:14 +0800 Received: from dggeme753-chm.china.huawei.com ([10.7.64.70]) by dggeme753-chm.china.huawei.com ([10.7.64.70]) with mapi id 15.01.1713.004; Fri, 21 Feb 2020 14:56:14 +0800 From: linmiaohe To: Sean Christopherson CC: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 03/10] KVM: VMX: Handle INVVPID fallback logic in vpid_sync_vcpu_addr() Thread-Topic: [PATCH 03/10] KVM: VMX: Handle INVVPID fallback logic in vpid_sync_vcpu_addr() Thread-Index: AdXog+GePHLbQPDSiEKWY5ZDsLwSXQ== Date: Fri, 21 Feb 2020 06:56:13 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.221.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sean Christopherson writes: >Directly invoke vpid_sync_context() to do a global INVVPID when the individual address variant is not supported instead of deferring such behavior to the caller. This allows for additional consolidation of code as the logic is basically identical to the emulation of the individual address variant in handle_invvpid(). > >No functional change intended. > >Signed-off-by: Sean Christopherson >--- Reviewed-by: Miaohe Lin