Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3765128pxv; Tue, 13 Jul 2021 03:17:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzW/WwPMSnqEmCJOXt6rGQ7/L/dlvJzt1F7nUsW7fBaTbTljjpPROTKnP9yA1GgX0e7bNB X-Received: by 2002:a05:6e02:666:: with SMTP id l6mr2370570ilt.245.1626171433234; Tue, 13 Jul 2021 03:17:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626171433; cv=none; d=google.com; s=arc-20160816; b=A9A1ZJ/MY2KI8XDQdd1geyGgoFdNWUOxoGxnxYLOHvfrZFjB493oCZKSCAC3KIpBn5 w00Z6a1TGcjRXn9io8f0BCAnmP61dZHRVWoM1UkmQXwAh4FiT0oeEZqMTiUHDAwfletc X4QZ/z6BSsnQKjxfszPG2Z+Wr6GaM4vYph10QDERkMSKpeBe/Q3Lwsp6wnDWCH3R80a6 EtVvsnRbrqoPQBnUTAgMtrvkGfRmh0IZIpRGY/nVTrZneZLMzsAWXmqXl1G5i5voZdlx DHftc1Sp/IL8hdsNFZ6S/LDdsLU2c5YWKtF/7wssU5Fg+86tWFyZW5arH8BR+3Tf9Dx9 JgGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:dkim-signature; bh=pZ+kJIZpqwPna83byG9/WJMMnZqY/UkbffT9YAmCx5Y=; b=TZOdMs1CrGf4IUuHIWJcbKQ1ENMcmGWEyCvE+PrWgzZl4MRpszUpd37XTT6/MtLEay +9JSjr2mK9iwG/a/6r3tcUDzAyINpXPrGA1NqNjFP1zIqfXrm/B+NEVPMeptoMrHE6a9 vmjLzOLYak/Ex1ldJzzDRyww546y6TgHiVFU+TOS4rEhldBvrp/bsQo4HCYZ+Z/8DoQs R7hyDI5imyWUbXV8deE6MA1tu6/IUs2wleP8LX+eAgibuqKryOewGKcrotYbTsCV7uss TUKmQsAzsoZb+/BQz1CGSj6xvY6MkWfGj8o3PSvBU2194Iqk/qi1Y05Tl5KpNMg4elf6 9AsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FggyFQ1h; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m1si23681279ilu.13.2021.07.13.03.16.59; Tue, 13 Jul 2021 03:17:13 -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=@gmail.com header.s=20161025 header.b=FggyFQ1h; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235326AbhGMKTI (ORCPT + 99 others); Tue, 13 Jul 2021 06:19:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235143AbhGMKTH (ORCPT ); Tue, 13 Jul 2021 06:19:07 -0400 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9864EC0613DD; Tue, 13 Jul 2021 03:16:16 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id a127so19108828pfa.10; Tue, 13 Jul 2021 03:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pZ+kJIZpqwPna83byG9/WJMMnZqY/UkbffT9YAmCx5Y=; b=FggyFQ1hdkSBHPNsyxE7wgkRDUf+2lrqhQYPR+9om9qKy71AO7QUa2bAULnsN7CFD2 hjV4k+E1rbfgUMW/6LiVe1tFlOpp5sbigFNT9rb8Zg1ImEugjwMLr7AhEWfm4+3xGr7C U5eyOLNgIOWiRTKXZQT5c1pN1uMKTLnZhd7hnYFof7o5MQw2eDVVbshIw9kkLiqmbtnQ 3AAJ71AYWh/oYG8spKS435N19+ChT3/QAK7C9GBSaJPwGT8YXSWifElDljPREMv+Yhca tVBwwS131a4tZ7KfuaNEB1TXq8HKKL2pdRMMT3TMQzoJ9cQ6Mc4ehR39xL6Jc1FkdJpO ekBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pZ+kJIZpqwPna83byG9/WJMMnZqY/UkbffT9YAmCx5Y=; b=DybDQU0hB4R8zZDC6CtpR2Imtcsid6FgWJRn4qfQdfF8BNHVC1ZPzQ98mzF99SvFdg QpbzWux5uP4LPGJg0Yz1PUSNrFo9gDLFqLK0OaCEeQ1+n2IjcuS96BAC2Z6hK3f1y2CX rW+RgXlJ0K/dHtKq11Crc6PXhnvThHxidAt4AGztHOF1weUwxokL1RJgIp/NGRgxKWmu Uf6XAoLk4TwYCnWqsfrNdLUmCo7HkjCGmn8YyOdUiMpVTgeQEiQ1+gbR+fTcjvjDRpCY t0Ods9fmruyC69owB0hbQh/80cgFGzVYwEBIgCOurxSEiZm69EB41hVQnk2QeEBgc9Qt I/ag== X-Gm-Message-State: AOAM531Cc0g7Lpd8vl++hZu8llGM3sVFwZJrYAWicmoy34n7Uy+IDusI y8jzrxjHkdnD0UaQ2u4Lcpc2SnWw1dtQOowJ X-Received: by 2002:a65:5086:: with SMTP id r6mr3566071pgp.237.1626171375987; Tue, 13 Jul 2021 03:16:15 -0700 (PDT) Received: from Likes-MacBook-Pro.local ([103.7.29.32]) by smtp.gmail.com with ESMTPSA id x10sm14944114pfr.150.2021.07.13.03.16.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 03:16:15 -0700 (PDT) To: Yang Weijiang , Jim Mattson Cc: pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wei.w.wang@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org 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> <20210713094713.GB13824@intel.com> From: Like Xu Subject: Re: [PATCH v5 06/13] KVM: x86/vmx: Save/Restore host MSR_ARCH_LBR_CTL state Message-ID: <1be1fde6-37c5-4697-cff0-b15af419975e@gmail.com> Date: Tue, 13 Jul 2021 18:16:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210713094713.GB13824@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/7/2021 5:47 pm, Yang Weijiang wrote: > On Mon, Jul 12, 2021 at 10:23:02AM -0700, Jim Mattson wrote: >> 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! The guest is pretty fine that the real LBR MSRs contain the guest values even after vm-exit if there is no other LBR user in the current thread. (The perf subsystem makes this data visible only to the current thread) Except for MSR_ARCH_LBR_CTL, we don't want to add msr switch overhead to the vmx transaction (just think about {from, to, info} * 32 entries). If we have other LBR user (such as a "perf kvm") in the current thread, the host/guest LBR user will create separate LBR events to compete for who can use the LBR in the the current thread. The final arbiter is the host perf scheduler. The host perf will save/restore the contents of the LBR when switching between two LBR events. Indeed, if the LBR hardware is assigned to the host LBR event before vm-entry, then the guest LBR feature will be broken and a warning will be triggered on the host. LBR is the kind of exclusive hardware resource and cannot be shared by different host/guest lbr_select configurations. > I'll check if an inner simplified xsave/restore to guest/host LBR MSRs is meaningful, > the worst case is to drop this patch since it's not correct to only enable host lbr ctl > while still leaves guest LBR data in the MSRs. Thanks for the reminder! >