All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Carsten Otte <cotte@de.ibm.com>, Alexander Graf <agraf@suse.de>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	KVM <kvm@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [PATCH 0/3] KVM: s390: Trace events support.
Date: Thu, 26 Jul 2012 14:05:09 +0300	[thread overview]
Message-ID: <50112465.3070102@redhat.com> (raw)
In-Reply-To: <20120726124752.00f9fccd@BR9GNB5Z>

On 07/26/2012 01:47 PM, Cornelia Huck wrote:
> On Thu, 26 Jul 2012 12:35:10 +0300
> Avi Kivity <avi@redhat.com> wrote:
> 
>> On 07/23/2012 06:20 PM, Cornelia Huck wrote:
>> > Avi, Marcelo,
>> > 
>> > here's a patch set that introduces trace events for kvm/s390.
>> > 
>> > It's split into two parts:
>> > 
>> > - Trace points for architecture-defined events, like intercepts.
>> >   This patch calls into the disassembler via the interface provided
>> >   by the first patch. These trace points show up under events/kvm/.
>> > - Trace points for implementation-specific events like interrupt
>> >   injection. These show up under a new trace system, kvm-s390.
>> 
>> I don't see what's the difference between the two types.  Isn't
>> interrupt injection architectural?
> 
> I don't think so. The details how we do that might change, it's nothing
> dictated by the architecture.
> 
> (It might be argued where interrupt delivery belongs, since parts of it
> are architectured, while other parts are made up by us.)
> 
>> 
>> On x86, the implementation tracepoints are ones that may go away if the
>> implementation changes significantly, while the architectural ones will
>> not go away unless the architecture is changed.  
> 
> That's what I tried to do here as well.
> 
>> In fact creation and
>> destruction of vcpus and reset requests are not only architectural,
>> they're generic, you may as well add them to the arch independent trace
>> code.
> 
> The vpcu creation event also traces interesting information like the
> location of our sie control block (in fact, that's the most interesting
> information provided by the event).
> 
> The reset request traced is s390 specific (for diag 308 ipl).
> 
>> 
>> btw - why are vcpu creation and destruction useful events to trace?
> 
> See above - mainly for the control block location.

Ok, thanks for the explanations.  Applied all.


-- 
error compiling committee.c: too many arguments to function

      reply	other threads:[~2012-07-26 11:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 15:20 [PATCH 0/3] KVM: s390: Trace events support Cornelia Huck
2012-07-23 15:20 ` [PATCH 1/3] s390/dis: Instruction decoding interface Cornelia Huck
2012-07-23 15:20 ` [PATCH 2/3] KVM: s390: Add architectural trace events Cornelia Huck
2012-07-23 15:20 ` [PATCH 3/3] KVM: s390: Add implementation-specific " Cornelia Huck
2012-07-26  9:35 ` [PATCH 0/3] KVM: s390: Trace events support Avi Kivity
2012-07-26 10:47   ` Cornelia Huck
2012-07-26 11:05     ` Avi Kivity [this message]

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=50112465.3070102@redhat.com \
    --to=avi@redhat.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=schwidefsky@de.ibm.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.