Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2818878pxv; Mon, 12 Jul 2021 02:40:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrqykz96XVDARbp8OevlqiBqFJomkLCWWa+oEnhazApbuAX+kcQugxewZDMaioBh3sADvs X-Received: by 2002:a92:905:: with SMTP id y5mr20140866ilg.222.1626082833618; Mon, 12 Jul 2021 02:40:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626082833; cv=none; d=google.com; s=arc-20160816; b=h5MnwncJF5ImYwXTQ2RII6LjoRLXRHJyL3Pdxqb0M4ipRoB4SD03lUShAjWaXSyutK LPM9Z9Atvs1sXWnSMNQgIuZ4OVqtTAuFg4oxA5Jfpb6lFDUSz9bw0s2pCGeMlfXT5ng0 jnznX9OI6I9lfAcyLfUksFNrhuOia1GeHdY2Q0i9TqBQMo1VZgWSrjcVGkazIOJ0NQPY hsSaltpicLSmFnQoDTkouTf85BqZnU6CF7Dif0QVL5jqfIwlkSmyauX3aJ4LTMRw/3/u NMXIH39CdkHzaxQelcBg2iVHcbPNadiNusJ6BvoeN1IpvQ8RUPsJ66xxZw6GBhHv3MLH B00w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=N1wU4N7p8qzNK7A9rm5uFTbF2pkygs3+nwmrW4del4I=; b=0DQ48bZ8BhHhg53jByiZSC3NtH/h/8MDpjaVkqv1I/0XgbqonZNjUJv+jXKL1IFnIC vQn3BuWT4lG8ABDenX1sT5tSTcXz0Y6g/IX9mZoLfR8jcZT/5UKyTia5PythR7qz4Yno WvPwU6+/OIMWCInb/Nib3fKsOReIrGqvRbaMgkmNFFNnk2e95T1q7Nqs8uR0ZPPIXq4n eDYh63UXU6Y2LR09GILAD+GPzWzId/n8Ws6zyDxGJfQDvdhO6Q9CUezejolFtebbN/6Y 8/UKAifoag0+AQxqJw8h6V60473PWedwu6KOXFJverj+zxQaxbjWZjgCkwIeBhWLNZkq t0gg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l12si16998249jaj.28.2021.07.12.02.40.21; Mon, 12 Jul 2021 02:40:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237648AbhGLJmf (ORCPT + 99 others); Mon, 12 Jul 2021 05:42:35 -0400 Received: from mga17.intel.com ([192.55.52.151]:12193 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237631AbhGLJjU (ORCPT ); Mon, 12 Jul 2021 05:39:20 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10042"; a="190332116" X-IronPort-AV: E=Sophos;i="5.84,232,1620716400"; d="scan'208";a="190332116" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2021 02:36:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,232,1620716400"; d="scan'208";a="491957343" Received: from michael-optiplex-9020.sh.intel.com (HELO localhost) ([10.239.159.182]) by FMSMGA003.fm.intel.com with ESMTP; 12 Jul 2021 02:36:30 -0700 Date: Mon, 12 Jul 2021 17:50:34 +0800 From: Yang Weijiang To: Jim Mattson Cc: Yang Weijiang , pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wei.w.wang@intel.com, like.xu.linux@gmail.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 06/13] KVM: x86/vmx: Save/Restore host MSR_ARCH_LBR_CTL state Message-ID: <20210712095034.GD12162@intel.com> References: <1625825111-6604-1-git-send-email-weijiang.yang@intel.com> <1625825111-6604-7-git-send-email-weijiang.yang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 09, 2021 at 03:54:53PM -0700, Jim Mattson wrote: > On Fri, Jul 9, 2021 at 2:51 AM Yang Weijiang wrote: > > > > If host is using MSR_ARCH_LBR_CTL then save it before vm-entry > > and reload it after vm-exit. > > I don't see anything being done here "before VM-entry" or "after > VM-exit." This code seems to be invoked on vcpu_load and vcpu_put. > > In any case, I don't see why this one MSR is special. It seems that if > the host is using the architectural LBR MSRs, then *all* of the host > architectural LBR MSRs have to be saved on vcpu_load and restored on > vcpu_put. Shouldn't kvm_load_guest_fpu() and kvm_put_guest_fpu() do > that via the calls to kvm_save_current_fpu(vcpu->arch.user_fpu) and > restore_fpregs_from_fpstate(&vcpu->arch.user_fpu->state)? I looked back on the discussion thread: https://patchwork.kernel.org/project/kvm/patch/20210303135756.1546253-8-like.xu@linux.intel.com/ not sure why this code is added, but IMO, although fpu save/restore in outer loop covers this LBR MSR, but the operation points are far away from vm-entry/exit point, i.e., the guest MSR setting could leak to host side for a signicant long of time, it may cause host side profiling accuracy. if we save/restore it manually, it'll mitigate the issue signifcantly.