All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	Denis Nikitin <denik@chromium.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
	linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
	linux-arm-kernel@lists.infradead.org,
	Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing
Date: Fri, 16 Oct 2020 21:14:07 +0800	[thread overview]
Message-ID: <20201016131407.GA31839@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <f6ee4156-664c-7bff-8e35-5cd1acdbaa84@arm.com>

On Fri, Oct 16, 2020 at 12:38:47PM +0100, Suzuki Kuruppassery Poulose wrote:

[...]

> > > What happens to the sysfs mode of tracing? For that we would still
> > > need a config right to exclude kernel mode tracing completely.
> > 
> > IIUC, sysfs mode and perf mode both can apply the same approach, the
> > guest OS runs a thread context for the host, so when a guest OS is
> > switched in or out, the hypervisor can save/restore the context for
> > the guest OS; thus every guest OS will have its dedicated context and
> > trace data ideally.
> 
> I don't think Guest Context is something we can support as mentioned
> above, at least for systems without sysreg access for ETMs (and virtualizing
> ETRs is a different story !)

Thanks for sharing thoughts, Suzuki.

I missed the device virtulisation.  Here should virtualize all devices
(includes CoreSight ETM/funnel/ETR/ETF)?  Or only need to virtualize
ETRs?

Obviously, this is a difficult task :)

Thanks,
Leo

WARNING: multiple messages have this Message-ID (diff)
From: Leo Yan <leo.yan@linaro.org>
To: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	Denis Nikitin <denik@chromium.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
	linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
	linux-arm-kernel@lists.infradead.org,
	Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing
Date: Fri, 16 Oct 2020 21:14:07 +0800	[thread overview]
Message-ID: <20201016131407.GA31839@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <f6ee4156-664c-7bff-8e35-5cd1acdbaa84@arm.com>

On Fri, Oct 16, 2020 at 12:38:47PM +0100, Suzuki Kuruppassery Poulose wrote:

[...]

> > > What happens to the sysfs mode of tracing? For that we would still
> > > need a config right to exclude kernel mode tracing completely.
> > 
> > IIUC, sysfs mode and perf mode both can apply the same approach, the
> > guest OS runs a thread context for the host, so when a guest OS is
> > switched in or out, the hypervisor can save/restore the context for
> > the guest OS; thus every guest OS will have its dedicated context and
> > trace data ideally.
> 
> I don't think Guest Context is something we can support as mentioned
> above, at least for systems without sysreg access for ETMs (and virtualizing
> ETRs is a different story !)

Thanks for sharing thoughts, Suzuki.

I missed the device virtulisation.  Here should virtualize all devices
(includes CoreSight ETM/funnel/ETR/ETF)?  Or only need to virtualize
ETRs?

Obviously, this is a difficult task :)

Thanks,
Leo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-16 13:14 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 12:45 [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing Sai Prakash Ranjan
2020-10-15 12:45 ` Sai Prakash Ranjan
2020-10-15 14:27 ` Suzuki K Poulose
2020-10-15 14:27   ` Suzuki K Poulose
2020-10-16  8:30   ` Sai Prakash Ranjan
2020-10-16  8:30     ` Sai Prakash Ranjan
2020-10-15 16:02 ` Mathieu Poirier
2020-10-15 16:02   ` Mathieu Poirier
     [not found]   ` <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
2020-10-16  7:24     ` Leo Yan
2020-10-16  7:24       ` Leo Yan
2020-10-16  8:40       ` Sai Prakash Ranjan
2020-10-16  8:40         ` Sai Prakash Ranjan
2020-10-16  9:24         ` Leo Yan
2020-10-16  9:24           ` Leo Yan
2020-10-16 10:30           ` Sai Prakash Ranjan
2020-10-16 10:30             ` Sai Prakash Ranjan
2020-10-16 11:38           ` Suzuki Poulose
2020-10-16 11:38             ` Suzuki Poulose
2020-10-16 13:14             ` Leo Yan [this message]
2020-10-16 13:14               ` Leo Yan
2020-10-16 13:17               ` Suzuki Poulose
2020-10-16 13:17                 ` Suzuki Poulose
2020-10-16 11:11     ` Suzuki Poulose
2020-10-16 11:11       ` Suzuki Poulose
2021-01-15  5:46   ` Sai Prakash Ranjan
2021-01-18 14:47     ` Mattias Nissler
2021-01-18 14:47       ` Mattias Nissler
2021-01-19  5:12       ` Sai Prakash Ranjan
2021-01-18 20:23     ` Mathieu Poirier
2021-01-18 20:23       ` Mathieu Poirier
2021-01-19  5:21       ` Sai Prakash Ranjan
2021-01-19  8:36         ` Al Grant
2021-01-19  8:36           ` Al Grant
2021-01-19  9:51           ` Sai Prakash Ranjan
2021-01-19 10:33             ` Suzuki K Poulose
2021-01-19 10:33               ` Suzuki K Poulose
2021-01-19 11:56               ` Al Grant
2021-01-19 11:56                 ` Al Grant
2021-01-20  5:13                 ` Sai Prakash Ranjan
2021-01-19 12:00               ` Sai Prakash Ranjan
2021-01-20 18:48           ` Mathieu Poirier
2021-01-20 18:48             ` Mathieu Poirier
2021-01-21  6:03             ` Sai Prakash Ranjan

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=20201016131407.GA31839@leoy-ThinkPad-X240s \
    --to=leo.yan@linaro.org \
    --cc=coresight@lists.linaro.org \
    --cc=denik@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=saiprakash.ranjan@codeaurora.org \
    --cc=suzuki.poulose@arm.com \
    --cc=swboyd@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.