Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp139648pxf; Wed, 7 Apr 2021 22:44:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyD/QLtllmcUprDIaxjPmZBnb9F8Ov3jNUrQgyIpp+XRIImojJX6+p/DOPJS+DN45/96haj X-Received: by 2002:a17:906:a1c5:: with SMTP id bx5mr8335581ejb.166.1617860651851; Wed, 07 Apr 2021 22:44:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617860651; cv=none; d=google.com; s=arc-20160816; b=zqz9PrzERdY5kC5JjGGSSlHkQiCHNLeEVpDJoW0FPj0EqSQ7Nicvo+zYisCnYR5iCh LcdphyI6W+NWwp9JoIsC2XXuS/461ytFCa3iBWnZBjhX5Xpzn2LAC1U6I5Z65CCeg9gA Itc6lHKfv2uI7cOY03BajCCB+a2P7x9xRth0zhc1Zde59zhoEysNI9VomPT1A3B4nyjV SimCD2vLu1NeDpubPLL1AjwgCz7v6VE3dysG+iU8lZcdVR7/5L7B6oGemyMfIWlfqT0w 8HDbGNSSVgkD03frFOoBr28l/GThx6ecX7SUbrZc6uFDGcUHY23f6ETv6kUJ7G7fgsdC qoiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:ironport-sdr:ironport-sdr; bh=UZU8bjqqlZ5ku1oclIXi9zH2Vtk6ZKRx1jrhvrtJdlU=; b=d/dxCwsLkJrHN5RnrV+lFW+rDpsEVknLARqzKKhPn9mmBEILP1WMzRwh1NKXwqfzib oLiXDf0jP10Hn7sHBCFXT0T2e9YQZy6y7KHEp7KzlthT2HjfNiWC/wTaNRiidEA7QXd9 02TX9E7r8vvJfIctijWR7Jqi85CC/L46aN3+m1Ag0rGWRYp/c6i6wADeynQaO2umKh5B Pq8LGm2Bf2MI+MKaZHHLHNPeMHQ2xLO6OLJ+jcKhC+jDVaoM1391YovCwAHvE5UWtuDC IfzioauEkvarD8V6Zi7UF/cZkMJ7c0b2l3g1L4RpOoCK4aud58HOYMatlF+eNxB13P/8 RcXQ== 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 k24si20701257ejk.354.2021.04.07.22.43.49; Wed, 07 Apr 2021 22:44:11 -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 S229747AbhDHFkI (ORCPT + 99 others); Thu, 8 Apr 2021 01:40:08 -0400 Received: from mga01.intel.com ([192.55.52.88]:35620 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229512AbhDHFkH (ORCPT ); Thu, 8 Apr 2021 01:40:07 -0400 IronPort-SDR: 1NjWPzihncrvdfHrftvyxSL0CPpKrkdPfaq/lvoc3QOVi9hOp368Z6IUnJpA3dL6Lu7fsODx6d 6qrBz6vgIbKw== X-IronPort-AV: E=McAfee;i="6000,8403,9947"; a="213865231" X-IronPort-AV: E=Sophos;i="5.82,205,1613462400"; d="scan'208";a="213865231" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2021 22:39:56 -0700 IronPort-SDR: 1nFchG0VZE84cW6XjVn3o0HBS7z8MjplqzBG6Xp+pw4/ZQaO5x4nB9B+DBfeb0HsxmjRpFzKzP rVqP6MDPNrXA== X-IronPort-AV: E=Sophos;i="5.82,205,1613462400"; d="scan'208";a="458674706" Received: from likexu-mobl1.ccr.corp.intel.com (HELO [10.238.4.93]) ([10.238.4.93]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2021 22:39:51 -0700 Subject: Re: [PATCH v4 08/16] KVM: x86/pmu: Add IA32_DS_AREA MSR emulation to manage guest DS buffer To: Peter Zijlstra Cc: Sean Christopherson , Paolo Bonzini , eranian@google.com, andi@firstfloor.org, kan.liang@linux.intel.com, wei.w.wang@intel.com, Wanpeng Li , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, Andi Kleen , Like Xu References: <20210329054137.120994-1-like.xu@linux.intel.com> <20210329054137.120994-9-like.xu@linux.intel.com> From: "Xu, Like" Message-ID: <610bfd14-3250-0542-2d93-cbd15f2b4e16@intel.com> Date: Thu, 8 Apr 2021 13:39:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, Thanks for your detailed comments. If you have more comments for other patches, please let me know. On 2021/4/7 23:39, Peter Zijlstra wrote: > On Mon, Mar 29, 2021 at 01:41:29PM +0800, Like Xu wrote: >> @@ -3869,10 +3876,12 @@ static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr, void *data) >> >> if (arr[1].guest) >> arr[0].guest |= arr[1].guest; >> - else >> + else { >> arr[1].guest = arr[1].host; >> + arr[2].guest = arr[2].host; >> + } > What's all this gibberish? > > The way I read that it says: > > if guest has PEBS_ENABLED > guest GLOBAL_CTRL |= PEBS_ENABLED > otherwise > guest PEBS_ENABLED = host PEBS_ENABLED > guest DS_AREA = host DS_AREA > > which is just completely random garbage afaict. Why would you leak host > msrs into the guest? In fact, this is not a leak at all. When we do "arr[i].guest = arr[i].host;" assignment in the intel_guest_get_msrs(), the KVM will check "if (msrs[i].host == msrs[i].guest)" and if so, it disables the atomic switch for this msr during vmx transaction in the caller atomic_switch_perf_msrs(). In that case, the msr value doesn't change and any guest write will be trapped. If the next check is "msrs[i].host != msrs[i].guest", the atomic switch will be triggered again. Compared to before, this part of the logic has not changed, which helps to reduce overhead. > Why would you change guest GLOBAL_CTRL implicitly; This is because in the early part of this function, we have operations:     if (x86_pmu.flags & PMU_FL_PEBS_ALL)         arr[0].guest &= ~cpuc->pebs_enabled;     else         arr[0].guest &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK); and if guest has PEBS_ENABLED, we need these bits back for PEBS counters:     arr[0].guest |= arr[1].guest; > guest had better wrmsr that himself to control when stuff is enabled. When vm_entry, the msr value of GLOBAL_CTRL on the hardware may be different from trapped value "pmu->global_ctrl" written by the guest. If the perf scheduler cross maps guest counter X to the host counter Y, we have to enable the bit Y in GLOBAL_CTRL before vm_entry rather than X. > > This just cannot be right.