[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 06/30] trace: Fix parameter types in migratio

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 06/30] trace: Fix parameter types in migration
Date: Mon, 13 Mar 2017 15:18:15 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 03/13/2017 03:07 PM, Dr. David Alan Gilbert wrote:
> * Eric Blake (address@hidden) wrote:
>> An upcoming patch will let the compiler warn us when we are silently
>> losing precision in traces; update the trace definitions to pass
>> through the full value at the callsite.
>> Signed-off-by: Eric Blake <address@hidden>
>> ---
>>  migration/trace-events | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)

>> -postcopy_ram_fault_thread_request(uint64_t hostaddr, const char *ramblock, 
>> size_t offset) "Request for HVA=%" PRIx64 " rb=%s offset=%zx"
>> +postcopy_ram_fault_thread_request(unsigned long long hostaddr, const char 
>> *ramblock, size_t offset) "Request for HVA=%llx rb=%s offset=%zx"
> Hmm - why?
> That's called as:
>         trace_postcopy_ram_fault_thread_request(msg.arg.pagefault.address,
>                                                 qemu_ram_get_idstr(rb),
>                                                 rb_offset);
>     struct uffd_msg msg;
> struct uffd_msg {
> ..
>         union {
>                 struct {
>                         __u64   flags;
>                         __u64   address;
>                 } pagefault;
> ..
>         } arg;
> }
> So why is a PRIx64 not the right way to print a __u64 ?

Because __u64 is not the same type as uint64_t.  On 64-bit Linux, __u64
is 'unsigned long long', while uint64_t is 'unsigned long'.

> (I prefer %llx to the horrid PRIx64 syntax, but it still seems weird in this 
> case)

As it is, I'm not sure if __u64 is always 'unsigned long long' in ALL
Linux clients; an even-more-conservative patch would be to switch all
callers to use explicit casts to something (like uint64_t or unsigned
long long) that we have full control over, rather than passing __u64
where we have no control over what type it ultimately resolves to.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]