From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56E7FC282DD for ; Wed, 8 Jan 2020 16:41:35 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2C7F820692 for ; Wed, 8 Jan 2020 16:41:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C7F820692 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipEOk-0000zi-Cs for qemu-devel@archiver.kernel.org; Wed, 08 Jan 2020 11:41:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34477) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipEO0-0000TZ-WB for qemu-devel@nongnu.org; Wed, 08 Jan 2020 11:40:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipENz-0005os-NP for qemu-devel@nongnu.org; Wed, 08 Jan 2020 11:40:48 -0500 Received: from indium.canonical.com ([91.189.90.7]:42028) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ipENz-0005my-Hj for qemu-devel@nongnu.org; Wed, 08 Jan 2020 11:40:47 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1ipENx-0000es-S8 for ; Wed, 08 Jan 2020 16:40:45 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id D04612E806D for ; Wed, 8 Jan 2020 16:40:45 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 08 Jan 2020 16:32:17 -0000 From: Aleksandar Markovic <1858461@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: aladjev-andrew amarkovic X-Launchpad-Bug-Reporter: puchuu (aladjev-andrew) X-Launchpad-Bug-Modifier: Aleksandar Markovic (amarkovic) References: <157833123209.15024.12557979334447840996.malonedeb@wampee.canonical.com> Message-Id: <157850113782.3101.13592251581816371892.malone@soybean.canonical.com> Subject: [Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="bceb5ef013b87ef7aafe0755545ceb689ca7ac60"; Instance="production-secrets-lazr.conf" X-Launchpad-Hash: 664a7ceafdb979d7176971eef0aaea8b3e2790c7 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 91.189.90.7 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1858461 <1858461@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Andrew, Please take a look at the patch: http://patchwork.ozlabs.org/patch/1217454/ Once you apply the patch, it should be straightforward to add getdents64_x32() (right after clone3()) for all MIPS ABIs. The thing is, kernel folks recently made some rearrangements of syscall numbers, so that all architectures have in future "similar" syscall numbers, but that required some "holes" in syscall numbers schemes for virtuall all archs, and for MIPS among them. That is why ne array in linux-user/mips/cpu_loop.c has some elements defined just as "0" - they are there just to adjust syscall numbers to be in accordance with the new scheme. Please let us know if you are able to work with such solution or not. Happy New Year! Aleksandar -- = 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 =3D env->active_tc.gpr[2] - 4000; if (syscall_num >=3D sizeof(mips_syscall_args)) { ret =3D -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