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,
CONECT LOCAL MACHINE TO VIRTUAL MACHINE
Hi My name Harbey I´m new using QEMU, I installed a CENTOS 8 VM with QEMU, the local machine is a CENTOS 7, but i have some problems setting the network, how I can fix it, or when i find documentation or information to set the VM and the local machine with local network. Thank you. *HARBEY JAIR GUERRERO BULLA**Coordinador de TI* UNIHILO Hilanderías Universal S.A.S hguerr...@unihilo.com.co Tel. (571) 4473661 Bogotá D.C. - Colombia Por medio del presente aviso informamos que los datos personales recogidos por medio de este canal de comunicación, serán tratados conforme a la Ley 1581 de 2012 y el Decreto 1377 de 2012, con la finalidad de prestar adecuadamente los productos y servicios que ofrece HILANDERIAS UNIVERSAL S.A.S. La información contenida en este correo electrónico puede tener información confidencial y/o datos personales. En caso de que no sea un destinatario autorizado de este mensaje, notifique de manera inmediata al emisor, borre y destruya este mensaje, incluida la información adjunta. En caso de divulgación, distribución, copia o uso no autorizado es considerado ilegal y se encuentra penalizado por la Ley 1273 de 2009. Tenga en cuenta que los comentarios y opiniones presentados en este correo no son necesariamente en representación de HILANDERIAS UNIVERSAL S.A.S. En caso de reclamo o consulta puede realizarla a través del correo electrónico: protecciondeda...@unihilo.com.co Para mayor información acerca del tratamiento de su información personal, lo invitamos a que consulte la Política de Tratamiento de datos personales en http://www.unihilo.com.co/
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
