Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3148384pxv; Mon, 12 Jul 2021 10:24:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzGWKzIszisnpbiajws/6l4R4aliU2aOHowZHboe3kJDNXWz9D7Zj1MikNwieMftT1iDCCO X-Received: by 2002:a17:906:794f:: with SMTP id l15mr184440ejo.462.1626110671421; Mon, 12 Jul 2021 10:24:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626110671; cv=none; d=google.com; s=arc-20160816; b=Vj6kK//BogijkGqKcZxD5kiY1pzuSGHxVTOcJ2VlojsKLZgLEJSh1KzDUfMM7JbhBk jy6NZirBVVjH0/Z2+hWa46HxflzmMaRs6Rc/c50ECAJV4vQT4VYx8tgSHt3LI4QCgaBX NHfEVH31mVs4807ud7AT8C4crT+TLytqGnixzMG1uEPMF70yeCENhH9cYCxu/4BJBfz1 r3eo62E/mRA8El3zCLv4fFzn1wk3tExE4YzpqHjlV/9nd5GPGYXy3/cjwmpTlRjJN/TG NCWEoqtpsQUdRBMup3GxTiLXwf+pu0/op+I+X7Uvi+X1Bhh2IcUcrH6Mq5aA+2192V+a 2LNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=BA8pDDOUvp6d/xPytywlLcoRhVoy9eZrqJDmTRrxqlQ=; b=bIx3B4nOUFGb+971qk/oQ4gc7gIzkUaxCpZtpIn2HLH1Btwf8FNdfDjC32BmVg84EV ZpTuHW4w7wq0rbhKbFqqdipDgEvtK4JGpUmzXDl3OFuMPKky6XbKWijKry1jhtUFVth9 jEoHnlWTwk8XJQC6Cwdel4uGMQrShHKWumNV6oMkXZ+jOHs43f99KcAas5OQvR0XEgH8 PEO0GnAeXugOQAWYgPr9hqco4NWz3DnkAMdg+5wyiJSCj1hOtE7bvgSIqPmpUmexD3sI nELiSy0Eura39wKiNw78LqjNVWJ86/dvcMXv35t0k9IH5wkp3teOYi5h8jzauxdtcfa8 5+xg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="q1/slnPr"; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d18si17000455ejc.683.2021.07.12.10.24.08; Mon, 12 Jul 2021 10:24:31 -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; dkim=pass header.i=@google.com header.s=20161025 header.b="q1/slnPr"; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235199AbhGLR0D (ORCPT + 99 others); Mon, 12 Jul 2021 13:26:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234856AbhGLR0C (ORCPT ); Mon, 12 Jul 2021 13:26:02 -0400 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5316FC0613DD for ; Mon, 12 Jul 2021 10:23:14 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id f93-20020a9d03e60000b02904b1f1d7c5f4so18825103otf.9 for ; Mon, 12 Jul 2021 10:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BA8pDDOUvp6d/xPytywlLcoRhVoy9eZrqJDmTRrxqlQ=; b=q1/slnPrL96kz9b2UR4Xvv++1BDjB7aaDsvPs4OKGMG7Am1SN7GGpB3iPZ2Llfj2CP wcGSV7sAZ4/jkKgFpJ8yC053amfGf6wy+ZECpr69m0/gAR5ngLUmSGjnFagkLkNZJj8E 4IeFx9TSVRwT6igKIy8ivzOLl1iAF6Q7xTvG5jNZDQMPX1gyO7HaSoYkFiI60213FPHE KCpep6I6PzmZA+zLWt/2Hvdija9vv8bIpA4LGem/h250OIHUhi5YaafYituQyKEYUHTj AoBa2OWAkKLAkFqx3EcxVlWRddu0givKOoYujaRXGyAcpsDZzvAizAaIIyAquT+3u3SP 3RKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BA8pDDOUvp6d/xPytywlLcoRhVoy9eZrqJDmTRrxqlQ=; b=hXdvV2YWUkqHgGMdGoeMUpC5ijm9Vef1Q3qA2k3iGPScQTXxfTdJvCvGTU6t2ZZ2Db du1fxUAQFsXM+uliarQlZMWxl6WYAZgl29UfWGbrDi25rGyNZ82b87+f+OnVlkSccfCy h40Rs2B8PI5+bxyY73jgStbywMsvIzFoSyIWqyOh20KaQga0LXBQ5oQ0KTqQ1n734pXq IAUXeS1s2Avm+kANUKBrhwG6t6+OmNApbq0Nk+bcu88ZXxZ2mPn978z0wVT62LUygRRh H55lhsvAKE5FwgpAHedQwtWAf4aYAugPnSUIzZM0neOTZFyjLOOxL+VcsQ1nrT44kvLM 5+Zg== X-Gm-Message-State: AOAM5306gaXMNRd8ADbPO+sMKqzmcmA/gfvxcbZ92PmXWXNgOocP4ggc zJ1lsnQfB93vjX2PHb4m/dxvNBDAdiykdY4ZFdIFTw== X-Received: by 2002:a9d:550e:: with SMTP id l14mr58035oth.241.1626110593467; Mon, 12 Jul 2021 10:23:13 -0700 (PDT) MIME-Version: 1.0 References: <1625825111-6604-1-git-send-email-weijiang.yang@intel.com> <1625825111-6604-7-git-send-email-weijiang.yang@intel.com> <20210712095034.GD12162@intel.com> In-Reply-To: <20210712095034.GD12162@intel.com> From: Jim Mattson Date: Mon, 12 Jul 2021 10:23:02 -0700 Message-ID: Subject: Re: [PATCH v5 06/13] KVM: x86/vmx: Save/Restore host MSR_ARCH_LBR_CTL state To: Yang Weijiang Cc: 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 12, 2021 at 2:36 AM Yang Weijiang wrote: > > 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. I'll be interested to see how you distinguish the intermingled branch streams, if you allow the host to record LBRs while the LBR MSRs contain guest values!