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

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

[Alistair Francis]

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

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

>
> 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 started to add some support for RV32 once it was merged into glibc.

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

>
> 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. I
expect it's something that will eventually happen though.

>
> 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. I assume just running date/clock_settime64
from a script wouldn't work with the glibc test framework?

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

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

[Lukasz Majewski]

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

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?

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

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

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

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

[Lukasz Majewski]

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

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