Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level

2020-02-12 Thread Laurent Vivier
Le 12/02/2020 à 22:34, Laurent Vivier a écrit :
> Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit :
>> From: Aleksandar Markovic 
>>
>> 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 
>> CC: Paolo Bonzini 
>> CC: Richard Henderson 
>> CC: Eduardo Habkost 
>> CC: Chris Wulff 
>> CC: Marek Vasut 
>> CC: David Gibson 
>> CC: Palmer Dabbelt 
>> CC: Alistair Francis 
>> CC: Sagar Karandikar 
>> CC: Bastian Koppelmann 
>> CC: David Hildenbrand 
>> CC: Mark Cave-Ayland 
>> CC: Artyom Tarasenko 
>>
>> 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 
>> CC: Richard Henderson 
>> CC: Stafford Horne 
>>
>> 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




Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level

2020-02-12 Thread Laurent Vivier
Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic 
> 
> 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 
> CC: Paolo Bonzini 
> CC: Richard Henderson 
> CC: Eduardo Habkost 
> CC: Chris Wulff 
> CC: Marek Vasut 
> CC: David Gibson 
> CC: Palmer Dabbelt 
> CC: Alistair Francis 
> CC: Sagar Karandikar 
> CC: Bastian Koppelmann 
> CC: David Hildenbrand 
> CC: Mark Cave-Ayland 
> CC: Artyom Tarasenko 
> 
> 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 
> CC: Richard Henderson 
> CC: Stafford Horne 
> 
> 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



Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level

2020-02-05 Thread Stafford Horne
On Tue, Feb 04, 2020 at 01:07:29PM +0100, Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
> 
> 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 
> CC: Richard Henderson 
> CC: Stafford Horne 
> 
> 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 



Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level

2020-02-04 Thread Aleksandar Markovic
On Tue, Feb 4, 2020 at 1:08 PM Aleksandar Markovic
 wrote:
>
> From: Aleksandar Markovic 
>
> 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 
> CC: Paolo Bonzini 
> CC: Richard Henderson 
> CC: Eduardo Habkost 
> CC: Chris Wulff 
> CC: Marek Vasut 
> CC: David Gibson 
> CC: Palmer Dabbelt 
> CC: Alistair Francis 
> CC: Sagar Karandikar 
> CC: Bastian Koppelmann 
> CC: David Hildenbrand 
> CC: Mark Cave-Ayland 
> CC: Artyom Tarasenko 
>
> 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 
> CC: Richard Henderson 
> CC: Stafford Horne 
>
> 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 

[PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level

2020-02-04 Thread Aleksandar Markovic
From: Aleksandar Markovic 

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 
CC: Paolo Bonzini 
CC: Richard Henderson 
CC: Eduardo Habkost 
CC: Chris Wulff 
CC: Marek Vasut 
CC: David Gibson 
CC: Palmer Dabbelt 
CC: Alistair Francis 
CC: Sagar Karandikar 
CC: Bastian Koppelmann 
CC: David Hildenbrand 
CC: Mark Cave-Ayland 
CC: Artyom Tarasenko 

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 
CC: Richard Henderson 
CC: Stafford Horne 

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