Le 04/11/2020 à 11:57, Lukasz Majewski a écrit : > Hi Alistair, > >> On Tue, Nov 3, 2020 at 8:55 AM Lukasz Majewski <lu...@denx.de> wrote: >>> >>> Hi Alistair, >>> >>>> On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski <lu...@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