qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c


From: puchuu
Subject: [Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c
Date: Wed, 08 Jan 2020 16:56:06 -0000

Hello, thank you. I want to introduce another patch with syscalls
related generator. Please review it.

I think about the following development flow:

1. Kernel updates and maintains "tbl".
2. Qemu developer wants to implement new syscall (like clone3) in 
"linux-user/syscall.c".
3. Developer clones new kernel into some directory and runs generators.
4. All syscall related stuff will be updated immediately.

I think it will very straightforward solution. Qemu won't hardcode
kernel related stuff and all linkage between kernel and qemu will be
very easy.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1858461

Title:
  Please refactor linux-user/mips/cpu_loop.c

Status in QEMU:
  New

Bug description:
  Hello. I am working with qemu on test images. I've added a new syscall
  (436) to qemu but received ENOSYS from mips application.

  Please open "linux-user/mips/cpu_loop.c". I've added at the end of
  "mips_syscall_args" the following:

  ```
  MIPS_SYS(sys_getdents64_x32, 3)
  ```

  But

  ```
  syscall_num = env->active_tc.gpr[2] - 4000;
  if (syscall_num >= sizeof(mips_syscall_args)) {
    ret = -TARGET_ENOSYS;
  ```

  returns -TARGET_ENOSYS

  We can see that "linux-user/mips/cpu_loop.c" differs a lot from
  "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc.

  Can you please refactor mips cpu loop in the same way as arm? Thank
  you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1858461/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]