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

[Alistair Francis]

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.

Without any mainline support that would be easy to do in your local
tree, 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.

Alistair

>
> >
> > Alistair
> >
> > >
> > >
> > > Thanks in advance for your help and reply.
> > >
> > >
> > > Links:
> > > [1] - https://github.com/lmajewski/meta-y2038/
> > > [2] -
> > > https://elixir.bootlin.com/linux/latest/source/arch/arm/tools/syscall.tbl#L419
> > >
> > > [3]:
> > > Example program:
> > > cat <<- EOF >> clock_settime_test.c
> > > #include <stdio.h>
> > > #include <time.h>
> > >
> > > int main (int argc, char **argv)
> > > {
> > >         struct timespec tv;
> > >         int ret;
> > >
> > >         tv.tv_sec = 0x7FFFFFFF;
> > >         tv.tv_sec += 61;
> > >         tv.tv_nsec = 0;
> > >
> > >         printf("clock_settime test program: ");
> > >         ret = clock_settime(CLOCK_REALTIME, &tv);
> > >         if (!ret)
> > >                 printf("OK\n");
> > >         else
> > >                 perror("ERR\n");
> > >
> > >         return 0;
> > > }
> > > EOF
> > >
> > > Build the test program:
> > > gcc -Wall -ggdb -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
> > > -I/opt/include -I/opt/usr/include -L/opt/usr/lib \
> > > -Wl,-rpath=/opt/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.2
> > > clock_settime_test.c -o cst -static
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Lukasz Majewski
> > >
> > > --
> > >
> > > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lukma@denx.de
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de