qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4] linux-user: fix to handle variably sized SIO


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH v4] linux-user: fix to handle variably sized SIOCGSTAMP with new kernels
Date: Fri, 12 Jul 2019 15:47:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

Le 12/07/2019 à 15:36, Arnd Bergmann a écrit :
> On Fri, Jul 12, 2019 at 3:23 PM Laurent Vivier <address@hidden> wrote:
>>
>> Le 12/07/2019 à 14:47, Arnd Bergmann a écrit :
...
>>> No, you don't need to swap. The difference is only in the padding.
>>> Since the kernel uses a 64/64 structure here, and user space
>>> may have use 'long tv_nsec', you need to add the padding on
>>> the correct side, like
>>>
>>> struct timeval64 {
>>>    long long tv_sec;
>>> #if 32bit && big-endian
>>>    long :32; /* anonymous padding */
>>> #endif
>>>    suseconds_t tv_usec;
>>> #if (32bit && little-endian) || sparc64
>>>    long :32;
>>> #endif
>>> };
>>
>> We don't do memcopy() but we set each field one by one, so the padding 
>> doesn't
>> seem needed if we define correctly the user structure:
>>
>> struct target_timeval64 {
>>     abi_llong tv_sec;
>>     abi_long tv_usec;
>> };
>>
>> and do something like:
>>
>>     struct target_timeval64 *target_tv;
>>     struct timeval *host_tv;
>> ...
>>     __put_user(host_tv->tv_sec, &target_tv->tv_sec);
>>     __put_user(host_tv->tv_usec, &target_tv->tv_usec);
>> ...
> 
> That still seems wrong. The user application has a definition
> of 'timeval' that contains the padding, so your definition has
> to match that.

I don't find this definition with the padding. Where it is defined?

We are at the syscall level, so structures are the ones provided by the
target to the syscall, and they can be converted by the libc if the one
from the user space differs.

Thanks,
Laurent



reply via email to

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