From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Jin Yao <yao.jin@linux.intel.com>
Subject: Re: [RFC PATCH] perf/core: don't sample kernel regs upon skid
Date: Wed, 11 Jul 2018 11:33:35 -0400 [thread overview]
Message-ID: <98e69f42-bae4-d2a9-727b-1eaee91fe3c0@oracle.com> (raw)
In-Reply-To: <20180711055927.wcfcfkninfjwox3n@salmiak>
On 07/11/2018 01:59 AM, Mark Rutland wrote:
> On Mon, Jul 09, 2018 at 06:42:29PM -0400, Boris Ostrovsky wrote:
>> On 07/02/2018 12:02 PM, Mark Rutland wrote:
>>> On Mon, Jul 02, 2018 at 05:46:55PM +0200, Peter Zijlstra wrote:
>>>> On Mon, Jul 02, 2018 at 04:12:50PM +0100, Mark Rutland wrote:
>>>>> +static struct pt_regs *perf_get_sample_regs(struct perf_event *event,
>>>>> + struct pt_regs *regs)
>>>>> +{
>>>>> + /*
>>>>> + * Due to interrupt latency (AKA "skid"), we may enter the kernel
>>>>> + * before taking an overflow, even if the PMU is only counting user
>>>>> + * events.
>>>>> + *
>>>>> + * If we're not counting kernel events, always use the user regs when
>>>>> + * sampling.
>>>>> + *
>>>>> + * TODO: what do we do about sampling a guest's registers? The IP is
>>>>> + * special-cased, but for the rest of the regs they'll get the
>>>>> + * user/kernel regs depending on whether exclude_kernel is set, which
>>>>> + * is nonsensical.
>>>>> + *
>>>>> + * We can't get at the full set of regs in all cases (e.g. Xen's PV PMU
>>>>> + * can't provide the GPRs), so should we just zero the GPRs when in a
>>>>> + * guest? Or skip outputting the regs in perf_output_sample?
>>>> Seems daft Xen cannot provide registers; why is that? Boris?
>>> The xen_pmu_regs structure simply doesn't have them, so I assume there's
>>> no API to get them.
>>>
>>> Given we don't currently sample the guest regs, I'd be tempted to just
>>> zero them for now, or skip the sample at output time (if that doesn't
>>> break some other case).
>> (Was out on vacation, couldn't respond earlier)
>>
>> Yes, PV guests only get a limited set of registers passed to the handler
>> by the hypervisor. GPRs are not part of this set.
> Is that also true for Dom0?
Yes. As far as VPMU is concerned there is (almost) no differences
between privileged (i.e. dom0) and unprivileged PV guests.
-boris
next prev parent reply other threads:[~2018-07-11 15:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-02 15:12 Mark Rutland
2018-07-02 15:46 ` Peter Zijlstra
2018-07-02 16:02 ` Mark Rutland
2018-07-09 22:42 ` Boris Ostrovsky
2018-07-11 5:59 ` Mark Rutland
2018-07-11 15:33 ` Boris Ostrovsky [this message]
2018-08-02 8:57 ` Mark Rutland
2018-07-12 11:56 ` Mark Rutland
2018-07-12 16:32 ` Boris Ostrovsky
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=98e69f42-bae4-d2a9-727b-1eaee91fe3c0@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=yao.jin@linux.intel.com \
/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
all inboxes | Powered by JetHome®