Re: [Xen-devel] [PATCH 1/2] xen{trace/analyze}: don't use 64bit versions of libc functions

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 06/24/2015 02:02 PM, Roger Pau Monnà wrote:
> El 24/06/15 a les 13.11, Roger Pau Monnà ha escrit:
>> El 22/06/15 a les 16.48, Roger Pau Monnà ha escrit:
>>> El 22/06/15 a les 12.09, George Dunlap ha escrit:
>>>> On 06/22/2015 10:59 AM, Roger Pau Monnà wrote:
>>>>> El 22/06/15 a les 11.08, George Dunlap ha escrit:
>>>>>> On 06/19/2015 09:58 AM, Roger Pau Monne wrote:
>>>>>>> This is not needed, neither encouraged. Configure already checks
>>>>>>> _FILE_OFFSET_BITS and appends it when needed, so that the right 
>>>>>>> functions
>>>>>>> are used. Also remove the usage of loff_t and O_LARGEFILE for the same
>>>>>>> reason.
>>>>>>
>>>>>> Just so I understand -- are you saying that configure at the tools
>>>>>> directory level will notice that Linux can handle 64-bit file operations
>>>>>> and use them automatically?
>>>>>
>>>>> Yes, according to the man page [1]:
>>>>>
>>>>> "Over time, increases in the size of the stat structure have led to
>>>>> three successive versions of stat(): sys_stat() (slot __NR_oldstat),
>>>>> sys_newstat() (slot __NR_stat), and sys_stat64() (new in kernel 2.4;
>>>>> slot __NR_stat64). The glibc stat() wrapper function hides these details
>>>>> from applications, invoking the most recent version of the system call
>>>>> provided by the kernel, and repacking the returned information if
>>>>> required for old binaries. Similar remarks apply for fstat() and lstat()."
>>>>
>>>> OK, if you can confirm that you've actually tested this on a file larger
>>>> than 4GiB, then:
>>>
>>> No, I have only build tested it since I was trying to unbreak the build.
>>> I don't think I will have time to test this until tomorrow, sorry for
>>> the delay.
>>
>> I've now tested this with a ~5GB file and it seems to work fine, I
>> haven't seen any error and the output looks reasonable. This was on a
>> 64bit Dom0, if someone has a 32bit Dom0 it would be good to test it
>> there also.
> 
> I've also tested on a 32bit Dom0, with and without the patches in this
> series and I always end up getting the same strange output from xenalyze:
> 
> # xenalyze trace.file
> No output defined, using summary.
> Using VMX hardware-assisted virtualization.
> scan_for_new_pcpu: Activating pcpu 0 at offset 0
> Creating vcpu 0 for dom 32768
> scan_for_new_pcpu: Activating pcpu 1 at offset 10376
> Creating vcpu 1 for dom 32768
> scan_for_new_pcpu: Activating pcpu 4 at offset 10848
> Creating vcpu 4 for dom 32768
> scan_for_new_pcpu: Activating pcpu 6 at offset 11176
> Creating vcpu 6 for dom 32768
> init_pcpus: through first trace write, done for now.
> Creating domain 0
> Creating vcpu 0 for dom 0
> Using first_tsc for d0v0 (8109 cycles)
> Creating domain 32767
> Creating vcpu 1 for dom 32767
> Creating vcpu 1 for dom 0
> Creating vcpu 2 for dom 0
> Creating vcpu 4 for dom 32767
> Using first_tsc for d32767v4 (9407 cycles)
> Creating vcpu 6 for dom 32767
> Using first_tsc for d32767v6 (8755 cycles)
> process_cpu_change: Activating pcpu 5 at offset 16664
> Creating vcpu 5 for dom 32768
> scan_for_new_pcpu: Activating pcpu 7 at offset 17812
> Creating vcpu 7 for dom 32768
> Creating vcpu 3 for dom 0
> Using first_tsc for d0v3 (3369172 cycles)
> Creating vcpu 0 for dom 32767
> Creating vcpu 6 for dom 0
> Creating vcpu 5 for dom 32767
> Using first_tsc for d32767v5 (7868 cycles)
> Creating vcpu 7 for dom 0
> Creating vcpu 7 for dom 32767
> Using first_tsc for d32767v7 (7693 cycles)
> process_cpu_change: Activating pcpu 2 at offset 61284
> Creating vcpu 2 for dom 32768
> process_cpu_change: Activating pcpu 3 at offset 62128
> Creating vcpu 3 for dom 32768
> Creating vcpu 5 for dom 0
> Creating vcpu 3 for dom 32767
> Using first_tsc for d32767v3 (24609 cycles)
> Creating vcpu 4 for dom 0
> Creating vcpu 2 for dom 32767
> Using first_tsc for d32767v2 (2575 cycles)
> WARNING: Unexpected vcpu data type for d0v0 on proc 1! Expected 1 got 2.
> Not processing
> ]   84007(8:4:7) 0 [ ]
> WARNING: Unexpected vcpu data type for d0v0 on proc 1! Expected 1 got 2.
> Not processing
> ]   84006(8:4:6) 0 [ ]
> WARNING: Unexpected vcpu data type for d0v2 on proc 6! Expected 1 got 2.
> Not processing
> ]   84008(8:4:8) 0 [ ]
> WARNING: Unexpected vcpu data type for d0v2 on proc 6! Expected 1 got 2.
> Not processing
> ]   84008(8:4:8) 0 [ ]
> WARNING: Unexpected vcpu data type for d0v3 on proc 0! Expected 1 got 2.
> Not processing
> ]   84006(8:4:6) 0 [ ]
> Creating domain 90
> Creating vcpu 0 for dom 90
> Creating domain 89
> Creating vcpu 0 for dom 89
> Unknown hvm event: 84011
> h->exit_reason 7b > exit_reason_max 38!
> ]   81002(8:1:2) 2 [ 7b 100d9e ]
> 
> And that's all. Since this seems to not be related to this fixes I think
> they should be applied.

+1.

(Ack is already there.)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel