Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Wang, Wei W" <wei.w.wang@intel.com>
To:     Andi Kleen <ak@linux.intel.com>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "Liang, Kan" <kan.liang@intel.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "rkrcmar@redhat.com" <rkrcmar@redhat.com>,
        "Xu, Like" <like.xu@intel.com>,
        "jannh@google.com" <jannh@google.com>,
        "arei.gonglei@huawei.com" <arei.gonglei@huawei.com>
Subject: RE: [PATCH v3 4/5] KVM/x86/vPMU: Add APIs to support host
 save/restore the guest lbr stack
Thread-Topic: [PATCH v3 4/5] KVM/x86/vPMU: Add APIs to support host
 save/restore the guest lbr stack
Thread-Index: AQHUUM3pU3aoeAw5SE6eJtMPeYOl0qT4xgeAgAsk5FA=
Date:   Thu, 27 Sep 2018 10:05:48 +0000
Message-ID: <286AC319A985734F985F78AFA26841F7397FCAD0@shsmsx102.ccr.corp.intel.com>
References: <1537437959-8751-1-git-send-email-wei.w.wang@intel.com>
 <1537437959-8751-5-git-send-email-wei.w.wang@intel.com>
 <20180920153035.GB10360@tassilo.jf.intel.com>
In-Reply-To: <20180920153035.GB10360@tassilo.jf.intel.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thursday, September 20, 2018 11:31 PM, Andi Kleen wrote:
> > +int intel_pmu_enable_save_guest_lbr(struct kvm_vcpu *vcpu) {
> > +	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> > +	struct perf_event *event;
> > +	struct perf_event_attr attr = {
> > +		.type = PERF_TYPE_RAW,
> > +		.size = sizeof(attr),
> > +		.pinned = true,
> > +		.exclude_host = true,
> > +		.sample_type = PERF_SAMPLE_BRANCH_STACK,
> > +		.branch_sample_type = PERF_SAMPLE_BRANCH_CALL_STACK
> |
> > +				      PERF_SAMPLE_BRANCH_USER |
> > +				      PERF_SAMPLE_BRANCH_KERNEL,


Sorry for my late response (I was digging into some of the details).


> I think that will allocate an extra perfmon counter, right?
> 
> So if the guest wants to use all perfmon counters we would start to multiplex,
> which would be bad

Right. The host side counter allocation is not necessary.


> Would need to fix perf core to not allocate a perfmon counter in this case, if
> no period and no event count is requested.
> 

If no period (i.e. .sample_period = 0), the current code still uses one counter with the period set to the max period.
If we change that to do no counter allocation, would that break any of the existing usages (I didn't find the reason why the existing code not avoid that allocation for a non-sampling event)?

Best,
Wei