All of lore.kernel.org
 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 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.