bsd-user upstreaming: read, write and exit
This series of patches continues the effort to get system calls working
upstream. This series was cleaved off a prior series to give me time to rework
based on the feedback from the first time I posted these. read, write and exit
are implemented, along with a few helper functions and tracing.
# -----BEGIN PGP SIGNATURE-----
# Comment: GPGTools - https://gpgtools.org
#
# iQIzBAABCgAdFiEEIDX4lLAKo898zeG3bBzRKH2wEQAFAmKknqsACgkQbBzRKH2w
# EQDJFhAA3ARnphfxKUvKHzi6ARza8YRFNJs/X48l78xugW8Fx2+UFxn/oPzVYuM3
# TUIIRNIXQxYDWP5rNN4zNfYjn1F32qx4PrLzzHw4t/0pNvNDvbVKyw+OB1pNUVI9
# 6hNH7jTLczi4OwZFPC4bJdFFHI55t4PCHxPaMQQO76lEsFzz3+9OcNNj3/j5aTBH
# kY3FsmOIKFEFuqDANjdn13lBlkNNWj5WMIsEQd+k1TPTfG3EWDlfHVJVezx9j5uH
# KMUjRRqBANLVJuqhog7sVAdkR6o/aKuq16nPVAgkLeJrsjwljoO1bGL3DTFWzhAo
# v3+S3a5gCReLXA/Z+dGCuJysmimsm+XdJWHyNIwDCV/UUg9tXc9/BI/eBSK7MLbz
# hvURY3cRSSVY+xiu5ts1OCp1bbqMaYbpIrv1mLZMA/32Y1KNv0LwSI0ClGag0MJ1
# rSVC3i/TGYn8Dk7TlfKkrKn751ZCCDsxZGROEcPlTV84Mc7080lpgYZKlgLCPJNT
# WWaVSBs9YhHhmoG3R3GurfsHnnRr8Y8iZkmndoCJdeSlmZh/1oD31PWKhnydsPa9
# jQCENkAM0dOM/r+hV+paFxOPkgklu7KLtjqGnVRxgB4j37jA9KDyw+UXLmjipP0K
# IwPlsNIfk1LujID3o5nJVgf/K+TJpXS7JDcUsuB9+FvlkeEMWm8=
# =nOc2
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 11 Jun 2022 06:54:51 AM PDT
# gpg: using RSA key 2035F894B00AA3CF7CCDE1B76C1CD1287DB01100
# gpg: Good signature from "Warner Losh <wlosh@netflix.com>" [unknown]
# gpg: aka "Warner Losh <imp@bsdimp.com>" [unknown]
# gpg: aka "Warner Losh <imp@freebsd.org>" [unknown]
# gpg: aka "Warner Losh <imp@village.org>" [unknown]
# gpg: aka "Warner Losh <wlosh@bsdimp.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 2035 F894 B00A A3CF 7CCD E1B7 6C1C D128 7DB0 1100
* tag 'bsd-user-preen-2022q2-pull-request' of ssh://github.com/qemu-bsd-user/qemu-bsd-user:
bsd-user/freebsd/os-syscall.c: Implement exit
bsd-user/bsd-file.h: Meat of the write system calls
bsd-user/bsd-file.h: Add implementations for read, pread, readv and preadv
bsd-user/freebsd/os-syscall.c: Tracing and error boilerplate
bsd-user/freebsd/os-syscall.c: unlock_iovec
bsd-user/freebsd/os-syscall.c: lock_iovec
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Fixes compilation due to false positives with -Werror:
In file included from /usr/include/glib-2.0/glib.h:114,
from qemu/src/include/glib-compat.h:32,
from qemu/src/include/qemu/osdep.h:144,
from ../src/hw/mips/boston.c:20:
In function ‘g_autoptr_cleanup_generic_gfree’,
inlined from ‘boston_mach_init’ at ../src/hw/mips/boston.c:790:52:
/usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: error: ‘dtb_load_data’ may be used uninitialized [-Werror=maybe-uninitialized]
28 | g_free (*pp);
| ^~~~~~~~~~~~
../src/hw/mips/boston.c: In function ‘boston_mach_init’:
../src/hw/mips/boston.c:790:52: note: ‘dtb_load_data’ was declared here
790 | g_autofree const void *dtb_file_data, *dtb_load_data;
| ^~~~~~~~~~~~~
In function ‘g_autoptr_cleanup_generic_gfree’,
inlined from ‘boston_mach_init’ at ../src/hw/mips/boston.c:790:36:
/usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: error: ‘dtb_file_data’ may be used uninitialized [-Werror=maybe-uninitialized]
28 | g_free (*pp);
| ^~~~~~~~~~~~
../src/hw/mips/boston.c: In function ‘boston_mach_init’:
../src/hw/mips/boston.c:790:36: note: ‘dtb_file_data’ was declared here
790 | g_autofree const void *dtb_file_data, *dtb_load_data;
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220605151908.30566-1-shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Exposing the io_base offset as a QOM property not only allows it to be
configurable but also to be displayed in HMP:
Before:
(qemu) info qtree
...
dev: mc146818rtc, id ""
gpio-out "" 1
base_year = 0 (0x0)
irq = 8 (0x8)
lost_tick_policy = "discard"
After:
dev: mc146818rtc, id ""
gpio-out "" 1
base_year = 0 (0x0)
iobase = 112 (0x70)
irq = 8 (0x8)
lost_tick_policy = "discard"
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220529184006.10712-4-shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
PCI interrupt wiring was performed in create() functions which are
obsolete. Move these tasks into QOM functions to modernize the code.
In order to avoid duplicate checking for xen_enabled() the realize
methods are now split.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20220603185045.143789-10-shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
When QOMifying a device it is typical to use _init() as the suffix for an
instance_init function, however this name is already in use by the legacy
piix4_pm_init() wrapper function. Eventually the wrapper function will be
removed, but for now rename it to piix4_pm_initfn() to avoid a naming
collision.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220528091934.15520-7-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
The sysbus floppy controllers (devices sysbus-fdc and sun-fdtwo)
don't support DMA. The core floppy controller code expects this to
be indicated by setting FDCtrl::dma_chann to -1. This used to be
done in the device instance_init functions sysbus_fdc_initfn() and
sun4m_fdc_initfn(), but in commit 1430759ec3 we refactored this code
and accidentally lost the setting of dma_chann.
For sysbus-fdc this has no ill effects because we were redundantly
also setting dma_chann in fdctrl_init_sysbus(), but for sun-fdtwo
this means that guests which try to enable DMA on the floppy
controller will cause QEMU to crash because FDCtrl::dma is NULL.
Set dma_chann to -1 in the common instance init, and remove the
redundant code in fdctrl_init_sysbus() that is also setting it.
There is a six-year-old FIXME comment in the jazz board code to the
effect that in theory it should support doing DMA via a custom DMA
controller. If anybody ever chooses to fix that they can do it by
adding support for setting both FDCtrl::dma_chann and FDCtrl::dma.
(A QOM link property 'dma-controller' on the sysbus device which can
be set to an instance of IsaDmaClass is probably the way to go.)
Fixes: 1430759ec3 ("hw/block/fdc: Extract SysBus floppy controllers to fdc-sysbus.c")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/958
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20220505101842.2757905-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
nanoMIPS ISA support in QEMU is actively used by MediaTek and is
planned to be maintained and potentially extended by MediaTek in
future.
Un-orphan nanoMIPS ISA support in QEMU by setting a maintainer from
MediaTek and remove deprecation notes from documentation as well.
Signed-off-by: Stefan Pejic <stefan.pejic@syrmia.com>
Message-Id: <20220504110403.613168-8-stefan.pejic@syrmia.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Switch statements for the code segments that handle nanoMIPS
instruction pools P.LL, P.SC, P.SHIFT, P.LS.S1, P.LS.E0, PP.LSXS
do not have proper default case, resulting in not generating
reserved instruction exception for certain illegal opcodes.
Fix this by adding default cases for these switch statements that
trigger reserved instruction exception.
Signed-off-by: Stefan Pejic <stefan.pejic@syrmia.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220504110403.613168-7-stefan.pejic@syrmia.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
If both rs and rt are the same register, the nanoMIPS instruction
BNEC[32] rs, rt, address is equivalent to NOP (branch is not taken and
there is no delay slot). This commit provides such behavior. Without
this commit, this scenario results in an incorrect behavior.
Signed-off-by: Dragan Mladjenovic <dragan.mladjenovic@syrmia.com>
Signed-off-by: Stefan Pejic <stefan.pejic@syrmia.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220504110403.613168-5-stefan.pejic@syrmia.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
There are currently two problems related to the emulation of the
instruction BPOSGE32C.
The nanoMIPS instruction BPOSGE32C belongs to DSP R3 instructions
(actually, as of now, it is the only instruction of DSP R3). The
presence of DSP R3 instructions in QEMU is indicated by the flag
MIPS_HFLAG_DSP_R3 (0x20000000). This flag is currently being properly
set in CPUMIPSState's hflags (for example, for I7200 nanoMIPS CPU).
However, it is not propagated to DisasContext's hflags, since the flag
MIPS_HFLAG_DSP_R3 is not set in MIPS_HFLAG_TMASK (while similar flags
MIPS_HFLAG_DSP_R2 and MIPS_HFLAG_DSP are set in this mask, and there
is no problem in functioning check_dsp_r2(), check_dsp()). This means
the function check_dsp_r3() currently does not work properly, and the
emulation of BPOSGE32C can not work properly as well.
Change MIPS_HFLAG_TMASK from 0x1F5807FF to 0x3F5807FF (logical OR
with 0x20000000) to fix this.
Additionally, check_cp1_enabled() is currently incorrectly called
while emulating BPOSGE32C. BPOSGE32C is in the same pool (P.BR1) as
FPU branch instruction BC1EQZC and BC1NEZC, but it not a part of FPU
(CP1) instructions, and check_cp1_enabled() should not be involved
while emulating BPOSGE32C.
Rearrange invocations of check_cp1_enabled() within P.BR1 pool
handling to affect only BC1EQZC and BC1NEZC emulation, and not
BPOSGE32C emulation.
Signed-off-by: Dragan Mladjenovic <dragan.mladjenovic@syrmia.com>
Signed-off-by: Stefan Pejic <stefan.pejic@syrmia.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220504110403.613168-4-stefan.pejic@syrmia.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
The field rs in the instruction EXTRV_S.H rt, ac, rs is specified in
nanoMIPS documentation as opcode[20..16]. It is, however, erroneously
considered as opcode[25..21] in the current QEMU implementation. In
function gen_pool32axf_2_nanomips_insn(), the variable v0_t corresponds
to rt/opcode[25..21], and v1_t corresponds to rs/opcode[20..16]), and
v0_t is by mistake passed to the helper gen_helper_extr_s_h().
Use v1_t rather than v0_t in the invocation of gen_helper_extr_s_h()
to fix this.
Signed-off-by: Dragan Mladjenovic <dragan.mladjenovic@syrmia.com>
Signed-off-by: Stefan Pejic <stefan.pejic@syrmia.com>
Fixes: 8b3698b294 ("target/mips: Add emulation of DSP ASE for nanoMIPS")
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220504110403.613168-3-stefan.pejic@syrmia.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
The field ac in nanoMIPS instruction MTHLIP rs, ac is specified in
nanoMIPS documentation as opcode[15..14] (2 bits). However, in the
current QEMU code, the corresponding argument passed to the helper
gen_helper_mthlip() has the value of opcode[15..11] (5 bits). Right
shift the value of this argument by three bits to fix this.
Signed-off-by: Stefan Pejic <stefan.pejic@syrmia.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220504110403.613168-2-stefan.pejic@syrmia.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Richard Henderson