All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH v19 03/15] trace-cmd: Find and store pids of tasks, which run virtual CPUs of given VM
Date: Wed, 26 Feb 2020 23:13:14 -0500	[thread overview]
Message-ID: <20200226231314.5d4a6e5f@oasis.local.home> (raw)
In-Reply-To: <20200131121111.130355-4-tz.stoyanov@gmail.com>

On Fri, 31 Jan 2020 14:10:59 +0200
"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:

> From: Tzvetomir Stoyanov <tstoyanov@vmware.com>
> 
> In order to match host and guest events, a mapping between guest VCPU
> and the host task, running this VCPU is needed. Extended existing
> struct guest to hold such mapping and added logic in read_qemu_guests()
> function to initialize it. Implemented a new internal API,
> get_guest_vcpu_pid(), to retrieve VCPU-task mapping for given VM.
> 
> Signed-off-by: Tzvetomir Stoyanov <tstoyanov@vmware.com>
> ---
>  tracecmd/include/trace-local.h |  2 ++
>  tracecmd/trace-record.c        | 54 ++++++++++++++++++++++++++++++++++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/tracecmd/include/trace-local.h b/tracecmd/include/trace-local.h
> index 29f2779..a5cf064 100644
> --- a/tracecmd/include/trace-local.h
> +++ b/tracecmd/include/trace-local.h
> @@ -247,6 +247,8 @@ void update_first_instance(struct buffer_instance *instance, int topt);
>  
>  void show_instance_file(struct buffer_instance *instance, const char *name);
>  
> +int get_guest_vcpu_pid(unsigned int guest_cid, unsigned int guest_vcpu);
> +
>  /* moved from trace-cmd.h */
>  void tracecmd_create_top_instance(char *name);
>  void tracecmd_remove_instances(void);
> diff --git a/tracecmd/trace-record.c b/tracecmd/trace-record.c
> index 28fe31b..b479e91 100644
> --- a/tracecmd/trace-record.c
> +++ b/tracecmd/trace-record.c
> @@ -3031,10 +3031,12 @@ static bool is_digits(const char *s)
>  	return true;
>  }
>  
> +#define VCPUS_MAX 256
>  struct guest {
>  	char *name;
>  	int cid;
>  	int pid;
> +	int cpu_pid[VCPUS_MAX];

Although this is probably fine for the near future, I don't like
arbitrary limits that don't have to do with max sizes of the storage
unit (like max int).

Why is the cpu_pid a static array and not one that is allocated? We
could use realloc, couldn't we, in the loading of it?

-- Steve

>  };
>  
>  static struct guest *guests;
> @@ -3052,6 +3054,43 @@ static char *get_qemu_guest_name(char *arg)
>  	return arg;
>  }
>  
> +static void read_qemu_guests_pids(char *guest_task, struct guest *guest)
> +{
> +	struct dirent *entry;
> +	char path[PATH_MAX];
> +	char *buf = NULL;
> +	size_t n = 0;
> +	int vcpu;
> +	DIR *dir;
> +	FILE *f;
> +
> +	snprintf(path, sizeof(path), "/proc/%s/task", guest_task);
> +	dir = opendir(path);
> +	if (!dir)
> +		return;
> +
> +	while ((entry = readdir(dir))) {
> +		if (!(entry->d_type == DT_DIR && is_digits(entry->d_name)))
> +			continue;
> +
> +		snprintf(path, sizeof(path), "/proc/%s/task/%s/comm",
> +			 guest_task, entry->d_name);
> +		f = fopen(path, "r");
> +		if (!f)
> +			continue;
> +
> +		if (getline(&buf, &n, f) >= 0 &&
> +		    strncmp(buf, "CPU ", 4) == 0) {
> +			vcpu = atoi(buf + 4);
> +			if (vcpu >= 0 && vcpu < VCPUS_MAX)
> +				guest->cpu_pid[vcpu] = atoi(entry->d_name);
> +		}
> +
> +		fclose(f);
> +	}
> +	free(buf);
> +}
> +
>  static void read_qemu_guests(void)
>  {
>  	static bool initialized;
> @@ -3115,6 +3154,8 @@ static void read_qemu_guests(void)
>  		if (!is_qemu)
>  			goto next;
>  
> +		read_qemu_guests_pids(entry->d_name, &guest);
> +
>  		guests = realloc(guests, (guests_len + 1) * sizeof(*guests));
>  		if (!guests)
>  			die("Can not allocate guest buffer");
> @@ -3160,6 +3201,19 @@ static char *parse_guest_name(char *guest, int *cid, int *port)
>  	return guest;
>  }
>  
> +int get_guest_vcpu_pid(unsigned int guest_cid, unsigned int guest_vcpu)
> +{
> +	int i;
> +
> +	if (!guests || guest_vcpu >= VCPUS_MAX)
> +		return -1;
> +
> +	for (i = 0; i < guests_len; i++)
> +		if (guest_cid == guests[i].cid)
> +			return guests[i].cpu_pid[guest_vcpu];
> +	return -1;
> +}
> +
>  static void set_prio(int prio)
>  {
>  	struct sched_param sp;


  reply	other threads:[~2020-02-27  4:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 12:10 [PATCH v19 00/15]Timestamp synchronization of host - guest tracing session Tzvetomir Stoyanov (VMware)
2020-01-31 12:10 ` [PATCH v19 01/15] trace-cmd: Add support for negative time offsets in trace.dat file Tzvetomir Stoyanov (VMware)
2020-01-31 12:10 ` [PATCH v19 02/15] trace-cmd: Add new library API for local CPU count Tzvetomir Stoyanov (VMware)
2020-01-31 12:10 ` [PATCH v19 03/15] trace-cmd: Find and store pids of tasks, which run virtual CPUs of given VM Tzvetomir Stoyanov (VMware)
2020-02-27  4:13   ` Steven Rostedt [this message]
2020-02-27  8:30     ` Tzvetomir Stoyanov
2020-01-31 12:11 ` [PATCH v19 04/15] trace-cmd: Implement new API tracecmd_add_option_v() Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 05/15] trace-cmd: Add new API to generate a unique ID of the tracing session Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 06/15] trace-cmd: Store the session tracing ID in the trace.dat file Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 07/15] trace-cmd: Add definitions of htonll() and ntohll() Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 08/15] trace-cmd: Exchange tracing IDs between host and guest Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 09/15] trace-cmd: Implement new option in trace.dat file: TRACECMD_OPTION_TIME_SHIFT Tzvetomir Stoyanov (VMware)
2020-02-27  3:49   ` Steven Rostedt
2020-01-31 12:11 ` [PATCH v19 10/15] trace-cmd: Add guest information in host's trace.dat file Tzvetomir Stoyanov (VMware)
2020-02-27  3:53   ` Steven Rostedt
2020-02-27  3:56   ` Steven Rostedt
2020-02-27  9:39     ` Tzvetomir Stoyanov
2020-01-31 12:11 ` [PATCH v19 11/15] trace-cmd: Add host trace clock as guest trace argument Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 12/15] trace-cmd: Refactor few trace-cmd internal functions Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 13/15] trace-cmd: Basic infrastructure for host - guest timestamp synchronization Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 14/15] trace-cmd: [POC] PTP-like algorithm " Tzvetomir Stoyanov (VMware)
2020-01-31 12:11 ` [PATCH v19 15/15] trace-cmd: Debug scripts for " Tzvetomir Stoyanov (VMware)

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=20200226231314.5d4a6e5f@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=tz.stoyanov@gmail.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 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.