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;
Date:   Wed, 18 Nov 2020 19:07:21 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Like Xu <like.xu@linux.intel.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        Kan Liang <kan.liang@linux.intel.com>, luwei.kang@intel.com,
        Thomas Gleixner <tglx@linutronix.de>, wei.w.wang@intel.com,
        Tony Luck <tony.luck@intel.com>,
        Stephane Eranian <eranian@google.com>,
        Mark Gross <mgross@linux.intel.com>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 04/17] perf: x86/ds: Handle guest PEBS overflow PMI
 and inject it to guest
Message-ID: <20201118180721.GA3121392@hirez.programming.kicks-ass.net>
References: <20201109021254.79755-1-like.xu@linux.intel.com>
 <20201109021254.79755-5-like.xu@linux.intel.com>
 <20201117143529.GJ3121406@hirez.programming.kicks-ass.net>
 <b2c3f889-44dd-cadb-f225-a4c5db3a4447@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b2c3f889-44dd-cadb-f225-a4c5db3a4447@linux.intel.com>
Precedence: bulk

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. 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.