Re: [QEMU] Question regarding user mode support for ARM syscalls

[Laurent Vivier]

Le 04/11/2020 à 11:57, Lukasz Majewski a écrit :
> Hi Alistair,
> 
>> On Tue, Nov 3, 2020 at 8:55 AM Lukasz Majewski <lukma@denx.de> wrote:
>>>
>>> Hi Alistair,
>>>  
>>>> On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski <lukma@denx.de>
>>>> wrote:  
>>>>>
>>>>> Dear Qemu Community,  
>>>>
>>>> Hey Lukasz,
>>>>
>>>> + QEMU Dev Mailing list
>>>> + Laurent
>>>>  
>>>
>>> Thanks for reaching more people.
>>>  
>>>>>
>>>>> I would like to ask you for some advice regarding the usage of
>>>>> arm-linux-user/qemu-arm user space program simulation.
>>>>>
>>>>> Background:
>>>>> -----------
>>>>>
>>>>> I'm looking for a way to efficiently test y2038 in-glibc
>>>>> solution for 32 bit architectures (e.g. ARM).
>>>>>
>>>>> For now I do use qemu-system-arm (part of Yocto/OE), which I'm
>>>>> using to run Linux kernel 5.1, glibc under test and Y2038
>>>>> tests. It works [1].
>>>>>
>>>>> Problem:
>>>>> --------
>>>>>
>>>>> I would like to test cross-compiled tests (which are built from
>>>>> glibc sources) without the need to run the emulated system with
>>>>> qemu-system-arm.
>>>>>
>>>>> I've come across the "QEMU user mode", which would execute the
>>>>> cross-compiled test (with already cross-compiled glibc via -L
>>>>> switch) and just return exit status code. This sounds
>>>>> appealing.  
>>>>
>>>> As another advantage it is much, much faster at running the glibc
>>>> tests.
>>>>  
>>>
>>> +1
>>>  
>>>>>
>>>>> As fair as I've read - QEMU user mode emulates ARM syscalls.
>>>>>
>>>>> During test execution (single qemu user mode process) I would
>>>>> need to adjust date with clock_settime64 syscall and then
>>>>> execute other syscalls if needed.
>>>>>
>>>>>
>>>>> Please correct me if I'm wrong:
>>>>> - It looks like qemu-arm doesn't have switch which would allow
>>>>> it to set time offset (to e.g. year 2039 - something similar to
>>>>>   qemu-system-arm -rtc=).
>>>>>
>>>>> - As of 5.1 qemu version there is no support for syscalls
>>>>> supporting 64 bit time on 32 bit architectures (e.g.
>>>>> clock_settime64 and friends from [2]).  
>>>>
>>>> There is some support in the current master, for example
>>>> __NR_futex_time64 is supported.  
>>>
>>> I've just looked into v5.1.0 stable release. I will double check
>>> this with -master branch.
>>>  
>>>>
>>>> I started to add some support for RV32 once it was merged into
>>>> glibc.  
>>>
>>> Ok.
>>>  
>>>>  
>>>>>
>>>>> For my example program [3] statically build for testing (it
>>>>> works with qemu-system-arm):
>>>>>
>>>>> ~/work/qemu-arm-tests-program$
>>>>> ../qemu-5.1.0-arm/arm-linux-user/qemu-arm -L
>>>>> ~/work/yocto/y2038/build/tmp/armv7at2hf-neon-poky-linux-gnueabi/y2038-glibc/2.30+git999-r0/image/opt
>>>>> -strace ./cst
>>>>>
>>>>> 17746 brk(NULL) = 0x00074000
>>>>> 17746 brk(0x000748a8) = 0x000748a8
>>>>> 17746 uname(0x40800370) = 0
>>>>> 17746 readlink("/proc/self/exe",0x407ff488,4096) = 43
>>>>> 17746 brk(0x000958a8) = 0x000958a8
>>>>> 17746 brk(0x00096000) = 0x00096000
>>>>> 17746 mprotect(0x00070000,8192,PROT_READ) = 0
>>>>> 17746statx(1,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x407ffd70)
>>>>> = 0
>>>>> 17746 Unknown syscall 404 --> is the syscall number of
>>>>> clock_settime64  
>>>>
>>>> clock_settime64 is supported in master QEMU.  
>>>
>>> I will double check it - thanks for pointing this out.
>>>  
>>>>  
>>>>>
>>>>> 17746 dup(2) = 3
>>>>> 17746 fcntl64(3,F_GETFL) = 2
>>>>> 17746statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x407ff8e8)
>>>>> = 0 ERR
>>>>>
>>>>> Questions:
>>>>> ----------
>>>>>
>>>>> 1. Is there any plan to add support for emulating syscalls
>>>>> supporting 64 bit time on 32 bit architectures [2]?  
>>>>
>>>> I would like to have RV32 supported, but it's a low priority for
>>>> me.  
>>>
>>> Having syscalls supporting 64 bit time on 32 bit machines indicated
>>> in [2] would be a very welcome for glibc testing.
>>>  
>>>> I
>>>> expect it's something that will eventually happen though.  
>>>
>>> Ok.
>>>  
>>>>  
>>>>>
>>>>> 2. Provide QEMU user space switch to adjust its time (i.e. add
>>>>> some offset to in-fly emulated time syscalls - like
>>>>> clock_settime64) when it is started?  
>>>>
>>>> That I'm not sure about.  
>>>
>>> For me it would be enough to have:
>>>
>>> qemu-arm -rtc="2039-01-01" -L... ./ctx
>>> So the emulated "time" would be after 32 bit time_t overflow when
>>> QEMU user space emulation process starts (as long as it doesn't
>>> touch the host machine time).
>>>
>>>
>>> Another option (workaround) would be to run clock_settime64() with
>>> time set to year 2038+ on the beginning of each glibc test. It
>>> shall work as long as we don't change host time (and all time
>>> changes would stay in the qemu user mode process).
>>>  
>>>> I assume just running date/clock_settime64
>>>> from a script wouldn't work with the glibc test framework?  
>>>
>>> Could you elaborate on this use case/scenario? Do you have some
>>> examples to share?  
>>
>> Whoops, I got confused here. The clock_gettime syscall goes to the
>> host, so we just report host time. I was thinking about softMMU where
>> we maintain our own time.
>>
>> So your proposed `-rtc` command would add an offset to the host time?
>> Something like:
>>
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 3160a9ba06..240bd59bb2 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -12074,6 +12074,7 @@ static abi_long do_syscall1(void *cpu_env, int
>> num, abi_long arg1,
>>
>>          ret = target_to_host_timespec64(&ts, arg2);
>>          if (!is_error(ret)) {
>> +            ts.tv_sec -= 567993505;
>>              ret = get_errno(clock_settime(arg1, &ts));
>>          }
>>          return ret;
>> @@ -12096,6 +12097,8 @@ static abi_long do_syscall1(void *cpu_env, int
>> num, abi_long arg1,
>>          struct timespec ts;
>>          ret = get_errno(clock_gettime(arg1, &ts));
>>          if (!is_error(ret)) {
>> +            // Calculate different to same time in 2038
>> +            ts.tv_sec += 567993505;
>>              ret = host_to_target_timespec64(arg2, &ts);
>>          }
>>          return ret;
>>
>> That might end up working if you can intercept all of the absolute
>> time syscalls.
> 
> It looks to me that intercepting _all_ time related syscalls seems to
> be a time consuming task.
> 
>>
>> Without any mainline support that would be easy to do in your local
>> tree,
> 
> The "local tree" solution is not an acceptable solution for me.
> 
>> which would at least allow you to test. You could also change
>> your host time to 2038, but that would break things for your host.
> 
> Yes, I would like to avoid changing the host time.
> 
>

I didn't read all the mail history but I think you should play with the
time namespace, see "unshare" and "--time" parameter.

https://man7.org/linux/man-pages/man1/unshare.1.html
https://man7.org/linux/man-pages/man7/time_namespaces.7.html

Thanks,
Laurent