[06/14] trace: Trace entry point of balloon request handler

From: Prerna Saxena <prerna@linux.vnet.ibm.com>

Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
---
 balloon.c    |    2 ++
 trace-events |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)

On 08/12/2010 05:36 AM, Stefan Hajnoczi wrote:
> From: Prerna Saxena<prerna@linux.vnet.ibm.com>
>
> Signed-off-by: Prerna Saxena<prerna@linux.vnet.ibm.com>
> Signed-off-by: Stefan Hajnoczi<stefanha@linux.vnet.ibm.com>
> ---
>   balloon.c    |    2 ++
>   trace-events |    4 ++++
>   2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/balloon.c b/balloon.c
> index 8e0b7f1..0021fef 100644
> --- a/balloon.c
> +++ b/balloon.c
> @@ -29,6 +29,7 @@
>   #include "cpu-common.h"
>   #include "kvm.h"
>   #include "balloon.h"
> +#include "trace.h"
>
>
>   static QEMUBalloonEvent *qemu_balloon_event;
> @@ -43,6 +44,7 @@ void qemu_add_balloon_handler(QEMUBalloonEvent *func, void *opaque)
>   int qemu_balloon(ram_addr_t target, MonitorCompletion cb, void *opaque)
>   {
>       if (qemu_balloon_event) {
> +        trace_balloon_event(qemu_balloon_event_opaque, target);
>           qemu_balloon_event(qemu_balloon_event_opaque, target, cb, opaque);
>           return 1;
>       } else {
> diff --git a/trace-events b/trace-events
> index c1f3e28..eae62da 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -58,3 +58,7 @@ paio_submit(void *acb, void *opaque, unsigned long sector_num, unsigned long nb_
>   # ioport.c
>   cpu_in(unsigned int addr, unsigned int val) "addr %#x value %u"
>   cpu_out(unsigned int addr, unsigned int val) "addr %#x value %u"
> +
> +# balloon.c
> +# Since requests are raised via monitor, not many tracepoints are needed.
> +balloon_event(void *opaque, unsigned long addr) "opaque %p addr %lu"
>    

ram_addr_t is not necessarily an unsigned long.  It's actually a 
uint64_t.   Integer promotion should handle this in most cases but 
having the definition in two different places worries me a bit.

Regards,

Anthony Liguori

On Sun, Aug 22, 2010 at 04:41:44PM -0500, Anthony Liguori wrote:
> ram_addr_t is not necessarily an unsigned long.  It's actually a
> uint64_t.   Integer promotion should handle this in most cases but
> having the definition in two different places worries me a bit.

I thought it is unsigned long:

cpu-common.h:typedef unsigned long ram_addr_t;

ram_addr_t cannot be used explicitly because it is only defined for
softmmu targets.  User-only builds do not define ram_addr_t and the
generated trace.h header would break the compile.

This is a more general weakness of the tracing system: it is fragile
under #ifdefed builds because it tries to work for softmmu, user-only,
and qemu-tools!  Perhaps we should split the trace-events file.

Stefan

On 08/23/2010 05:10 AM, Stefan Hajnoczi wrote:
> On Sun, Aug 22, 2010 at 04:41:44PM -0500, Anthony Liguori wrote:
>    
>> ram_addr_t is not necessarily an unsigned long.  It's actually a
>> uint64_t.   Integer promotion should handle this in most cases but
>> having the definition in two different places worries me a bit.
>>      
> I thought it is unsigned long:
>
> cpu-common.h:typedef unsigned long ram_addr_t;
>    

Yeah, the definition has changed I think so you're right.

> ram_addr_t cannot be used explicitly because it is only defined for
> softmmu targets.  User-only builds do not define ram_addr_t and the
> generated trace.h header would break the compile.
>
> This is a more general weakness of the tracing system: it is fragile
> under #ifdefed builds because it tries to work for softmmu, user-only,
> and qemu-tools!  Perhaps we should split the trace-events file.
>    

I think documentation could go a long way to addressing this.

Regards,

Anthony Liguori

> Stefan
>