xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 2/3] trace: improve usefulness of hypercall trace record
Date: Tue, 2 Oct 2012 18:06:43 +0100	[thread overview]
Message-ID: <506B1F23.105@citrix.com> (raw)
In-Reply-To: <CAFLBxZakC=_YzaVBLh+QpoapBD8dx2BQ_SHiKB6Ffb0zg78ZVA@mail.gmail.com>

On 02/10/12 17:09, George Dunlap wrote:
> On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Trace hypercalls using a more useful trace record format.
>>
>> The EIP field is removed (it was always somewhere in the hypercall
>> page) and include selected hypercall arguments (e.g., the number of
>> calls in a multicall, and the number of PTE updates in an mmu_update
>> etc.).  12 bits in the first extra word are used to indicate which
>> arguments are present in the record and what size they are (32 or
>> 64-bit).
>>
>> This is an incompatible record format so a new event ID is used so
>> tools can distinguish between the two formats.
>>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> Acked-by: George Dunlap <george.dunlap@citrix.com>
> 
> Looking at it again, I do have one comment (see below) -- so I guess
> that would be technically withdrawing the Ack until we sort it out.
> 
>> diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c
>> index 27fe150..f2c75bc 100644
>> --- a/xen/arch/x86/trace.c
>> +++ b/xen/arch/x86/trace.c
>> @@ -9,33 +9,28 @@
>>  void trace_hypercall(void)
> 
> In most places, "trace_*" means "Call unconditionally; inside it will
> check tb_init_done", while "__trace_*" means, "I have already checked
> that tb_init_done is set, don't bother checking it."

This isn't something that this patch changes but I'll add a new patch to
change this since it's a trivial change.

>> +    switch ( op )
>> +    {
>> +    case __HYPERVISOR_mmu_update:
>> +        APPEND_ARG32(1); /* count */
>> +        break;
>> +    case __HYPERVISOR_multicall:
>> +        APPEND_ARG32(1); /* count */
>> +        break;
>> +    case __HYPERVISOR_grant_table_op:
>> +        APPEND_ARG32(0); /* cmd */
>> +        APPEND_ARG32(2); /* count */
>> +        break;
>> +    case __HYPERVISOR_vcpu_op:
>> +        APPEND_ARG32(0); /* cmd */
>> +        APPEND_ARG32(1); /* vcpuid */
>> +        break;
>> +    case __HYPERVISOR_mmuext_op:
>> +        APPEND_ARG32(1); /* count */
>> +        break;
>> +    case __HYPERVISOR_sched_op:
>> +        APPEND_ARG32(0); /* cmd */
>> +        break;
>> +    }
> 
> I may have commented on this before -- I wonder if doing some kind of
> array might be better than a big switch statement.  I think with only
> a few hypercalls, a switch statement is probably acceptable; but as we
> add more, the code is going to get bloated.

I'll see what I can come up with.

David

  reply	other threads:[~2012-10-02 17:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-01 17:47 [PATCHv4 0/3] trace: improve hypercall tracing David Vrabel
2012-10-01 17:47 ` [PATCH 1/3] trace: allow for different sub-classes of TRC_PV_* tracepoints David Vrabel
2012-10-02 15:56   ` George Dunlap
2012-10-01 17:47 ` [PATCH 2/3] trace: improve usefulness of hypercall trace record David Vrabel
2012-10-02 16:09   ` George Dunlap
2012-10-02 17:06     ` David Vrabel [this message]
2012-10-03 10:01       ` George Dunlap
2012-10-01 17:47 ` [PATCH 3/3] trace: trace hypercalls inside a multicall David Vrabel
2012-10-02 16:15   ` George Dunlap
  -- strict thread matches above, loose matches on Subject: below --
2012-05-31 11:06 [PATCHv3 0/3] trace: improve hypercall tracing David Vrabel
2012-05-31 11:06 ` [PATCH 2/3] trace: improve usefulness of hypercall trace record David Vrabel
2012-05-31 14:14   ` George Dunlap

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=506B1F23.105@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=dunlapg@umich.edu \
    --cc=xen-devel@lists.xensource.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;
as well as URLs for NNTP newsgroup(s).