linux-user/alpha/syscall_nr.h | 35 +++++++++++++++++ linux-user/arm/syscall_nr.h | 44 +++++++++++++++++++++ linux-user/m68k/syscall_nr.h | 50 +++++++++++++++++++++++- linux-user/microblaze/syscall_nr.h | 45 ++++++++++++++++++++++ linux-user/mips/cpu_loop.c | 78 +++++++++++++++++++++++++++++++++++++- linux-user/mips/syscall_nr.h | 45 ++++++++++++++++++++++ linux-user/mips64/syscall_nr.h | 13 +++++++ linux-user/sh4/syscall_nr.h | 48 +++++++++++++++++++++++ linux-user/x86_64/syscall_nr.h | 24 ++++++++++++ linux-user/xtensa/syscall_nr.h | 36 +++++++++++++++++- 10 files changed, 414 insertions(+), 4 deletions(-)
From: Aleksandar Markovic <amarkovic@wavecomp.com> Hello, folks! This series is a spin-off of another larger linux-user series that become too large to handle, hence these patches related to syscall numbers are now in this, separate, series. Now that kernel 5.5 is released few days ago, it is time to reflect what can be updated in linux-user for upcomming QEMU 5.0. An obvoius kernel change we should take into account are new system calls, and the foirst step is updating syscall numbers mainteined within QEMU linux-user. Regarding kernel syscal numbers there is good news and bad news. The good news is that kernel developers decided to make future syscall numbers much more synchonized accross architectures than before. They already reached that state. The bad news is that we in QEMU did not reach that state yet, since we lag after kernel significantly. The good news again is that we will reach that state if we update syscall numbers accross the board now. This is the main intention and motivation of this series. The bad news again is that in order to update syscall numebrs we need to be very careful at this moment. There are a number of new syscalls added to the kernel recently that QEMU doesn't know about at all. Significant number of new syscalls deal with 32/64-bit compatibility, traditionally a problematic area in kernel, and in QEMU as well. Moreover, some of the new syscalls are applicable to 32-bit architectures only. This series covers updating syscall numbers defined in the following files: - linux-user/alpha/syscall_nr.h - linux-user/arm/syscall_nr.h - linux-user/m68k/syscall_nr.h - linux-user/microblaze/syscall_nr.h - linux-user/mips/cpu_loop.c - linux-user/mips/syscall_nr.h - linux-user/mips64/syscall_nr.h - linux-user/sh4/syscall_nr.h - linux-user/x86_64/syscall_nr.h - linux-user/xtensa/syscall_nr.h This series doesn't cover following files (since they use certain proprietary rules for mapping between kernel source and qemu source, I don't feel quite comfortable changing them - therefore I am asking corresponding target maintainers or Lauren to update them, if possible, before our 5.0 release): - linux-user/aarch64/syscall_nr.h - linux-user/i386/syscall_nr.h - linux-user/nios2/syscall_nr.h - linux-user/ppc/syscall_nr.h - linux-user/riscv/syscall_nr.h - linux-user/s390x/syscall_nr.h - linux-user/sparc/syscall_nr.h - linux-user/sparc64/syscall_nr.h CC: Peter Maydell <peter.maydell@linaro.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Richard Henderson <rth@twiddle.net> CC: Eduardo Habkost <ehabkost@redhat.com> CC: Chris Wulff <crwulff@gmail.com> CC: Marek Vasut <marex@denx.de> CC: David Gibson <david@gibson.dropbear.id.au> CC: Palmer Dabbelt <palmer@dabbelt.com> CC: Alistair Francis <Alistair.Francis@wdc.com> CC: Sagar Karandikar <sagark@eecs.berkeley.edu> CC: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> CC: David Hildenbrand <david@redhat.com> CC: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> CC: Artyom Tarasenko <atar4qemu@gmail.com> This series also doesn't cover following files (since I can't find corresponding kernel code - and I am also asking corresponding target maintainers or Lauren to update them, if possible, before our 5.0 release): - linux-user/cris/cpu_loop.c - linux-user/hppa/syscall_nr.h - linux-user/openrisc/syscall_nr.h - linux-user/tilegx/syscall_nr.h CC: Edgar E. Iglesias <edgar.iglesias@gmail.com> CC: Richard Henderson <rth@twiddle.net> CC: Stafford Horne <shorne@gmail.com> Again, I don't plan (I am really running out of time resources) to work in a significant way on this issue any more, and I am asking you guys other maintainers to help finish updating syscall numbers before QEMU 5.0 release. Once we do that, updating syscall numbers in QEMU should and will be significantly easier. Thanks in advance! Truly yours, Aleksandar ----------------------------------------------------------------------- Aleksandar Markovic (9): linux-user: alpha: Update syscall numbers to kernel 5.5 level linux-user: arm: Update syscall numbers to kernel 5.5 level linux-user: m68k: Update syscall numbers to kernel 5.5 level linux-user: microblaze: Update syscall numbers to kernel 5.5 level linux-user: mips: Update syscall numbers to kernel 5.5 level linux-user: sh4: Update syscall numbers to kernel 5.5 level linux-user: x86_64: Update syscall numbers to kernel 5.5 level linux-user: xtensa: Update syscall numbers to kernel 5.5 level linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count linux-user/alpha/syscall_nr.h | 35 +++++++++++++++++ linux-user/arm/syscall_nr.h | 44 +++++++++++++++++++++ linux-user/m68k/syscall_nr.h | 50 +++++++++++++++++++++++- linux-user/microblaze/syscall_nr.h | 45 ++++++++++++++++++++++ linux-user/mips/cpu_loop.c | 78 +++++++++++++++++++++++++++++++++++++- linux-user/mips/syscall_nr.h | 45 ++++++++++++++++++++++ linux-user/mips64/syscall_nr.h | 13 +++++++ linux-user/sh4/syscall_nr.h | 48 +++++++++++++++++++++++ linux-user/x86_64/syscall_nr.h | 24 ++++++++++++ linux-user/xtensa/syscall_nr.h | 36 +++++++++++++++++- 10 files changed, 414 insertions(+), 4 deletions(-) -- 2.7.4
On Tue, Feb 4, 2020 at 1:08 PM Aleksandar Markovic <aleksandar.markovic@rt-rk.com> wrote: > > From: Aleksandar Markovic <amarkovic@wavecomp.com> > > Hello, folks! > > This series is a spin-off of another larger linux-user series > that become too large to handle, hence these patches related to > syscall numbers are now in this, separate, series. > I forgot to say that, compared to the previous larger linux-user series, two new patches are added (arm and sh4 related), and the remaining seven patches are identical (except that "R-b:"s and "A-b:"s are added when needed). Sincerely, Aleksandar > Now that kernel 5.5 is released few days ago, it is time to > reflect what can be updated in linux-user for upcomming QEMU 5.0. > > An obvoius kernel change we should take into account are new > system calls, and the foirst step is updating syscall numbers > mainteined within QEMU linux-user. > > Regarding kernel syscal numbers there is good news and bad news. > > The good news is that kernel developers decided to make future > syscall numbers much more synchonized accross architectures than > before. They already reached that state. > > The bad news is that we in QEMU did not reach that state yet, since > we lag after kernel significantly. > > The good news again is that we will reach that state if we update > syscall numbers accross the board now. This is the main intention > and motivation of this series. > > The bad news again is that in order to update syscall numebrs we > need to be very careful at this moment. There are a number of new > syscalls added to the kernel recently that QEMU doesn't know about > at all. Significant number of new syscalls deal with 32/64-bit > compatibility, traditionally a problematic area in kernel, and in > QEMU as well. Moreover, some of the new syscalls are applicable to > 32-bit architectures only. > > This series covers updating syscall numbers defined in the following > files: > > - linux-user/alpha/syscall_nr.h > - linux-user/arm/syscall_nr.h > - linux-user/m68k/syscall_nr.h > - linux-user/microblaze/syscall_nr.h > - linux-user/mips/cpu_loop.c > - linux-user/mips/syscall_nr.h > - linux-user/mips64/syscall_nr.h > - linux-user/sh4/syscall_nr.h > - linux-user/x86_64/syscall_nr.h > - linux-user/xtensa/syscall_nr.h > > This series doesn't cover following files (since they use certain > proprietary rules for mapping between kernel source and qemu source, > I don't feel quite comfortable changing them - therefore I am asking > corresponding target maintainers or Lauren to update them, if > possible, before our 5.0 release): > > - linux-user/aarch64/syscall_nr.h > - linux-user/i386/syscall_nr.h > - linux-user/nios2/syscall_nr.h > - linux-user/ppc/syscall_nr.h > - linux-user/riscv/syscall_nr.h > - linux-user/s390x/syscall_nr.h > - linux-user/sparc/syscall_nr.h > - linux-user/sparc64/syscall_nr.h > > CC: Peter Maydell <peter.maydell@linaro.org> > CC: Paolo Bonzini <pbonzini@redhat.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Eduardo Habkost <ehabkost@redhat.com> > CC: Chris Wulff <crwulff@gmail.com> > CC: Marek Vasut <marex@denx.de> > CC: David Gibson <david@gibson.dropbear.id.au> > CC: Palmer Dabbelt <palmer@dabbelt.com> > CC: Alistair Francis <Alistair.Francis@wdc.com> > CC: Sagar Karandikar <sagark@eecs.berkeley.edu> > CC: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> > CC: David Hildenbrand <david@redhat.com> > CC: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> > CC: Artyom Tarasenko <atar4qemu@gmail.com> > > This series also doesn't cover following files (since I can't find > corresponding kernel code - and I am also asking corresponding > target maintainers or Lauren to update them, if possible, before > our 5.0 release): > > - linux-user/cris/cpu_loop.c > - linux-user/hppa/syscall_nr.h > - linux-user/openrisc/syscall_nr.h > - linux-user/tilegx/syscall_nr.h > > CC: Edgar E. Iglesias <edgar.iglesias@gmail.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Stafford Horne <shorne@gmail.com> > > Again, I don't plan (I am really running out of time resources) to > work in a significant way on this issue any more, and I am asking > you guys other maintainers to help finish updating syscall numbers > before QEMU 5.0 release. > > Once we do that, updating syscall numbers in QEMU should and will > be significantly easier. > > Thanks in advance! > > Truly yours, > Aleksandar > > ----------------------------------------------------------------------- > > Aleksandar Markovic (9): > linux-user: alpha: Update syscall numbers to kernel 5.5 level > linux-user: arm: Update syscall numbers to kernel 5.5 level > linux-user: m68k: Update syscall numbers to kernel 5.5 level > linux-user: microblaze: Update syscall numbers to kernel 5.5 level > linux-user: mips: Update syscall numbers to kernel 5.5 level > linux-user: sh4: Update syscall numbers to kernel 5.5 level > linux-user: x86_64: Update syscall numbers to kernel 5.5 level > linux-user: xtensa: Update syscall numbers to kernel 5.5 level > linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count > > linux-user/alpha/syscall_nr.h | 35 +++++++++++++++++ > linux-user/arm/syscall_nr.h | 44 +++++++++++++++++++++ > linux-user/m68k/syscall_nr.h | 50 +++++++++++++++++++++++- > linux-user/microblaze/syscall_nr.h | 45 ++++++++++++++++++++++ > linux-user/mips/cpu_loop.c | 78 +++++++++++++++++++++++++++++++++++++- > linux-user/mips/syscall_nr.h | 45 ++++++++++++++++++++++ > linux-user/mips64/syscall_nr.h | 13 +++++++ > linux-user/sh4/syscall_nr.h | 48 +++++++++++++++++++++++ > linux-user/x86_64/syscall_nr.h | 24 ++++++++++++ > linux-user/xtensa/syscall_nr.h | 36 +++++++++++++++++- > 10 files changed, 414 insertions(+), 4 deletions(-) > > -- > 2.7.4 > >
Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit : > From: Aleksandar Markovic <amarkovic@wavecomp.com> > > Hello, folks! > > This series is a spin-off of another larger linux-user series > that become too large to handle, hence these patches related to > syscall numbers are now in this, separate, series. > > Now that kernel 5.5 is released few days ago, it is time to > reflect what can be updated in linux-user for upcomming QEMU 5.0. > > An obvoius kernel change we should take into account are new > system calls, and the foirst step is updating syscall numbers > mainteined within QEMU linux-user. > > Regarding kernel syscal numbers there is good news and bad news. > > The good news is that kernel developers decided to make future > syscall numbers much more synchonized accross architectures than > before. They already reached that state. > > The bad news is that we in QEMU did not reach that state yet, since > we lag after kernel significantly. > > The good news again is that we will reach that state if we update > syscall numbers accross the board now. This is the main intention > and motivation of this series. > > The bad news again is that in order to update syscall numebrs we > need to be very careful at this moment. There are a number of new > syscalls added to the kernel recently that QEMU doesn't know about > at all. Significant number of new syscalls deal with 32/64-bit > compatibility, traditionally a problematic area in kernel, and in > QEMU as well. Moreover, some of the new syscalls are applicable to > 32-bit architectures only. > > This series covers updating syscall numbers defined in the following > files: > > - linux-user/alpha/syscall_nr.h > - linux-user/arm/syscall_nr.h > - linux-user/m68k/syscall_nr.h > - linux-user/microblaze/syscall_nr.h > - linux-user/mips/cpu_loop.c > - linux-user/mips/syscall_nr.h > - linux-user/mips64/syscall_nr.h > - linux-user/sh4/syscall_nr.h > - linux-user/x86_64/syscall_nr.h > - linux-user/xtensa/syscall_nr.h > > This series doesn't cover following files (since they use certain > proprietary rules for mapping between kernel source and qemu source, > I don't feel quite comfortable changing them - therefore I am asking > corresponding target maintainers or Lauren to update them, if > possible, before our 5.0 release): > > - linux-user/aarch64/syscall_nr.h > - linux-user/i386/syscall_nr.h > - linux-user/nios2/syscall_nr.h > - linux-user/ppc/syscall_nr.h > - linux-user/riscv/syscall_nr.h > - linux-user/s390x/syscall_nr.h > - linux-user/sparc/syscall_nr.h > - linux-user/sparc64/syscall_nr.h > > CC: Peter Maydell <peter.maydell@linaro.org> > CC: Paolo Bonzini <pbonzini@redhat.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Eduardo Habkost <ehabkost@redhat.com> > CC: Chris Wulff <crwulff@gmail.com> > CC: Marek Vasut <marex@denx.de> > CC: David Gibson <david@gibson.dropbear.id.au> > CC: Palmer Dabbelt <palmer@dabbelt.com> > CC: Alistair Francis <Alistair.Francis@wdc.com> > CC: Sagar Karandikar <sagark@eecs.berkeley.edu> > CC: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> > CC: David Hildenbrand <david@redhat.com> > CC: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> > CC: Artyom Tarasenko <atar4qemu@gmail.com> > > This series also doesn't cover following files (since I can't find > corresponding kernel code - and I am also asking corresponding > target maintainers or Lauren to update them, if possible, before > our 5.0 release): > > - linux-user/cris/cpu_loop.c > - linux-user/hppa/syscall_nr.h > - linux-user/openrisc/syscall_nr.h > - linux-user/tilegx/syscall_nr.h > > CC: Edgar E. Iglesias <edgar.iglesias@gmail.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Stafford Horne <shorne@gmail.com> > > Again, I don't plan (I am really running out of time resources) to > work in a significant way on this issue any more, and I am asking > you guys other maintainers to help finish updating syscall numbers > before QEMU 5.0 release. > > Once we do that, updating syscall numbers in QEMU should and will > be significantly easier. > I think we should copy the syscall.tbl and syscallhdr.sh scripts from the linux tree and update syscallhdr.sh to generate our syscall_nr.h I think it can be done in an easy way for most of our targets, except some like mips that mixes o32, n32, n64 and a special table inside cpu_loop.c I will merge your patches (please update the mips one) as the work is already done but I will have a look to try to generate them for the next time from the kernel tables. Thanks, Laurent
Le 12/02/2020 à 22:34, Laurent Vivier a écrit : > Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit : >> From: Aleksandar Markovic <amarkovic@wavecomp.com> >> >> Hello, folks! >> >> This series is a spin-off of another larger linux-user series >> that become too large to handle, hence these patches related to >> syscall numbers are now in this, separate, series. >> >> Now that kernel 5.5 is released few days ago, it is time to >> reflect what can be updated in linux-user for upcomming QEMU 5.0. >> >> An obvoius kernel change we should take into account are new >> system calls, and the foirst step is updating syscall numbers >> mainteined within QEMU linux-user. >> >> Regarding kernel syscal numbers there is good news and bad news. >> >> The good news is that kernel developers decided to make future >> syscall numbers much more synchonized accross architectures than >> before. They already reached that state. >> >> The bad news is that we in QEMU did not reach that state yet, since >> we lag after kernel significantly. >> >> The good news again is that we will reach that state if we update >> syscall numbers accross the board now. This is the main intention >> and motivation of this series. >> >> The bad news again is that in order to update syscall numebrs we >> need to be very careful at this moment. There are a number of new >> syscalls added to the kernel recently that QEMU doesn't know about >> at all. Significant number of new syscalls deal with 32/64-bit >> compatibility, traditionally a problematic area in kernel, and in >> QEMU as well. Moreover, some of the new syscalls are applicable to >> 32-bit architectures only. >> >> This series covers updating syscall numbers defined in the following >> files: >> >> - linux-user/alpha/syscall_nr.h >> - linux-user/arm/syscall_nr.h >> - linux-user/m68k/syscall_nr.h >> - linux-user/microblaze/syscall_nr.h >> - linux-user/mips/cpu_loop.c >> - linux-user/mips/syscall_nr.h >> - linux-user/mips64/syscall_nr.h >> - linux-user/sh4/syscall_nr.h >> - linux-user/x86_64/syscall_nr.h >> - linux-user/xtensa/syscall_nr.h >> >> This series doesn't cover following files (since they use certain >> proprietary rules for mapping between kernel source and qemu source, >> I don't feel quite comfortable changing them - therefore I am asking >> corresponding target maintainers or Lauren to update them, if >> possible, before our 5.0 release): >> >> - linux-user/aarch64/syscall_nr.h >> - linux-user/i386/syscall_nr.h >> - linux-user/nios2/syscall_nr.h >> - linux-user/ppc/syscall_nr.h >> - linux-user/riscv/syscall_nr.h >> - linux-user/s390x/syscall_nr.h >> - linux-user/sparc/syscall_nr.h >> - linux-user/sparc64/syscall_nr.h >> >> CC: Peter Maydell <peter.maydell@linaro.org> >> CC: Paolo Bonzini <pbonzini@redhat.com> >> CC: Richard Henderson <rth@twiddle.net> >> CC: Eduardo Habkost <ehabkost@redhat.com> >> CC: Chris Wulff <crwulff@gmail.com> >> CC: Marek Vasut <marex@denx.de> >> CC: David Gibson <david@gibson.dropbear.id.au> >> CC: Palmer Dabbelt <palmer@dabbelt.com> >> CC: Alistair Francis <Alistair.Francis@wdc.com> >> CC: Sagar Karandikar <sagark@eecs.berkeley.edu> >> CC: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> >> CC: David Hildenbrand <david@redhat.com> >> CC: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> >> CC: Artyom Tarasenko <atar4qemu@gmail.com> >> >> This series also doesn't cover following files (since I can't find >> corresponding kernel code - and I am also asking corresponding >> target maintainers or Lauren to update them, if possible, before >> our 5.0 release): >> >> - linux-user/cris/cpu_loop.c >> - linux-user/hppa/syscall_nr.h >> - linux-user/openrisc/syscall_nr.h >> - linux-user/tilegx/syscall_nr.h >> >> CC: Edgar E. Iglesias <edgar.iglesias@gmail.com> >> CC: Richard Henderson <rth@twiddle.net> >> CC: Stafford Horne <shorne@gmail.com> >> >> Again, I don't plan (I am really running out of time resources) to >> work in a significant way on this issue any more, and I am asking >> you guys other maintainers to help finish updating syscall numbers >> before QEMU 5.0 release. >> >> Once we do that, updating syscall numbers in QEMU should and will >> be significantly easier. >> > > I think we should copy the syscall.tbl and syscallhdr.sh scripts from > the linux tree and update syscallhdr.sh to generate our syscall_nr.h I made a draft here: https://github.com/vivier/qemu/commits/linux-user-syscalltbl Thanks, Laurent
On Tue, Feb 04, 2020 at 01:07:29PM +0100, Aleksandar Markovic wrote: > From: Aleksandar Markovic <amarkovic@wavecomp.com> > > This series also doesn't cover following files (since I can't find > corresponding kernel code - and I am also asking corresponding > target maintainers or Lauren to update them, if possible, before > our 5.0 release): OpenRISC is in the kernel under arch/openrisc and the syscall numbers we user are just like other architectures, it's in: linux/arch/openrisc/include/uapi/asm/unistd.h This then includes the generic numbers: linux/include/uapi/asm-generic/unistd.h There are other architectures in the kernel, like arm64, risvc, nios2 using the generic syscall numbers. Should QEMU also have linux-user/generic/syscall_nr.h that mirrors the generic file in linux? This way this could be maintained in just one place. > - linux-user/cris/cpu_loop.c > - linux-user/hppa/syscall_nr.h > - linux-user/openrisc/syscall_nr.h > - linux-user/tilegx/syscall_nr.h > > CC: Edgar E. Iglesias <edgar.iglesias@gmail.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Stafford Horne <shorne@gmail.com> > > Again, I don't plan (I am really running out of time resources) to > work in a significant way on this issue any more, and I am asking > you guys other maintainers to help finish updating syscall numbers > before QEMU 5.0 release. I actually have a patch to add syscall numbers for openrisc which I am using to test our new glibc port right now. I will clean if up and submit for review. It looks like for 5.0 we would need to get changes in by March 23: https://wiki.qemu.org/Planning/5.0 I'll try to aim to get my change up for review soon then. -Stafford
© 2016 - 2024 Red Hat, Inc.