A Linux binary will have the string "S390EP" at address 0x10008,
which is important in getting the guest up off the ground. In the
case of a reboot (specifically chreipl going to a new device),
we should defer to the PSW at address zero for the new config,
which will re-write "S390EP" from the new image.
Let's clear it out at this point so that a reipl to, say, a DASD
passthrough device drives the IPL path from scratch without disrupting
disrupting the order of operations for other boots.
Rather than hardcoding the address of this magic (again), let's
define it somewhere so that the two users are visibly related.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Message-Id: <20201120160117.59366-3-farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
If, for example, we boot off a virtio device and chreipl to a vfio-ccw
device, the space at lowcore will be non-zero. We build a Read IPL CCW
at address zero, but it will have leftover PSW data that will conflict
with the Format-0 CCW being generated:
0x0: 00080000 80010000
------ Ccw0.cda
-- Ccw0.chainData
-- Reserved bits
The data address will be overwritten with the correct value (0x0), but
the apparent data chain bit will cause subsequent memory to be used as
the target of the data store, which may not be where we expect (0x0).
Clear out this space when we boot from DASD, so that we know it exists
exactly as we expect.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@de.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20201120160117.59366-2-farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Commit ae5643ecc6 "hw/display/tcx: Allow 64-bit accesses to framebuffer stippler
and blitter" enabled 64-bit access for the TCX framebuffer stippler and blitter
but missed applying the change to one of the blitter MemoryRegions.
Whilst the original change works for me on my local NetBSD test image, the latest
NetBSD ISO panics on startup without this fix.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Fixes: ae5643ecc6 ("hw/display/tcx: Allow 64-bit accesses to framebuffer stippler and blitter")
Buglink: https://bugs.launchpad.net/bugs/1892540
Message-Id: <20201120081754.18250-1-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
This also brings in two patches that Debian had to include,
qboot_stop_using_inttypes.patch and qboot_no_jump_tables.diff.
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201120152408.164346-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove the "default y" for USB_XHCI_SYSBUS because
sysbus devices are not user creatable; boards that use them will
specify them manually with "imply" or "select" clauses.
It would be nice to keep the ability to remove PCIe and USB from microvm,
since thos can be disabled on the command line and therefore should not
be included if QEMU is configured --without-default-devices. However
it's too late for 5.2 to figure out a place for the DSDT creation code.
Reported-by: Bruce Rogers <brogers@suse.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If expected_args is 0, qtest frees the argument vector and then returns it
nevertheless. Coverity complains; in practice this is not an issue because
expected_args == 0 means that the caller is not interested in the argument
vector, but it would be a potential problem if somebody wanted to add
commands with optional arguments to qtest.
Suggested-by: Kamil Dudka <kdudka@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20201120073149.99079-1-pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
According to the glib function requirements, we need initialise
the variable. Otherwise there will be compilation warnings:
glib-autocleanups.h:28:3: warning: ‘full_name’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
28 | g_free (*pp);
| ^~~~~~~~~~~~
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
Message-Id: <20201118115646.2461726-2-kuhn.chenqun@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The man page does not contain all the chapters from the System Emulation
Users Guide, so some of the links that we've put into the qemu options
descriptions can not be resolved and thus the link names are used in the
man pages instead. These link names currently contain weird "_005f" letters
in the middle and just do not make any sense for the users. To avoid this
situation, replace the link names with more descriptive, natural text.
Message-Id: <20201116145341.91606-1-thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3
Buglink: https://bugs.launchpad.net/qemu/+bug/1453608
Signed-off-by: Thomas Huth <thuth@redhat.com>
QEMU binaries no longer launch successfully with recent SystemTap
releases. This is because modular QEMU builds link the sdt semaphores
into the main binary instead of into the shared objects where they are
used. The symbol visibility of semaphores is 'hidden' and the dynamic
linker prints an error during module loading:
$ ./configure --enable-trace-backends=dtrace --enable-modules ...
...
Failed to open module: /builddir/build/BUILD/qemu-4.2.0/s390x-softmmu/../block-curl.so: undefined symbol: qemu_curl_close_semaphore
The long-term solution is to generate per-module dtrace .o files and
link them into the module instead of the main binary.
In the short term we can define STAP_SDT_V2 so dtrace(1) produces a .o
file with 'default' symbol visibility instead of 'hidden'. This
workaround is small and easier to merge for QEMU 5.2 and downstream
backports.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1898700
Cc: wcohen@redhat.com
Cc: fche@redhat.com
Cc: kraxel@redhat.com
Cc: rjones@redhat.com
Cc: ddepaula@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
Message-id: 20201119141457.844452-1-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The zPCI group and function structures are big endian. However, we do
not consistently store them as big endian locally, and are missing some
conversions.
Let's just store the structures as host endian instead and convert to
big endian when actually handling the instructions retrieving the data.
Also fix the layout of ClpReqQueryPciGrp: g is actually only 8 bit. This
also fixes accesses on little endian hosts, and makes accesses on big
endian hosts consistent.
Fixes: 28dc86a072 ("s390x/pci: use a PCI Group structure")
Fixes: 9670ee7527 ("s390x/pci: use a PCI Function structure")
Fixes: 1e7552ff5c ("s390x/pci: get zPCI function info from host")
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Tested-by: Matthew Rosato <mjrosato@linux.ibm.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20201118104202.1301363-1-cohuck@redhat.com>
Hot-unplugging a vfio-pci device on s390x causes a QEMU crash:
qemu-system-s390x: ../softmmu/memory.c:2772:
do_address_space_destroy: Assertion `QTAILQ_EMPTY(&as->listeners)' failed.
In s390, the IOMMU address space is freed during device unplug but the
associated vfio-pci device may not yet be finalized and therefore may
still have a listener registered to the IOMMU address space.
Commit a2166410ad ("spapr_pci: Unregister listeners before destroying
the IOMMU address space") previously resolved this issue for spapr_pci.
We are now seeing this in s390x; it would seem the possibility for this
issue was already present but based on a bisect commit 2d24a64661
("device-core: use RCU for list of children of a bus") has now changed
the timing such that it is now readily reproducible.
Add logic to ensure listeners are removed before destroying the address
space.
Reported-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1605562955-21152-1-git-send-email-mjrosato@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The Control Program Name Code (CPNC) portion of the diag318
info must be set within the SIE block of each VCPU in the
configuration. The handler will iterate through each VCPU
and dirty the diag318_info reg to be synced with KVM on a
subsequent sync_regs call.
Additionally, the diag318 info resets must be handled via
userspace. As such, QEMU will reset this value for each
VCPU during a modified clear, load normal, and load clear
reset event.
Fixes: fabdada935 ("s390: guest support for diagnose 0x318")
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <20201113221022.257054-1-walling@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Janosch Frank <frankja@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
This fixes a regression that badly breaks some guest setups because
IPIs end up misconfigured in the XIVE interrupt controller. Hopefully,
the last fix for sPAPR. I'm sending this PR with the blessing of David
who is currently on holidays.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEtIKLr5QxQM7yo0kQcdTV5YIvc9YFAl+09tcACgkQcdTV5YIv
c9aW+xAAn0H219o6zfbJSkWnFcqq3vVLGhAva/QoQHzy2oeusbTgo968J4p9zwZb
rS+jRo1uA+U6cuRo+1PPh+iMP+t8ZLlN9AQIqdqtIIeUxpKTGUKUpX7AvZcknpvN
VNvcUsGJGIl/mOjHPXbP29PGi0hWv8+kvESoOOqGfxkv0bY8L1+PItEMK22+n3n2
aaPiWtxsx6UtRoFpyj82bMM/Y5PsKlP0ZvrVChvF8VZZu0kWe8KWKsR7do2/RLAX
tb5J4BN9gWPC2KERsrBWsGn0A4pE5n1NXnERH6BlwEBU/AhUM9d80N6280SSge0k
noE2U1pVAva78NJzAWAiweP1ZGR3yt71MWP2i7ndCxcbFG9IQ7Su48nSmzwKfutT
+SEuoP0fmTSRXmWiKkrOT+9ZdC4+Vpn0IvCGFHzoPTyNlhaOZRIoqhqxTlvrSYwx
/DDwechCwPhidpZ+RYaQudX4yUtZIh+Y33LH879aDxkWW8HcaA98XSXXQ+iOiofu
SY25HisfZjj1xHNuipjoGyMCdPZh4rdspaAGWzJVkOUjjFnzY9PeOxh7bYHz32eN
xFr3f/1woPYHacqQE5lP2aWmyUvWHkvJsEW3yVix1j+luzn1UmXOwRm1P7tGC1o5
gtMgQXR3ZodyLxO20slZjt/G77aFz3bpetWcHxoxaksPua3RZoc=
=zUP3
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/gkurz/tags/ppc-for-5.2-20201118' into staging
ppc patch queue for 2020-11-18
This fixes a regression that badly breaks some guest setups because
IPIs end up misconfigured in the XIVE interrupt controller. Hopefully,
the last fix for sPAPR. I'm sending this PR with the blessing of David
who is currently on holidays.
# gpg: Signature made Wed 18 Nov 2020 10:26:31 GMT
# gpg: using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6
# gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full]
# gpg: aka "Gregory Kurz <gregory.kurz@free.fr>" [full]
# gpg: aka "[jpeg image of size 3330]" [full]
# Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6
* remotes/gkurz/tags/ppc-for-5.2-20201118:
Revert series "spapr/xive: Allocate vCPU IPIs from the vCPU contexts"
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
If the 'identify' property is not set, we'll pass a NULL pointer to
g_str_equal() and crash. Catch the error condition during the creation
of the object.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If the 'service' property is not set, we'll call pam_start() with a NULL
pointer for the service name. This fails and leaves a message like this
in the syslog:
qemu-storage-daemon[294015]: PAM pam_start: invalid argument: service == NULL
Make specifying the property mandatory and catch the error already
during the creation of the object.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When qauthz_list_file_load() rejects JSON values other than JSON
object with a rather confusing error message:
$ echo 1 | qemu-system-x86_64 -nodefaults -S -display none -object authz-list-file,id=authz0,filename=/dev/stdin
qemu-system-x86_64: -object authz-list-file,id=authz0,filename=/dev/stdin: Invalid parameter type for 'obj', expected: dict
Improve to
qemu-system-x86_64: -object authz-list-file,id=authz0,filename=/dev/stdin: File '/dev/stdin' must contain a JSON object
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call.
qauthz_list_file_complete() is wrong that way: it passes @errp to
qauthz_list_file_complete() without checking for failure. If it runs
into another failure, it trips error_setv()'s assertion. Reproducer:
$ qemu-system-x86_64 -nodefaults -S -display none -object authz-list-file,id=authz0,filename=
qemu-system-x86_64: ../util/error.c:59: error_setv: Assertion `*errp == NULL' failed.
Aborted (core dumped)
Fix it to check for failure.
Fixes: 55d869846d
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This series was largely built on the assumption that IPI numbers are
numerically equal to vCPU ids. Even if this happens to be the case
in practice with the default machine settings, this ceases to be true
if VSMT is set to a different value than the number of vCPUs per core.
This causes bogus IPI numbers to be created in KVM from a guest stand
point. This leads to unknow results in the guest, including crashes
or missing vCPUs (see BugLink) and even non-fatal oopses in current
KVM that lacks a check before accessing misconfigured HW (see [1]).
A tentative patch was sent (see [2]) but it seems too complex to be
merged in an RC. Since the original changes are essentially an
optimization, it seems safer to revert them for now. The damage is
done by commit acbdb9956f ("spapr/xive: Allocate IPIs independently
from the other sources") but the previous patches in the series are
really preparatory patches. So this reverts the whole series:
eab0a2d06e ("spapr/xive: Allocate vCPU IPIs from the vCPU contexts")
acbdb9956f ("spapr/xive: Allocate IPIs independently from the other sources")
fa94447a2c ("spapr/xive: Use kvmppc_xive_source_reset() in post_load")
235d3b1162 ("spapr/xive: Modify kvm_cpu_is_enabled() interface")
[1] https://marc.info/?l=kvm-ppc&m=160458409722959&w=4
[2] https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg03626.html
Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Fixes: acbdb9956f ("spapr/xive: Allocate IPIs independently from the other sources")
BugLink: https://bugs.launchpad.net/qemu/+bug/1900241
Signed-off-by: Greg Kurz <groug@kaod.org>
Acked-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <160554086275.1325084.12110142252189044646.stgit@bahia.lan>
Since commits 0979ed017f ("meson: rename .inc.h files to .h.inc")
and 139c1837db ("meson: rename included C source files to .c.inc")
'git-diff --function-context' stopped displaying C function context
correctly.
We can help git-diff by providing attributes to the .[ch].inc path
names. See:
https://git-scm.com/docs/gitattributes#_generating_diff_text
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20201014082209.3712625-1-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The Requested Privilege Level field is 2 bits, the Table Indicator field
is 1 bit and the Index field is the remaining 15 bits, with TI=0 meaning
GDT and TI=1 meaning LDT.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Message-Id: <20201116200414.28286-1-jrtc27@jrtc27.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fixes regression on curses detection in msys2
by commit#925a40df2828d32d3aaaf022282cba81082fb263
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Message-Id: <20201116213106.589-1-luoyonggang@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The QGA MSI target requires several macros which are only available
without --disable-guest-agent-msi.
Don't define that target if configure was called with --disable-guest-agent-msi.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-Id: <20201117201834.408892-1-sw@weilnetz.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix also a similar typo in a code comment.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-Id: <20201117193448.393472-1-sw@weilnetz.de>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
`make installer` with a DLL directory was broken.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-Id: <20201117190640.390359-1-sw@weilnetz.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- quorum: Fix crash with rewrite-corrupted and without read-write user
- io_uring: do not use pointer after free
- file-posix: Use fallback path for -EBUSY from FALLOC_FL_PUNCH_HOLE
- iotests: Fix failure on Python 3.9 due to use of a deprecated function
- char-stdio: Fix QMP default for 'signal'
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAl+zt1URHGt3b2xmQHJl
ZGhhdC5jb20ACgkQfwmycsiPL9ZxyxAAu8GIOeAb7atQvc+KpeBTUG4A+tfAXkC+
iUYdIpFeWWgmGf7myu3nlaAkeTDk6qHalmzkGRHi3yhX4eNIh5Sdff1YwPcZwf+q
GLIqFFTW0z1Bd36N8G7Mkf04nKX4QTHqp6THHtSt9jNs56h5OP3axPXVA/3v9y8B
4ZAkOOvwnwO+U94crhy5y5pX/Vwafv/Dz4DH9hEupE+EI9AuzjZLBrS+sgkxjhmu
gvHpDSqm6NXwWQA5a24J6NzCy3n/Fw/rqmnoOrN8eRz+4DSCMVDnTDDEMFLa/UoK
Ci7AqWfG/MnQ4GrGsOx80KJhAFLTmI60vfnUizKtEjL/HJyK5PDyM+VxHz+P/Tkq
4hqQsHEsll4mAQiKCrrKOOXhn+YC4DhY/5O1EzEfhqfUjI+BFE9iC7LuqQevwKPL
gytup7eoZjIHMtnKwY1B2ApAqHtodswjHkefcjEcvSlhqGi/BvwuWmeYlFXmA3r0
YO8fvbYJrwHwJy7CzMb5Rgs2461QGERmXoCsBxLAiqXU9rhpOZ6gKXIjjlYojZ8M
W0kqbaccTRPuhooFdEQ9RTPSkX7AX2bI0nOoPxfz3YD/siw35YwnUkJqvQbckvJd
vpPkCL5jt3d9sfO0z1xjSH2ey9bevSReYpCsk+kIZl7V2XoDAW0Nbi0Td3pW4j6x
dEkg/+sjF+o=
=0pFF
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Patches for 5.2.0-rc2:
- quorum: Fix crash with rewrite-corrupted and without read-write user
- io_uring: do not use pointer after free
- file-posix: Use fallback path for -EBUSY from FALLOC_FL_PUNCH_HOLE
- iotests: Fix failure on Python 3.9 due to use of a deprecated function
- char-stdio: Fix QMP default for 'signal'
# gpg: Signature made Tue 17 Nov 2020 11:43:17 GMT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* remotes/kevin/tags/for-upstream:
iotests/081: Test rewrite-corrupted without WRITE
iotests/081: Filter image format after testdir
quorum: Require WRITE perm with rewrite-corrupted
io_uring: do not use pointer after free
file-posix: allow -EBUSY errors during write zeros on raw block devices
iotests: Replace deprecated ConfigParser.readfp()
char-stdio: Fix QMP default for 'signal'
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In qobject_type(), NULL is returned when the 'QObject' returned from parse_value() is not of QString type,
and this 'QObject' memory will leaked.
So we need to first cache the 'QObject' returned from parse_value(), and finally
free 'QObject' memory at the end of the function.
Also, we add a testcast about invalid dict key.
The memleak stack is as follows:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0xfffe4b3c34fb in __interceptor_malloc (/lib64/libasan.so.4+0xd34fb)
#1 0xfffe4ae48aa3 in g_malloc (/lib64/libglib-2.0.so.0+0x58aa3)
#2 0xaaab3557d9f7 in qnum_from_int qemu/qobject/qnum.c:25
#3 0xaaab35584d23 in parse_literal qemu/qobject/json-parser.c:511
#4 0xaaab35584d23 in parse_value qemu/qobject/json-parser.c:554
#5 0xaaab35583d77 in parse_pair qemu/qobject/json-parser.c:270
#6 0xaaab355845db in parse_object qemu/qobject/json-parser.c:327
#7 0xaaab355845db in parse_value qemu/qobject/json-parser.c:546
#8 0xaaab35585b1b in json_parser_parse qemu/qobject/json-parser.c:580
#9 0xaaab35583703 in json_message_process_token qemu/qobject/json-streamer.c:92
#10 0xaaab355ddccf in json_lexer_feed_char qemu/qobject/json-lexer.c:313
#11 0xaaab355de0eb in json_lexer_feed qemu/qobject/json-lexer.c:350
#12 0xaaab354aff67 in tcp_chr_read qemu/chardev/char-socket.c:525
#13 0xfffe4ae429db in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x529db)
#14 0xfffe4ae42d8f (/lib64/libglib-2.0.so.0+0x52d8f)
#15 0xfffe4ae430df in g_main_loop_run (/lib64/libglib-2.0.so.0+0x530df)
#16 0xaaab34d70bff in iothread_run qemu/iothread.c:82
#17 0xaaab3559d71b in qemu_thread_start qemu/util/qemu-thread-posix.c:519
Fixes: 532fb53284 ("qapi: Make more of qobject_to()")
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Alex Chen <alex.chen@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201113145525.85151-1-alex.chen@huawei.com>
[Commit message tweaked]
With iproute2-5.8.0, the route, link and addr show commands fail:
root@sid:~# ip addr show
RTNETLINK answers: Unknown error 352321537
Dump terminated
root@sid:~# ip link show
RTNETLINK answers: Unknown error 352321537
Dump terminated
root@sid:~# ip route show
RTNETLINK answers: Unknown error 352321537
Dump terminated
This patch correctly decodes the GETROUTE and GETLINK commands and adds
the RTA_TABLE message.
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20201116163622.791442-1-laurent@vivier.eu>
* Update NetBSD VM to version 9.1
* Misc fixes (e.g. categorize some devices)
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAl+zld8RHHRodXRoQHJl
ZGhhdC5jb20ACgkQLtnXdP5wLbWb8Q/+IRvGUGjGcPfbTvwoOqJVy4Hm7huW5i1s
wHe/6nitNtpvaAqcxbQHBIvWX9xTzppWcFiEkIs8rPwLOUFKh5xJ+NbEdf4acQaJ
m4G2mEY5bYt/o5e6p7ZK1RgS2EjD1eQ6BwMWQKeUHET7MTv0UabKtvWmBWpMqFxA
vl/3SbVWsSwGB9gOA5oksYhKY5ZRcVaDxsGk89f7iwgaStcxWNxVFEXddbBmqhfW
Q4ZPt0K7yod7NDBOaGEoc2hOjIfr0TvovHojDuAxt+2tKdYi1vwtnwKbFqTWp7Ca
7ttzoQUSsteiOjAhHRpa2PEbfrNs+loIm9fem5fQ9i7POlbS/Ozv2RnPCZm1X8pW
n7Jvsh25V066AFnHat7PnjcBVBRFfmR3xtA61PqvAMGEKW8tortbZbpqXO18Pv5p
6P/GG9G3QE0v2rEsU5BNFWp/aD7fiWy/VPu3dGFUkI9/S3biatocldHn/9eyXz94
k75Xzhe5x6n5Jf8QYFQ/6BO0qSoidNbAVg1W8+QyRXIJJhWRnvW9eYa7tSx5ezJg
5+oCo4oh6Qd9nvrl5pIwvX6QMDf2kPxzp7PsHeemqt7+QNmXErAVsIi1HUVsLWRP
Qb/BbKyKNeWJwvWWLAm/2kXVmNQfjLVNCwg04xa8tkQemhIDekVrCpMoX3cNHjWf
EWa1vEtbq9k=
=A3/B
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-11-17' into staging
* Fixes for compiling on Haiku, and add Haiku VM for compile-testing
* Update NetBSD VM to version 9.1
* Misc fixes (e.g. categorize some devices)
# gpg: Signature made Tue 17 Nov 2020 09:20:31 GMT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* remotes/huth-gitlab/tags/pull-request-2020-11-17:
max111x: put it into the 'misc' category
nand: put it into the 'storage' category
ads7846: put it into the 'input' category
ssd0323: put it into the 'display' category
gitlab-ci: Use $CI_REGISTRY instead of hard-coding registry.gitlab.com
target/microblaze: Fix possible array out of bounds in mmu_write()
tests/vm: update NetBSD to 9.1
tests/vm: Add Haiku test based on their vagrant images
configure: Add a proper check for sys/ioccom.h and use it in tpm_ioctl.h
configure: Do not build pc-bios/optionrom on Haiku
configure: Fix the _BSD_SOURCE define for the Haiku build
qemu/bswap: Remove unused qemu_bswap_len()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The TMP105 datasheet says that in Interrupt Mode (when TM==1) the device
signals an alert when the temperature equals or exceeds the T_high value and
then remains high until a device register is read or the device responds to
the SMBUS Alert Response address, or the device is put into Shutdown Mode.
Thereafter the Alert pin will only be re-signalled when temperature falls
below T_low; alert can then be cleared in the same set of ways, and the
device returns to its initial "alert when temperature goes above T_high"
mode. (If this textual description is confusing, see figure 3 in the
TI datasheet at https://www.ti.com/lit/gpn/tmp105 .)
We were misimplementing this as a simple "always alert if temperature is
above T_high or below T_low" condition, which gives a spurious alert on
startup if using the "T_high = 80 degrees C, T_low = 75 degrees C" reset
limit values.
Implement the correct (hysteresis) behaviour by tracking whether we
are currently looking for the temperature to rise over T_high or
for it to fall below T_low. Our implementation of the comparator
mode (TM==0) wasn't wrong, but rephrase it to match the way that
interrupt mode is now handled for clarity.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20201110150023.25533-3-peter.maydell@linaro.org
The TMP105 datasheet (https://www.ti.com/lit/gpn/tmp105) says that the
power-up reset values for the T_low and T_high registers are 80 degrees C
and 75 degrees C, which are 0x500 and 0x4B0 hex according to table 5. These
values are then shifted right by four bits to give the register reset
values, since both registers store the 12 bits of temperature data in bits
[15..4] of a 16 bit register.
We were resetting these registers to zero, which is problematic for Linux
guests which enable the alert interrupt and then immediately take an
unexpected overtemperature alert because the current temperature is above
freezing...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20201110150023.25533-2-peter.maydell@linaro.org
In commit 76346b6264 we tried to add a configure check that
the libgio pkg-config data was correct, which builds an executable
linked against it. Unfortunately this doesn't catch the problem
(missing static library dependency info), because a "do nothing" test
source file doesn't have any symbol references that cause the linker
to pull in .o files from libgio.a, and so we don't see the "missing
symbols from libmount" error that a full QEMU link triggers.
(The ineffective test went unnoticed because of a typo that
effectively disabled libgio unconditionally, but after commit
3569a5dfc1 fixed that, a static link of the system emulator on
Ubuntu stopped working again.)
Improve the gio test by having the test source fragment reference a
g_dbus function (which is what is indirectly causing us to end up
wanting functions from libmount).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20201116104617.18333-1-peter.maydell@linaro.org
Fix Coverity CID 1435957: Memory - illegal accesses (OVERRUN):
>>> Overrunning array "suffixes" of 7 8-byte elements at element
index 7 (byte offset 63) using index "idx" (which evaluates to 7).
Note, the biggest input value freq_to_str() can accept is UINT64_MAX,
which is ~18.446 EHz, less than 1000 EHz.
Reported-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Luc Michel <luc@lmichel.fr>
Message-id: 20201101215755.2021421-1-f4bug@amsat.org
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch fixes CID 1432800 by removing an unnecessary check.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In the mtspr helper we attempt to check for "is the timer disabled"
with "if (env->ttmr & TIMER_NONE)". This is wrong because TIMER_NONE
is zero and the condition is always false (Coverity complains about
the dead code.)
The correct check would be to test whether the TTMR_M field in the
register is equal to TIMER_NONE instead. However, the
cpu_openrisc_timer_update() function checks whether the timer is
enabled (it looks at cpu->env.is_counting, which is set to 0 via
cpu_openrisc_count_stop() when the TTMR_M field is set to
TIMER_NONE), so there's no need to check for "timer disabled" in the
target/openrisc code. Instead, simply remove the dead code.
Fixes: Coverity CID 1005812
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Stafford Horne <shorne@gmail.com>
Message-id: 20201103114654.18540-1-peter.maydell@linaro.org
