From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: kan.liang@intel.com, andi@firstfloor.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH V5 1/2] perf ignore LBR and extra_regs
Date: Mon, 14 Jul 2014 14:40:33 +0200 [thread overview]
Message-ID: <53C3CFC1.9070800@redhat.com> (raw)
In-Reply-To: <20140714120922.GV9918@twins.programming.kicks-ass.net>
Il 14/07/2014 14:09, Peter Zijlstra ha scritto:
> On Mon, Jul 14, 2014 at 01:55:03PM +0200, Paolo Bonzini wrote:
>> Il 10/07/2014 12:59, kan.liang@intel.com ha scritto:
>>> From: Kan Liang <kan.liang@intel.com>
>>>
>>> x86, perf: Protect LBR and extra_regs against KVM lying
>>>
>>> With -cpu host, KVM reports LBR and extra_regs support, if the host has support.
>>> When the guest perf driver tries to access LBR or extra_regs MSR,
>>> it #GPs all MSR accesses,since KVM doesn't handle LBR and extra_regs support.
>>> So check the related MSRs access right once at initialization time to avoid the error access at runtime.
>>>
>>> For reproducing the issue, please build the kernel with CONFIG_KVM_INTEL = y (for host kernel).
>>> And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest kernel).
>>
>> I'm not sure this is a useful patch.
>>
>> This is #GP'ing just because of a limitation in the PMU; just compile the
>> kernel with CONFIG_PARAVIRT
>
> How's that going to help? If you run kvm -host the VM is lying through
> its teeth is the kernel is going to assume all those MSRs present,
> PARAVIRT isn't going to help with this.
>
>> , or split the "rdmsr is always rdmsr_safe"
>> behavior out of CONFIG_PARAVIRT and into a new Kconfig symbol.
>
> That's not useful either, because non of these code-paths are going to
> check the return value.
Hmmm, I thought rdmsr_safe was going to return zero, but it just returns
whatever happened to be in edx:eax which maybe should also be fixed.
Kan Liang, what happens if CONFIG_PARAVIRT=y? Do you get garbage or
just no events reported?
>> In fact there's no reason why LBR cannot be virtualized (though it does need
>> support from the processor), and it may even be possible to support
>> OFFCORE_RSP_X in the KVM virtual PMU.
>
> But its not, so something needs to be done, right?
A first thing that could be done, is to have a way for the kernel to
detect absence of LBR, for example an all-1s setting of the LBR format
field of IA32_PERF_CAPABILITIES. If Intel can tell us "all 1s will
never be used", we can have KVM set the field that way. The kernel then
should disable LBR.
Paolo
next prev parent reply other threads:[~2014-07-14 12:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 10:59 [PATCH V5 1/2] perf ignore LBR and extra_regs kan.liang
2014-07-10 10:59 ` [PATCH V5 2/2] kvm: ignore LBR and extra_reg kan.liang
2014-07-14 10:53 ` [PATCH V5 1/2] perf ignore LBR and extra_regs Peter Zijlstra
2014-07-14 14:28 ` Liang, Kan
2014-07-14 16:28 ` Peter Zijlstra
2014-07-14 11:08 ` Peter Zijlstra
2014-07-14 11:55 ` Paolo Bonzini
2014-07-14 12:09 ` Peter Zijlstra
2014-07-14 12:40 ` Paolo Bonzini [this message]
2014-07-14 12:48 ` Peter Zijlstra
2014-07-14 13:47 ` Paolo Bonzini
2014-07-14 13:36 ` Liang, Kan
2014-07-14 13:40 ` Paolo Bonzini
2014-07-14 13:44 ` Liang, Kan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53C3CFC1.9070800@redhat.com \
--to=pbonzini@redhat.com \
--cc=andi@firstfloor.org \
--cc=kan.liang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox