blob: 7cdae503fe85d1672fb4d8174f76f0d733a49c39 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, I need to classify this bug report about QEMU Linux-user not translating host/target data for iovec I/O functions like readv into either 'user' or 'system'. Let's break it down.
The issue occurs when using readv with libevent on big-endian targets (ppc64 or s390x) running on x86_64. The problem is that the data isn't being translated between host and target endianness, causing failures in unit tests.
Looking at the code snippets provided, especially the do_syscall1 function, I see that for the read syscall (TARGET_NR_read), there's handling to translate data using fd_trans_host_to_target_data. However, for readv (TARGET_NR_readv), such translation isn't happening. The code locks and unlocks the iovec but doesn't apply any translation after reading.
This seems related to how user-space applications interact with system calls in QEMU's user mode emulation. Since it's about data translation during I/O operations handled by user-mode syscalls, it falls under user-mode issues. System-mode would typically involve lower-level hardware or device handling, which isn't the case here.
So, the bug is within the user-mode emulation part of QEMU, specifically in how readv and similar iovec functions handle data translation between host and target architectures.
</think>
user
|