Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3147750pxv; Mon, 12 Jul 2021 10:23:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzt+ry7L0FHaYkDBUtUrAg4yv2XqyTT7k5lYVYcAaBCWFsGfPS/nl3oOPUrpdLHCZ8K+N/d X-Received: by 2002:a05:6402:4388:: with SMTP id o8mr48059209edc.338.1626110617624; Mon, 12 Jul 2021 10:23:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626110617; cv=none; d=google.com; s=arc-20160816; b=VOC6vueWXNOrvUKf5h84ReH2moc9IciDMC3NoZE6Cj16JuAuCxD26fGjAlITq9jfO1 RkqTx6/pVzy10O9VPnvRpyQ01gbPSJykbSru9jRp0X7tSadow4j+GzSW5pYKiIa3XGaO PbNvrsQJcy4cWbuFNg8hU0brYHsz/QAyKiQtyQQ+bA6g/NbZCBVWYVkcqX4WY/chASPl jmDsrmw81bgU286Aaa1RJ05dS5re/5s9FkYMCaiHzxcsEiO52GNWFjFXZgX1JJX1TGWj pbPu4TXJTQT7K8OFdSr+XdKBKx8QhpL+8I+9LBn3WSc2uyheIsAz3GAh87IanXJs/Yp4 pW1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=/g8dTtqEdW34OwE46m1MAAewcTdXVykzo2F4gfcfFFQ=; b=jJV2Uua6S+KXPyqpsAIbeij11EP21J92E++gyVcg2XOqkH/LxsTwEeQRWOkBQsnaAz icIqkjsBTqtThxUx2LrqF+PanX0JSrJvB0MgKAmLoc0BWxttO/JelQkLgXLCaDlwstPu 3v5yEw4YYCSb3Y0WOHpxu79u3lGfeY/R+PNWelWcR0SKLBDgmnZDk/AWs9p89cOr+XtZ 4FWhXVIKDI4K2M5uIkW0BAafIrVMwXYSQbN9FUhns2CpfsMD8W6iWKDLC3VkVMcRH48k oYeuKhfuyzE4Kb3DM0KscIUwXF/oLLQjYI1Gsf2JpopCxg93XyRe7WLWR3YEXnuWjFDm e55g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FgzYbYWW; 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 w11si18570682ejc.453.2021.07.12.10.23.13; Mon, 12 Jul 2021 10:23:37 -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=FgzYbYWW; 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 S234994AbhGLRXG (ORCPT + 99 others); Mon, 12 Jul 2021 13:23:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234856AbhGLRXG (ORCPT ); Mon, 12 Jul 2021 13:23:06 -0400 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD406C0613DD for ; Mon, 12 Jul 2021 10:20:16 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id q16so11129423oiw.6 for ; Mon, 12 Jul 2021 10:20:16 -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:content-transfer-encoding; bh=/g8dTtqEdW34OwE46m1MAAewcTdXVykzo2F4gfcfFFQ=; b=FgzYbYWWchiFEX7JgzLKKjpNjSXbJFtN64/66JKLT7nxtDXqKdS6dmH55joKAL+sXz BxIQNE9emF49HbPJ+lPO2V++Kc5y++hSFU0F+z7Lv7o2iYOub3UWC1bAA0cp3kD/dOf6 ji4OkDM89dDb2iK2vZzHUwweAI7g6BoUt7h6FmNNTDcQIyGIeuJofzEzyKxvL1Bvwz+O zQP9ciarNI2bFATzZ7+oGOi7/BoKEAC78+KpGDYMm/aySIVbDs9mJwnGFnjBAUkr15mJ iws9TWsO9v5liXhfcImCSsWYTZjUlhEtD6LHxZg14KIwkotAg7CKC4nCFuHiGlHCWWNx 8OEA== 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:content-transfer-encoding; bh=/g8dTtqEdW34OwE46m1MAAewcTdXVykzo2F4gfcfFFQ=; b=J2pVgLucXfAC0mbTYTtElw3CvD+wYUZgVSWmMlZtSgX9o+Jd2gQWKfdt3a2/t6jndN 35O4bp2OesEMe6pEL7h17W7t8JQta7H4Tz6TwzucyiuNMXsneNUk375zhWmzqdsK0tuM RIrIl+31/5Z73mGrb/GScFgalZQpNAJJFZuMAp7HVfX0mhLX0HyQQdanGyvNUmCytGsp TZEDe/MhISmVD8Kr7HABU9dCfNyiiCX2Ibfhy7/d5goxcx3FlhZDgPNQW73aQac2Sgvz tYtoS7pOjr6VvNKp4zyYCDlZdlk8Z8bB8+7ng4eHsMI8CMIRWOCiWrs1eIcflnVo42nK thFw== X-Gm-Message-State: AOAM532lPYFNuiRIkhd3EmBmu+Vp0WwUJSTUww+DteigzgywuMsxl9CM jPasLCwMq+67HINROw8Rwck/tULtU8h/m55DVr5b0Q== X-Received: by 2002:aca:1e07:: with SMTP id m7mr38610835oic.28.1626110415883; Mon, 12 Jul 2021 10:20:15 -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> <20210712095305.GE12162@intel.com> In-Reply-To: From: Jim Mattson Date: Mon, 12 Jul 2021 10:20:04 -0700 Message-ID: Subject: Re: [PATCH v5 06/13] KVM: x86/vmx: Save/Restore host MSR_ARCH_LBR_CTL state To: Like Xu Cc: Yang Weijiang , pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wei.w.wang@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, "kan.liang@linux.intel.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 12, 2021 at 3:19 AM Like Xu wrote: > > On 12/7/2021 5:53 pm, Yang Weijiang wrote: > > On Fri, Jul 09, 2021 at 04:41:30PM -0700, Jim Mattson wrote: > >> On Fri, Jul 9, 2021 at 3:54 PM 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 i= f > >>> 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)? > >> > >> It does seem like there is something special about IA32_LBR_DEPTH, tho= ugh... > >> > >> Section 7.3.1 of the Intel=C2=AE Architecture Instruction Set Extensio= ns > >> and Future Features Programming Reference > >> says, "IA32_LBR_DEPTH is saved by XSAVES, but it is not written by > >> XRSTORS in any circumstance." It seems like that would require some > >> special handling if the host depth and the guest depth do not match. > > In our vPMU design, guest depth is alway kept the same as that of host, > > so this won't be a problem. But I'll double check the code again, thank= s! > > KVM only exposes the host's depth value to the user space > so the guest can only use the same depth as the host. The allowed depth supplied by KVM_GET_SUPPORTED_CPUID isn't enforced, though, is it?