Xentrace supported platforms.

Xentrace supported platforms.

[Tony Breeds]

Hello all,
	I've hacked up a version of xentrace (both tools, and hypervisor
code), to work on PPC.  During this process I found a few places that
break on 64-bit platforms.  So I'm wondering who's using xentrace and
on what platforms?

Also is anyone interested in being able to capture the xentrace data on
one machine and read/process it on another (potentially switching
endianness and wordsize in the process)?

Yours Tony

   linux.conf.au       http://linux.conf.au/ || http://lca2007.linux.org.au/
   Jan 15-20 2007      The Australian Linux Technical Conference!

Re: Xentrace supported platforms.

[Rob Gardner]

Tony Breeds wrote:
> Hello all,
> 	I've hacked up a version of xentrace (both tools, and hypervisor
> code), to work on PPC.  During this process I found a few places that
> break on 64-bit platforms.  So I'm wondering who's using xentrace and
> on what platforms?

In the dim past, xentrace/xenmon had been tested on amd64 and IA64, but 
I don't know if anyone is using it on those platforms.

If you have fixes that would work on all platforms, then by all means 
you should share them.


Rob

Re: Re: Xentrace supported platforms.

[Atsushi SAKAI]

Hello, Rob and Tony

 I am using xentrace in IA64 environment.
It works fine.
What is your problem?

Anyway I sometimes analyze xentrace/IA64 data on x86 
by change the format string of xentrace_format/x86.
So for my work, endian is no problem at this moment.

Thanks
Atsushi SAKAI


>Tony Breeds wrote:
>> Hello all,
>> 	I've hacked up a version of xentrace (both tools, and hypervisor
>> code), to work on PPC.  During this process I found a few places that
>> break on 64-bit platforms.  So I'm wondering who's using xentrace and
>> on what platforms?
>
>In the dim past, xentrace/xenmon had been tested on amd64 and IA64, but 
>I don't know if anyone is using it on those platforms.
>
>If you have fixes that would work on all platforms, then by all means 
>you should share them.
>
>
>Rob
>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>

Re: Re: Xentrace supported platforms.

[Tony Breeds]

On Fri, Nov 17, 2006 at 02:01:02PM +0900, Atsushi SAKAI wrote:
> Hello, Rob and Tony
> 
>  I am using xentrace in IA64 environment.
> It works fine.
> What is your problem?

Essentially it boiled down to the use of unsigned long in the t_rec
structure.  When trying to write the data to disk (xentrace.c) the t_rec
structure was being written 32bytes at a time (as oppoed to the whole
structure which is 56 bytes.
 
> Anyway I sometimes analyze xentrace/IA64 data on x86 
> by change the format string of xentrace_format/x86.
> So for my work, endian is no problem at this moment.

Okay good to know.

Yours Tony

   linux.conf.au       http://linux.conf.au/ || http://lca2007.linux.org.au/
   Jan 15-20 2007      The Australian Linux Technical Conference!

Re: Re: Xentrace supported platforms.

[Tony Breeds]

On Thu, Nov 16, 2006 at 09:55:40PM -0700, Rob Gardner wrote:
 
> In the dim past, xentrace/xenmon had been tested on amd64 and IA64, but 
> I don't know if anyone is using it on those platforms.
> 
> If you have fixes that would work on all platforms, then by all means 
> you should share them.

Certainly will.. I wanted to know what platforms are currently in use so
I can try and verify that I don't break them in the process :)

Yours Tony

   linux.conf.au       http://linux.conf.au/ || http://lca2007.linux.org.au/
   Jan 15-20 2007      The Australian Linux Technical Conference!

Re: [Xen-devel] Re: Xentrace supported platforms.

[Jimi Xenidis]

On Nov 17, 2006, at 12:39 AM, Tony Breeds wrote:

> On Fri, Nov 17, 2006 at 02:01:02PM +0900, Atsushi SAKAI wrote:
>> Hello, Rob and Tony
>>
>>  I am using xentrace in IA64 environment.
>> It works fine.
>> What is your problem?
>
> Essentially it boiled down to the use of unsigned long in the t_rec
> structure.  When trying to write the data to disk (xentrace.c) the  
> t_rec
> structure was being written 32bytes at a time (as oppoed to the whole
> structure which is 56 bytes.
let alone a whole 4 bytes wasted to padding in the 64bit world (guess  
thats why there data[5]?)
Can we get away with uint32[5], always?


Also, I'm not sure we have headers that can state this, but if we do  
not then lets pick 1 endian.
I know I'll lose so I'll even be ok with little-endian as the  
canonical endian.
-JX