On Thu, 2017-06-01 at 19:02 +0100, Andrew Cooper wrote:
> On 01/06/17 18:33, Dario Faggioli wrote:
> > More specifically:
> >  - the handling of the TRC_HW_IRQ_HANDLED is fixed, both in
> >    xentrace_format and in xenalyze;
> >  - simple events for recording when we enter and exit the
> >    do_IRQ function, as well as when we deal with a guest
> >    IRQ, are added;
> >  - tracing of IRQs handled with direct vectors is also
> >    added.
> > 
> > With all the above, a trace will now look like this (using
> > xenalyze):
> > 
> >  0.001299072 .x- d32768v5 irq_enter, irq 80000000
> >  0.001299072 .x- d32768v5 irq_direct, vec fa, handler =
> > 0xffff82d08026d7e4
> 
> Please consistently use 0x$hex.  vec in particular has 10/16ths of
> its
> values which are completely ambiguous between hex and decimal.
> 
I fully agree. The file is not super consistent about this already, and
I was basically following the suit of the majority of existing cases.

But I really do agree, so I'll probably make a pre-patch, that converts
everyone to 0x$hex, and then use it in this patch as well.

> > +        {
> > +            if ( unlikely(tb_init_done) )
> > +            {
> > +                struct __packed {
> > +                    uint32_t vec;
> > +                    uint64_t handler;
> > +                } d;
> > +
> > +                d.vec = vector;
> > +                d.handler = (uint64_t)direct_apic_vector[vector];
> 
> As there is no code inbetween, you can do this as a straight
> initialisation of d.
> 
> i.e.
> 
> } d = { vector, (uint64_t)direct_apic_vector[vector] };
> 
> Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
Ok, thanks. I'll take care of this, and of all the others print format
and style comments.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)