All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lluís Vilanova" <vilanova@ac.upc.edu>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Peter Crosthwaite" <crosthwaite.peter@gmail.com>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	"Riku Voipio" <riku.voipio@iki.fi>,
	qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Blue Swirl" <blauwirbel@gmail.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Luiz Capitulino" <lcapitulino@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v4 8/9] trace: [tcg] Add per-vCPU tracing states for events with the 'vcpu' property
Date: Mon, 18 Jan 2016 12:55:21 +0100	[thread overview]
Message-ID: <874mebp0eu.fsf@fimbulvetr.bsc.es> (raw)
In-Reply-To: 569CC38F.60302@redhat.com

Paolo Bonzini writes:

> On 15/01/2016 17:38, Lluís Vilanova wrote:
>> Each event with the 'vcpu' property gets a per-vCPU dynamic tracing state.
>> 
>> The set of enabled events with the 'vcpu' and 'tcg' properties is used
>> to select a per-vCPU physical TB cache.  The number of events with both
>> properties is used to select the number of physical TB caches, and a
>> bitmap of the identifiers of such enabled events is used to select a
>> physical TB cache.
>> 
>> Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>

> I may be wrong, but this patch and patches 3+5 seem overengineered.  Why
> can't you just flush the TB cache entirely whenever the set of trace
> events changes, independent of whether they use the vcpu attribute?
> That's a very rare event.

A request for this was discussed some time ago, while the current simple version
was merged. Right now, an event is enabled for al vCPUs. This series allows
enabling events on a per-vCPU basis (e.g., trace memory accesses of a specific
vCPU, or with the necessary logic, trace a specific guest process).

This series contains three different new features that are closely related:

* Identify the guest vCPU that is generating an event (when it has the 'vcpu'
  property).
* Set dynamic event state on a per-vCPU basis (when it has the 'tcg' and 'vcpu'
  properties).
* Use a different virtual TB cache for each vCPU, so that they can efficiently
  share TBs. If vCPUs have different events enabled, those with the disabled
  events won't pay for the extra tracing code generated in the TB.

Would it be better to split these into three separate series? It would probably
make reviewing more manageable.

Also, I have more patches on my queue to start adding meaningful guest code
events (memory access and instruction traces), but they depend on this new
'vcpu' property.


Thanks,
  Lluis

  reply	other threads:[~2016-01-18 11:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15 16:37 [Qemu-devel] [PATCH v4 0/9] trace: Per-vCPU tracing states Lluís Vilanova
2016-01-15 16:37 ` [Qemu-devel] [PATCH v4 1/9] trace: Add support for vCPU pointers in trace events Lluís Vilanova
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 2/9] trace: Add 'vcpu' event property Lluís Vilanova
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 3/9] trace: [tcg] Identify events with the 'vcpu' property Lluís Vilanova
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 4/9] exec: [tcg] Refactor flush of per-CPU virtual TB cache Lluís Vilanova
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 5/9] exec: [tcg] Use multiple physical TB caches Lluís Vilanova
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 6/9] exec: [tcg] Track which vCPU is performing translation and execution Lluís Vilanova
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 7/9] disas: Remove unused macro '_' Lluís Vilanova
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 8/9] trace: [tcg] Add per-vCPU tracing states for events with the 'vcpu' property Lluís Vilanova
2016-01-18 10:50   ` Paolo Bonzini
2016-01-18 11:55     ` Lluís Vilanova [this message]
2016-01-19 22:06   ` Eric Blake
2016-01-15 16:38 ` [Qemu-devel] [PATCH v4 9/9] trace: [tcg] Generate TCG code to trace guest events on a per-vCPU basis Lluís Vilanova

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=874mebp0eu.fsf@fimbulvetr.bsc.es \
    --to=vilanova@ac.upc.edu \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    --cc=rth@twiddle.net \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.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.