Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp97721pxb; Wed, 18 Nov 2020 17:39:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJy7+fVjJmovUGvmxK5nAGeRjIuxiiUc5mOFc56+VG3TZSZbQdvwYQxuviDNQbL4N+QxLB2O X-Received: by 2002:a05:6402:1243:: with SMTP id l3mr5364408edw.151.1605749998429; Wed, 18 Nov 2020 17:39:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605749998; cv=none; d=google.com; s=arc-20160816; b=JXi4yCoK64FfLuVoo44oYWhHTfgTMfwpoDIL8jBDOSUts3FspZNi1U3YgS4XQ7ox6r vGzcHiwOitKRmcCOppMuXhlHTrHEl2DilldgC5eTXiRTepBHpiOiUoaF2fCXsMbryW/j SfevaFHAz3gjU4GetyeV7ImEu/NST9Gh2eNxBtNfBaMNF0BcuhloSU83sXCSbEihDGMs VRbVa0g8nX+8RmHreO8jrh0SI1m5iBiLQ/SXRzDy5JR9S0pQ/o0nXR0PG4Iu2l+Kgv7l tc8auYFKKu0Dy427TrfZvO/ecjj6qHaFd3pF9FUeOldR0Xq1Wrbph8RO0J+NSkIJpzFG AQpg== 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=fmLnRRUsXlUMwkE5vM9lbL3fqJ7WBnpwE+ktz2KyBk0=; b=xaxvI68TAzUtOJ0PboNkXWuHs0bmGKjTsSqrb/OO9l81aUHuoWzqYpdiUH9dJjQ8ye 5BQULwUm84qUJFHth2WX85v4Me8Ks9ir2v1PWoxJowdqB4thVn7pU+rxGvYDzZGJVqlA yoT2GHA9UMNWQR3WRBeqXxrQM/KTeJ7nbXq4sSZdiCB2g8mR9p5IAMWqQylVHlzMaYgQ HSt2opZLLNWr/Vcdt2gRnFc1hU4HNcglwJJgHxrI/gmKs6ZU8EhQnMh30QmXoQB6aehP nzv5o1cItSkK19XZvuc6hepJUvx5bUj3v9dV7vg5bV7Q3FE/pkv+Xq+6ZXlh03g7IsqR GDzQ== 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 a16si15804507ejd.678.2020.11.18.17.39.34; Wed, 18 Nov 2020 17:39:58 -0800 (PST) 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 S1727164AbgKSBhH (ORCPT + 99 others); Wed, 18 Nov 2020 20:37:07 -0500 Received: from mga02.intel.com ([134.134.136.20]:61754 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbgKSBhH (ORCPT ); Wed, 18 Nov 2020 20:37:07 -0500 IronPort-SDR: 4EKHJrWXJn2fkDKXZqNN04xK0UzxEsWIOrSMtZsHAuiIGikqHnkobqkQu6fnW9hSHHn63NWsaZ iKTw3HpCKM/g== X-IronPort-AV: E=McAfee;i="6000,8403,9809"; a="158248476" X-IronPort-AV: E=Sophos;i="5.77,489,1596524400"; d="scan'208";a="158248476" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2020 17:37:06 -0800 IronPort-SDR: P4LrGHN2rkdRihzcxWzIhnaa1U7Tz1T69KmlJXQfZAc3XAYtQ7CKAp9u4MJ73kEBXnPBz4ksPT 0cDy/SV/fQXQ== X-IronPort-AV: E=Sophos;i="5.77,489,1596524400"; d="scan'208";a="544794488" Received: from likexu-mobl1.ccr.corp.intel.com (HELO [10.238.4.107]) ([10.238.4.107]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2020 17:37:01 -0800 Subject: Re: [PATCH v2 04/17] perf: x86/ds: Handle guest PEBS overflow PMI and inject it to guest To: Peter Zijlstra , Like Xu Cc: Paolo Bonzini , kvm@vger.kernel.org, Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Kan Liang , luwei.kang@intel.com, Thomas Gleixner , wei.w.wang@intel.com, Tony Luck , Stephane Eranian , Mark Gross , Srinivas Pandruvada , linux-kernel@vger.kernel.org References: <20201109021254.79755-1-like.xu@linux.intel.com> <20201109021254.79755-5-like.xu@linux.intel.com> <20201117143529.GJ3121406@hirez.programming.kicks-ass.net> <20201118180721.GA3121392@hirez.programming.kicks-ass.net> From: "Xu, Like" Message-ID: <7b47b5c5-8e38-ce73-d905-47176734b1d8@intel.com> Date: Thu, 19 Nov 2020 09:36:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201118180721.GA3121392@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/11/19 2:07, Peter Zijlstra wrote: > On Thu, Nov 19, 2020 at 12:15:09AM +0800, Like Xu wrote: > >>> ISTR there was lots of fail trying to virtualize it earlier. What's >>> changed? There's 0 clues here. >> Ah, now we have EPT-friendly PEBS facilities supported since Ice Lake >> which makes guest PEBS feature possible w/o guest memory pinned. > OK. > >>> Why are the host and guest DS area separate, why can't we map them to >>> the exact same physical pages? >> If we map both guest and host DS_AREA to the exact same physical pages, >> - the guest can access the host PEBS records, which means that the host >> IP maybe leaked, because we cannot predict the time guest drains records and >> it would be over-designed to clean it up before each vm-entry; >> - different tasks/vcpus on the same pcpu cannot share the same PEBS DS >> settings from the same physical page. For example, some require large >> PEBS and reset values, while others do not. >> >> Like many guest msrs, we use the separate guest DS_AREA for the guest's >> own use and it avoids mutual interference as little as possible. > OK, but the code here wanted to inspect the guest DS from the host. It > states this is somehow complicated/expensive. Yes, it's expensive to inspect guest DS in the NMI handler and also unsafe to call sleepable EPT page fault handler in the NMI context. So in this version, we propose to move this complicated part to the KVM and I think the overhead is acceptable for the cross-mapped cases. The bad thing is we will not be able to distinguish whether PEBS PMI is from guest or host once there's a host PEBS counter enabled on the same CPU and we may fix it later w/ your ideas. > But surely we can at the > very least map the first guest DS page somewhere so we can at least > access the control bits without too much magic. I am not sure whether the first mapped guest DS page can help the guest PEBS to keep working from beginning to end since later host may not map guest DS page on the physical one and currently KVM couldn't control it fine-grained. This version could also avoid attacks from malicious guests by keeping its control bits in its guest space. Thanks, Like Xu