qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Mike Gelfand <1893003@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1893003] Re: qemu linux-user doesn't translate host/target data for iovec I/O
Date: Wed, 26 Aug 2020 08:43:12 -0000	[thread overview]
Message-ID: <159843139349.16164.4541379650960164501.launchpad@soybean.canonical.com> (raw)
In-Reply-To: 159842808665.2865.2216413646645324343.malonedeb@chaenomeles.canonical.com

** Summary changed:

- qemu-user doesn't translate host/target data for iovec I/O
+ qemu linux-user doesn't translate host/target data for iovec I/O

** Tags added: linux-user

** Tags added: ppc s390x

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

Title:
  qemu linux-user doesn't translate host/target data for iovec I/O

Status in QEMU:
  New

Bug description:
  When using iovec I/O functions (like `readv`), no data translation
  happens. I'm hitting this issue with libevent upon constructing a
  bufferevent over an inotify descriptor, and then building for either
  ppc64 or s390x (both big-endian) on x86_64 (little-endian) and running
  resulting code with qemu-ppc64 or qemu-s390x on Gentoo using latest
  QEMU version available (5.0.0-r2).

  The code in question is in
  https://github.com/transmission/transmission/blob/master/libtransmission
  /watchdir-inotify.c (`tr_watchdir_inotify_new`,
  `tr_watchdir_inotify_on_event`).

  While `read` syscall is handled properly, `readv` (which libevent is
  using in my case) doesn't have any logic to call
  `host_to_target_data_inotify` or any other translation function,
  leaving inotify data unchanged (with values in little-endian), which
  then leads to unit test failures. Quoting `do_syscall1` implementation
  bits for the reference:

  ---8<---begin---
      case TARGET_NR_read:
          if (arg2 == 0 && arg3 == 0) {
              return get_errno(safe_read(arg1, 0, 0));
          } else {
              if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
                  return -TARGET_EFAULT;
              ret = get_errno(safe_read(arg1, p, arg3));
              if (ret >= 0 &&
                  fd_trans_host_to_target_data(arg1)) {
                  ret = fd_trans_host_to_target_data(arg1)(p, ret);
              }
              unlock_user(p, arg2, ret);
          }
          return ret;
  ...
      case TARGET_NR_readv:
          {
              struct iovec *vec = lock_iovec(VERIFY_WRITE, arg2, arg3, 0);
              if (vec != NULL) {
                  ret = get_errno(safe_readv(arg1, vec, arg3));
                  unlock_iovec(vec, arg2, arg3, 1);
              } else {
                  ret = -host_to_target_errno(errno);
              }
          }
          return ret;
  ---8<---end---

  To reiterate, the issue is not only with `readv` but with other iovec
  functions as well.

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


  reply	other threads:[~2020-08-26  8:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-26  7:48 [Bug 1893003] [NEW] qemu-user doesn't translate host/target data for iovec I/O Mike Gelfand
2020-08-26  8:43 ` Mike Gelfand [this message]
2020-08-27  8:40 ` [Bug 1893003] Re: qemu linux-user " Mike Gelfand
2021-05-11  7:59 ` Thomas Huth
2021-06-17  7:12 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=159843139349.16164.4541379650960164501.launchpad@soybean.canonical.com \
    --to=1893003@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).