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

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 9217 bytes --]

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.

> 
> 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  




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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]