Re: [QEMU] Question regarding user mode support for ARM syscalls
Le 04/11/2020 à 11:57, Lukasz Majewski a écrit :
> Hi Alistair,
>
>> On Tue, Nov 3, 2020 at 8:55 AM Lukasz Majewski wrote:
>>>
>>> Hi Alistair,
>>>
On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski
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(0x0007,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,
Re: [QEMU] Question regarding user mode support for ARM syscalls
Hi Alex,
> Lukasz Majewski writes:
>
> > Dear Qemu Community,
> >
> > 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 fair as I've read - QEMU user mode emulates ARM syscalls.
>
> It's not strictly an emulation - it is more of a guided pass-through.
> QEMU may tweak details like re-arranging structures or handling
> byte-swapping but ultimately the syscall is passed down to the host
> system.
This means that clock_settime64 will run clock_settime on the host
system (x86_64 in my case) and adjust its time. My goal is to avoid
adjusting host time in any way.
>
> > 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.
>
> This will set the time on your host system.
Ok. Thanks for the clarification.
>
> > 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=).
>
> No - most of the command line switches pertain to memory layout and
> how libraries are searched for. The details of the results of system
> calls are very much left up to the host.
>
> >
> > - 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]).
>
> Hmm since 5bcb4986384e02669418a411cac10377cf48e698 the syscall table
> has had mappings for all of those:
>
> # 402 is unused
> 403 common clock_gettime64
> sys_clock_gettime 404 common clock_settime64
> sys_clock_settime 405 common
> clock_adjtime64 sys_clock_adjtime
>
Ok. I've been using v5.1.0 instead of -master branch.
> >
> > 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(0x0007,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
> >
> > 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]?
>
> It's certainly a bug if it's not working for you.
>
> >
> > 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?
>
> Unlikely - but you could carry a local patch for your own purposes.
>
My goal would be to test if syscalls with 64 bit time (e.g. struct
timespec) work correctly, so I would need to adjust many syscalls as I
do test for example if futex change times out.
It looks like having Yocto/OE crafted BSP with qemu-system-arm is a
better solution as I do have proper syscalls support out of the box.
Anyway, big thanks for the clarification.
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: lu...@denx.de
pgpvZ5pcPUEtY.pgp
Description: OpenPGP digital signature
Re: [QEMU] Question regarding user mode support for ARM syscalls
Hi Alistair,
> On Tue, Nov 3, 2020 at 8:55 AM Lukasz Majewski wrote:
> >
> > Hi Alistair,
> >
> > > On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski
> > > 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(0x0007,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
Re: [QEMU] Question regarding user mode support for ARM syscalls
Lukasz Majewski writes:
> Dear Qemu Community,
>
> 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 fair as I've read - QEMU user mode emulates ARM syscalls.
It's not strictly an emulation - it is more of a guided pass-through.
QEMU may tweak details like re-arranging structures or handling
byte-swapping but ultimately the syscall is passed down to the host
system.
> 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.
This will set the time on your host system.
> 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=).
No - most of the command line switches pertain to memory layout and how
libraries are searched for. The details of the results of system calls
are very much left up to the host.
>
> - 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]).
Hmm since 5bcb4986384e02669418a411cac10377cf48e698 the syscall table has
had mappings for all of those:
# 402 is unused
403 common clock_gettime64 sys_clock_gettime
404 common clock_settime64 sys_clock_settime
405 common clock_adjtime64 sys_clock_adjtime
>
> 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(0x0007,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
>
> 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]?
It's certainly a bug if it's not working for you.
>
> 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?
Unlikely - but you could carry a local patch for your own purposes.
--
Alex Bennée
Re: [QEMU] Question regarding user mode support for ARM syscalls
On Tue, Nov 3, 2020 at 8:55 AM Lukasz Majewski wrote:
>
> Hi Alistair,
>
> > On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski 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(0x0007,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
Re: [QEMU] Question regarding user mode support for ARM syscalls
Hi Alistair,
> On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski 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(0x0007,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
> > #include
> >
> > int main (int argc, char **argv)
> > {
> > struct timespec tv;
> > int ret;
> >
> > tv.tv_sec = 0x7FFF;
> > tv.tv_sec += 61;
> > tv.tv_nsec = 0;
> >
> > printf("clock_settime test program: ");
> > ret = clock_settime(CLOCK_REALTIME, );
> >
Re: [QEMU] Question regarding user mode support for ARM syscalls
On Tue, Nov 3, 2020 at 3:03 AM Lukasz Majewski 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(0x0007,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
> #include
>
> int main (int argc, char **argv)
> {
> struct timespec tv;
> int ret;
>
> tv.tv_sec = 0x7FFF;
> tv.tv_sec += 61;
> tv.tv_nsec = 0;
>
> printf("clock_settime test program: ");
> ret = clock_settime(CLOCK_REALTIME, );
> 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: lu...@denx.de
[QEMU] Question regarding user mode support for ARM syscalls
Dear Qemu Community,
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 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]).
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(0x0007,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
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]?
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?
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
#include
int main (int argc, char **argv)
{
struct timespec tv;
int ret;
tv.tv_sec = 0x7FFF;
tv.tv_sec += 61;
tv.tv_nsec = 0;
printf("clock_settime test program: ");
ret = clock_settime(CLOCK_REALTIME, );
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: lu...@denx.de
pgpj3Hdt62hNP.pgp
Description: OpenPGP digital signature
