These functions are not used outside helper.c
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190322162333.17159-4-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
cortex-a7 and cortex-a15 have pmus (PMUv2) and they advertise
them in ID_DFR0. Let's allow them to function. This also enables
the pmu cpu property to work with these cpu types, i.e. we can
now do '-cpu cortex-a15,pmu=off' to remove the pmu.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190322162333.17159-3-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Fix a QEMU NULL derefence that occurs when the guest attempts to
enable PMU counters with a non-v8 cpu model or a v8 cpu model
which has not configured a PMU.
Fixes: 4e7beb0cc0 ("target/arm: Add a timer to predict PMU counter overflow")
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190322162333.17159-2-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In the kconfig shuffle arm lost pci-testdev which is used by
kvm-unit-tests. Let's add it back.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20190322163059.9716-1-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Some drivers do I2C bitbanging by keeping the output to 0 and flipping
the GPIO direction between input and output (see for example in Linux
gpio_set_open_drain_value_commit, in drivers/gpio/gpiolib.c).
When the GPIO is set to input, the pull-up resistor brings the output
to 1, while when the GPIO is set to output, the output driver brings
the output to 0.
Implement this for the nRF51 GPIO device model. First, if both input and
output are floating, and there is a pull-up or pull-down resistor
configured, do not just set s->in, but also make any devices listening
on the output qemu_irq receive that value. Second, if the pin is
driven both internally (output pin) and externally you don't get a
short circuit if both sides drive the pin to the same value.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20190317141001.3346-1-pbonzini@redhat.com
[PMM: wrapped long line]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The second word has been loaded from the unincremented
address since the first commit.
Fixes: 44ac14b06f
Reported-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190322234302.12770-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
- more splitting of Travis matric to avoid timeouts
- Fused Multiply-Add fixes for MIPS and hardfloat
- cleanups to docker travis emulation
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAlyYsRwACgkQ+9DbCVqe
KkR1AQf/bPdeZti25BfqdJBZKhuxa0KFjwq0bp5FB5twyJYhvMXAEqr/nwhYI3oE
6oe2540TF5153lJVGrvmEQ7HzdPiAznAAEF9QzKU78tm46HSE0ohBDm1T4JP4GI6
F01+XQrDUgItjdjF+VodJDDadf2Ez25//jNo9k49oLnXYX6oSastNndQZML02nIp
TkRW+XbgxBiJh3stP8Z0fawqsYuShAqekr1tuCYCs0+V+jZpiQDPHq7r11LdEmig
HuADMXrgEzp27l2Zmji5vcqrIM1qcymzjV69DezfaV5F5/gJ3XslVmrPE2D+CwwT
MEmeLGV4LCowvdeuIzpGdlGHDDSJyw==
=XHYI
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-and-fpu-fixes-250319-1' into staging
Mix of testing & fpu fixes
- more splitting of Travis matric to avoid timeouts
- Fused Multiply-Add fixes for MIPS and hardfloat
- cleanups to docker travis emulation
# gpg: Signature made Mon 25 Mar 2019 10:44:44 GMT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* remotes/stsquad/tags/pull-testing-and-fpu-fixes-250319-1:
docker: trivial changes to `make docker` help
docker: Fix travis script unable to find source dir
docker: Fix travis.py parser and misc change
hardfloat: fix float32/64 fused multiply-add
target/mips: Fix minor bug in FPU
.travis.yml: reduce number of targets built while disabling things
.travis.yml: --disable-user for --without-default-devices
.travis.yml: split some more system builds
configure: add --target-list-exclude
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The script generated from QEMU_SRC/.travis.yml uses BUILD_DIR and
SRC_DIR path relative to the current dir, unless these variables
are exported in environment.
Since commit 05790dafef BUILD_DIR is exported in the runner script,
although SRC_DIR is not, so that make docker-travis fails becase
the reference to source dir is wrong. So let's unset both BUILD_DIR
and SRC_DIR before calling the script, given it is executed from
the source dir already (as in Travis).
Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <20190320221207.11366-3-wainersm@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Fixed the travis.py script that has failed to parse the current
QEMU_SRC/.travis.yml file. It no longer makes combinations from
env/matrix, instead it uses explicit includes. Also the compiler
can be omitted from matrix/include, so that Travis chooses the
first entry of the global compiler list.
Replaced yaml.load() with yaml.safe_load() so that quieting the
following deprecation warning:
https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation
Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <20190320221207.11366-2-wainersm@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Before falling back to softfloat FMA, we do not restore the original
values of inputs A and C. Fix it.
This bug was caught by running gcc's testsuite on RISC-V qemu.
Note that this change gives a small perf increase for fp-bench:
Host: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Command: perf stat -r 3 taskset -c 0 ./fp-bench -o mulAdd -p $prec
- $prec = single:
- before:
101.71 MFlops
102.18 MFlops
100.96 MFlops
- after:
103.63 MFlops
103.05 MFlops
102.96 MFlops
- $prec = double:
- before:
173.10 MFlops
173.93 MFlops
172.11 MFlops
- after:
178.49 MFlops
178.88 MFlops
178.66 MFlops
Signed-off-by: Kito Cheng <kito.cheng@gmail.com>
Signed-off-by: Emilio G. Cota <cota@braap.org>
Message-Id: <20190322204320.17777-1-cota@braap.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Wrong type of NaN was generated for IEEE 754-2008 by MADDF.<D|S> and
MSUBF.<D|S> instructions when the arguments were (Inf, Zero, NaN) or
(Zero, Inf, NaN).
The if-else statement establishes if the system conforms to IEEE
754-1985 or IEEE 754-2008, and defines different behaviors depending
on that. In case of IEEE 754-2008, in mentioned cases of inputs,
<MADDF|MSUBF>.<D|S> returns the input value 'c' [2] (page 53) and
raises floating point exception 'Invalid Operation' [1] (pages 349,
350).
These scenarios were tested and the results in QEMU emulation match
the results obtained on the machine that has a MIPS64R6 CPU.
[1] MIPS Architecture for Programmers Volume II-a: The MIPS64
Instruction Set Reference Manual, Revision 6.06
[2] MIPS Architecture for Programmers Volume IV-j: The MIPS64
SIMD Architecture Module, Revision 1.12
Signed-off-by: Mateja Marjanovic <mateja.marjanovic@rt-rk.com>
Message-Id: <1553008916-15274-2-git-send-email-mateja.marjanovic@rt-rk.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[AJB: fixed up commit message]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
This build keeps timing out on Travis and it's unlikely including the
additional guest front-ends will catch any failures in the fallback
code.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
This is essentially a softmmu tweak so don't bother building
linux-user builds as well.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
We define a new class of targets (MAIN_SOFTMMU_TARGETS) to cover the
major architectures. We either just build those or use the new
target-list-exclude mechanism to remove them from the list. This will
hopefully stop some of the longer builds hitting the Travis timeout
limit.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
This is an inverse selection which excludes a selected set of targets
from the default target list. It will mostly be useful for CI
configurations but it might be useful for some users as well.
You cannot specify --target-list and --target-list-exclude at the same
time.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJclTSiAAoJENro4Ql1lpzl4pIP/AstfTZ/IgII3LapdB+cVB1A
MvlX2JLRl6OYYVOQNsM83oiOeVZQYAsKoV/HTViDEzsDWInFTGojr4Y8EPU8oLav
8ssyGT7BPpVgF52ka99RLIsTnWptG+CWGNTX3Y3Ycb8WmmEUWhsabgL7Akv0OMw4
fLH4qwFeHYhBsXaPwWouerVEYJgz2sq6RglUC2DMLBHWPPnmTmf8Qit47qJEhycc
ykTa1tqBj7FVPv8bj4tlLjzGwQhjZag/j+hPHiwrbREqF2k3C+KUOl5Bj8AOj6UQ
XLN5lJDTEisGVJOtGb6XlTs3f+QF9sF5YPW7gjam0GpmK2kSUsuAuepcr5NsnUWq
skvMxRhwmOXHXGfWUS1/fSfPnKDnaZDLbGpl29FVLEh3onzbUFqYd0v3Fy1XXAWQ
5r0USRj4xquCmQ7XJkkW3n+uElLQjC5GkhKvz/fzrDlM0YxTS5xV9Cgj+B0+Wiyc
x7MRGWe7IBEVLC8NT6EpnZJ4HnmJi4B6J5a6pcPL353yj32BsZA8wwh81fjvSKD4
5OQL0YOzrlgMRF03eh2VcJEMkPdBtbXJDpRBPHVTXcuXNviACaONcCgg3KnXXQ7J
57V9whkfjxWCvNeOMOfNFtksvCT0UrCZhRw6Dz/Q6Rg/PJlRaMSyyOyB0VcmRHMa
kumTDRG28lN8J/KzbQvm
=TUq6
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/elmarco/tags/slirp-pull-request' into staging
slirp: clarify license of slirp as BSD-3
# gpg: Signature made Fri 22 Mar 2019 19:16:50 GMT
# gpg: using RSA key DAE8E10975969CE5
# gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full]
# gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full]
# Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5
* remotes/elmarco/tags/slirp-pull-request:
slirp: is not maintained by Kelly Price for a long time
slirp: remove reference to COPYRIGHT file
slirp: clarify license of slirp files using SPDX: implicit via unstated
slirp: clarify license of slirp files using SPDX: implicit via COPYRIGHT
slirp: clarify license of slirp files using SPDX: explicit MIT
slirp: clarify license of slirp files using SPDX: explicit BSD
slirp: relicense GPL files to BSD-3
slirp: update COPYRIGHT to use full 3-Clause BSD License
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Drop test_fail: we know that exit simcall works. Now that it's not run
automatically there's no point in keeping it.
Drop test_pipeline: we're not modeling pipeline, we don't control ccount
and there's no plan to do so.
Enable test_boolean: it won't break on cores without boolean option, it
will do testing on cores with boolean option.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Don't announce that exit simcall has been invoked: this is just noise.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
slirp has been maintained by the QEMU maintainers and will be
maintained under an independent project soon.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kelly Price <strredwolf@gmail.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The slirp COPYRIGHT file is a BSD-3 license. Instead of referring to
another project file, the SPDX license notice present in all source
files states that unequivocally.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Add SPDX license identifier to clarify the license of files without
explicit license header.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Add SPDX license identifier to clarify the license of files with
reference to BSD license from slirp COPYRIGHT file.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Add SPDX license identifier to clarify the license of files with
explicit MIT license header.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Add SPDX license identifier to clarify the license of files with
explicit 3-clause BSD license header.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
In order to make slirp a standalone project, the project must have a
clear license, and be compatible with the GPL or LGPL.
Since commit 2f5f899631 ("Remove the
advertising clause from the slirp license"), slirp is BSD-3. But new
files have been added under slirp/ with QEMU GPL license since then.
The copyright holders have been asked to relicense files to BSD-3 and
gave their permission:
- slirp/dhcpv6.{c,h}
Subject: Re: Clearing slirp/ license
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>, QEMU <qemu-devel@nongnu.org>, Thomas Huth <thuth@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <CAJ+F1CKBRNdLPb_wOLhURdUJd-j1RHY2toKSTEhCBt_zs4Xk1w@mail.gmail.com>
From: "Cédric Le Goater" <clg@kaod.org>
Message-ID: <e942cdab-fe1b-fdf4-3b9f-da16a4afa953@kaod.org>
Date: Mon, 11 Mar 2019 16:23:25 +0100
> Could you reply that you have no objection in relicensing those files
> are 3-Clause BSD?
Fine for me. You can change the license of slirp/ncsi.c and
slirp/ncsi-pkt.hto a 3-Clause BSD.
Thanks,
C.
Subject: Re: [Qemu-devel] Clearing slirp/ license
To: Peter Maydell <peter.maydell@linaro.org>, Shan Gavin <shan.gavin@gmail.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, "Marc-André Lureau" <marcandre.lureau@gmail.com>, Gavin Shan <gwshan@linux.vnet.ibm.com>, Thomas Huth <thuth@redhat.com>, QEMU <qemu-devel@nongnu.org>, Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <CAJ+F1CKBRNdLPb_wOLhURdUJd-j1RHY2toKSTEhCBt_zs4Xk1w@mail.gmail.com> <e942cdab-fe1b-fdf4-3b9f-da16a4afa953@kaod.org> <CAJ+F1C+hFfsa5gcSdttTP5J+uyDvNdYJWrm9OJM26+Zc1ZQkew@mail.gmail.com> <cc62e1fd-c564-e1b7-d10c-30665b481352@ozlabs.ru> <CAOL5TwkQXhPjdPP9v7n7mxAVxbDCSo6MEaG+E-Xys=MoD_pg2g@mail.gmail.com> <CAFEAcA_g=L2LSo=B_5dpJhJJrqFiOb6sswMVohQwpVGiKi_A7w@mail.gmail.com>
From: "Cédric Le Goater" <clg@kaod.org>
Message-ID: <4ddf6031-0df1-b3b5-965e-a181266e42b0@kaod.org>
Date: Tue, 12 Mar 2019 11:49:21 +0100
> Is the code in question copyright you personally, or copyright
> IBM as your employer at the time ? If the latter, it is IBM that
> would need to approve the relicensing.
That was done. I had our legal team approve the change of license.
Thanks,
C.
From: Shan Gavin <shan.gavin@gmail.com>
Date: Tue, 12 Mar 2019 15:04:54 +0800
Message-ID: <CAOL5TwkQXhPjdPP9v7n7mxAVxbDCSo6MEaG+E-Xys=MoD_pg2g@mail.gmail.com>
Subject: Re: [Qemu-devel] Clearing slirp/ license
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>, "Cédric Le Goater" <clg@kaod.org>, gwshan@linux.vnet.ibm.com, Peter Maydell <peter.maydell@linaro.org>, Thomas Huth <thuth@redhat.com>, QEMU <qemu-devel@nongnu.org>, Samuel Thibault <samuel.thibault@ens-lyon.org>
> Gavin, could you reply that you have no objection in relicensing
> ncsi-pkt.h as 3-Clause BSD?
No objection. Please go ahead with the relicensing.
Cheers,
Gavin
- ncsi.c, ncsi-pkt.h
Subject: Re: Clearing slirp/ license
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>, QEMU <qemu-devel@nongnu.org>, "Cédric Le Goater" <clg@kaod.org>
Cc: Peter Maydell <peter.maydell@linaro.org>, Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <CAJ+F1CKBRNdLPb_wOLhURdUJd-j1RHY2toKSTEhCBt_zs4Xk1w@mail.gmail.com>
From: Thomas Huth <thuth@redhat.com>
Message-ID: <ed5a9f55-f2e5-298d-58ac-414759e9b491@redhat.com>
Date: Wed, 13 Feb 2019 12:30:32 +0100
> Could you reply that you have no objection in relicensing those files
> are 3-Clause BSD?
Ok, for the records: I'm fine if you change the license of dhcpv6.[ch]
to either 3-Clause BSD or 2-Clause BSD.
Thomas
- vmstate.{c,h}
From: Juan Quintela <quintela@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: QEMU <qemu-devel@nongnu.org>, Peter Maydell <peter.maydell@linaro.org>, Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: Clearing slirp/ license
Date: Tue, 12 Mar 2019 12:43:17 +0100
Message-ID: <87k1h4qpwq.fsf@trasno.org>
> Juan, Could you reply that you have no objection in relicensing the
> vmstate files as 3-Clause BSD?
No problem at all on my side.
Later, Juan.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[ for the NC-SI files ]
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Thomas Huth <thuth@redhat.com>
According to commit 2f5f899631 ("Remove
the advertising clause from the slirp license"), Danny Gasparovski
gave permission to license slirp code under 3-clause BSD license:
Subject: RE: Slirp license
Date: Thu, 8 Jan 2009 10:51:00 +1100
From: "Gasparovski, Daniel" <Daniel.Gasparovski@ato.gov.au>
To: "Richard Fontana" <rfontana@redhat.com>
I have no objection to having Slirp code in QEMU be licensed under
the 3-clause BSD license.
slirp/COPYRIGHT's initial version in 2004 (commit 5fafdf24) listed
only 3 clauses BUT used the poisonous advertising clause for clause 3
which is the controversial clause of non-free 4-clause (that is, it
appears that the BSD-4 license was copied, and then the WRONG clause
was deleted, when creating COPYRIGHT. Perhaps explained as an easy
mistake to make since 3-clause was created by removing clause 3 of the
4-clause, where you sometimes see the three-clause version with
clauses 1, 2, 4; but more commonly see a renumbered version with
clauses 1, 2, 3 to close the gap. If you pay attention only to clause
numbers instead of content, it can be easy to confuse which clause to
delete to go from 4-clause to 3-clause).
Commit 2f5f89963 removed the poisonous wrong clause on
the grounds of moving from 4-clause to 3-clause; but did not add the
missing clause, which makes it LOOK like the 2-clause version. But I
think we have a decent enough trail showing the intent for 3-clause.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Some trace points are attributed to the wrong source file. Happens
when we neglect to update trace-events for code motion, or add events
in the wrong place, or misspell the file name.
Clean up with help of cleanup-trace-events.pl. Same funnies as in the
previous commit, of course. Manually shorten its change to
linux-user/trace-events to */signal.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20190314180929.27722-6-armbru@redhat.com
Message-Id: <20190314180929.27722-6-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tracked down with cleanup-trace-events.pl. Funnies requiring manual
post-processing:
* block.c and blockdev.c trace points are in block/trace-events.
* hw/block/nvme.c uses the preprocessor to hide its trace point use
from cleanup-trace-events.pl.
* include/hw/xen/xen_common.h trace points are in hw/xen/trace-events.
* net/colo-compare and net/filter-rewriter.c use pseudo trace points
colo_compare_udp_miscompare and colo_filter_rewriter_debug to guard
debug code.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20190314180929.27722-5-armbru@redhat.com
Message-Id: <20190314180929.27722-5-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Emit comments with shortened file names (previous commit).
Limit search to the input file's directory.
Cope with properties tcg (commit b2b36c22bd) and vcpu (commit
3d211d9f4d).
Cope with capital letters in function names.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20190314180929.27722-4-armbru@redhat.com
Message-Id: <20190314180929.27722-4-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
We spell out sub/dir/ in sub/dir/trace-events' comments pointing to
source files. That's because when trace-events got split up, the
comments were moved verbatim.
Delete the sub/dir/ part from these comments. Gets rid of several
misspellings.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190314180929.27722-3-armbru@redhat.com
Message-Id: <20190314180929.27722-3-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Almost all trace-events point to docs/devel/tracing.txt in a comment
right at the beginning. Touch up the ones that don't.
[Updated with Markus' new commit description wording.
--Stefan]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190314180929.27722-2-armbru@redhat.com
Message-Id: <20190314180929.27722-2-armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}". SystemTap's
dtrace(1) tool prints a warning when processing this input file.
This patch avoids the error by emitting an empty file instead of
"provider qemu {}" when there are no enabled trace events.
Fixes: 23c3d569f4 ("target/hppa: add TLB trace events")
Reported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 20190321170831.6539-3-stefanha@redhat.com
Message-Id: <20190321170831.6539-3-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
This is a system misconfiguration and the user must resolve it so that
applications can perform path-based system calls successfully.
This issue does not occur on real-world systems since tracefs is mounted
on /sys/kernel/debug/tracing/, but the compiler is smart enough to
foresee the possibility and warn about the unchecked snprintf(3) return
value. This patch fixes the compiler warning.
Reported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 20190321170831.6539-2-stefanha@redhat.com
Message-Id: <20190321170831.6539-2-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
A few fixes that missed -rc0:
* CPU model documentation updates (Daniel P. Berrangé)
* Fix bogus OSPKE warnings (Eduardo Habkost)
* Work around KVM bugs when handing arch_capabilities
(Eduardo Habkost)
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJck+ayAAoJECgHk2+YTcWmS6cP/iLbes+eRzkXaTMvRrSvE4h6
xGi55cLUlVQqzklPYimewn7qneCEe+R5gr4g9ajL7MPT9hBYmmcSoe5M3ElaPNHj
yWncdNDZR+C/U3egAN4uw6v3pHc0u7hi7cC578aj6RcgP5tKxsxW4dGZDaW2tKKw
p01xDPM6+FcrGdlNosE3GYHHB7EC35wdORHPYVjvCjEaXEOwCxndGjZurgzMPANd
IR90ag1ZRx9yNDqM9O4Im+nn7MrXuhhQZiwhMlFDP6wIkmxuigxv5RXRx/j77HMg
jVXmVTlh4EKP0arGO1LXywYSe2yZIuYChGHnInwkcFHJhduWt4Sq8VZlrvsAmO4u
+Eb5Vlfc4nNYN9BN43LENe3V4IhakTVSKZnb+zD6ML14oI0NyItRZTVXtDqjHsB3
RJAgQTgwm05dddeFiFpVe4L//A9kbjenFxutTvOf3N3Qj6tnug6kOBChwyLjl/dV
CaPYo+jTRX6KyIpXnVyo9CGgSUjFjSHzSx5C/clIYLZkMFtl8WOKEPPrommgD1WP
wTE80mt2avPcdXlX41MvTrKIALKbFI96CBYm8rL7uU4okYmssAKNMPuj2a9oPtKB
OuqeXCjVrKKdpk9dmVAjbAUh16xReeB1BJ1y0tv2efx/P/jlhkFSg8g3kIVPSpX8
o1FBZggBdRwjfagVKXoo
=Wg+0
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' into staging
x86 queue for -rc1
A few fixes that missed -rc0:
* CPU model documentation updates (Daniel P. Berrangé)
* Fix bogus OSPKE warnings (Eduardo Habkost)
* Work around KVM bugs when handing arch_capabilities
(Eduardo Habkost)
# gpg: Signature made Thu 21 Mar 2019 19:32:02 GMT
# gpg: using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/x86-next-pull-request:
docs: add note about stibp CPU feature for spectre v2
docs: clarify that spec-ctrl is only needed for Spectre v2
i386: Disable OSPKE on CPU model definitions
i386: Make arch_capabilities migratable
i386: kvm: Disable arch_capabilities if MSR can't be set
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
While running the GCC test suite against 4.0.0-rc0, Kito found a
regression introduced by the decodetree conversion that caused divuw and
remuw to sign-extend their inputs. The ISA manual says they are
supposed to be zero extended:
DIVW and DIVUW instructions are only valid for RV64, and divide the
lower 32 bits of rs1 by the lower 32 bits of rs2, treating them as
signed and unsigned integers respectively, placing the 32-bit
quotient in rd, sign-extended to 64 bits. REMW and REMUW
instructions are only valid for RV64, and provide the corresponding
signed and unsigned remainder operations respectively. Both REMW
and REMUW always sign-extend the 32-bit result to 64 bits, including
on a divide by zero.
Here's Kito's reduced test case from the GCC test suite
unsigned calc_mp(unsigned mod)
{
unsigned a,b,c;
c=-1;
a=c/mod;
b=0-a*mod;
if (b > mod) { a += 1; b-=mod; }
return b;
}
int main(int argc, char *argv[])
{
unsigned x = 1234;
unsigned y = calc_mp(x);
if ((sizeof (y) == 4 && y != 680)
|| (sizeof (y) == 2 && y != 134))
abort ();
exit (0);
}
I haven't done any other testing on this, but it does fix the test case.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
break_dependency incorrectly handles the case of dependency on an opcode
that references the same register multiple times. E.g. the following
instruction is translated incorrectly:
{ or a2, a3, a3 ; or a3, a2, a2 }
This happens because resource indices of both dependency graph nodes are
incremented, and a copy for the second instance of the same register in
the ending node is not done.
Only increment resource index of the ending node of the dependency.
Add test.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
When virtio-vga was added, the intention was to only support it for
those machines where the firmware does not know about virtio-gpu,
and supported VGA legacy hardware before virtio-{gpu,vga} were
introduced.
The Kconfig switch however enabled virtio-vga for all machines with
a PCI bus, and libvirt then prefers it even on hardware where
virtio-gpu would be preferrable. At least for now, only enable
virtio-vga for PC, hppa and pSeries machines, as was the case
before Kconfig dependencies were introduced.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Build fails with gcc 9:
crypto/block-luks.c:689:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
689 | be32_to_cpus(&luks->header.payload_offset);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
crypto/block-luks.c:690:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
690 | be32_to_cpus(&luks->header.key_bytes);
| ^~~~~~~~~~~~~~~~~~~~~~~
crypto/block-luks.c:691:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
691 | be32_to_cpus(&luks->header.master_key_iterations);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... a bunch of similar errors...
crypto/block-luks.c:1288:22: error: taking address of packed member of ‘struct QCryptoBlockLUKSKeySlot’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
1288 | be32_to_cpus(&luks->header.key_slots[i].stripes);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
All members of the QCryptoBlockLUKSKeySlot and QCryptoBlockLUKSHeader are
naturally aligned and we already check at build time there isn't any
unwanted padding. Drop the QEMU_PACKED attribute.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
TYPE_QAUTHZ is an abstract object of type TYPE_OBJECT. All other
are children of TYPE_QAUTHZ, thus also objects.
Keep INTERFACE_CHECK() for interfaces, and use OBJECT_CHECK() on
objects.
Reported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We were never reporting the G_IO_HUP event when an end of file was hit
on the websocket channel.
We also didn't report G_IO_ERR when we hit a fatal error processing the
websocket protocol.
The latter in particular meant that the chardev code would not notice
when an eof/error was encountered on the websocket channel, unless the
guest OS happened to trigger a write operation.
This meant that once the first client had quit, the chardev would never
listen to accept a new client.
Fixes launchpad bug 1816819
Acked-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
While the stibp CPU feature is not commonly used by guest OS for spectre
mitigation due to its performance impact, it is none the less best
practice to expose it to all guest OS. This allows the guest OS to
decide whether to make use or it.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190307121838.6345-3-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The docs currently say that the spec-ctrl feature is needed for both
Spectre variants, but it is only used to address Spectre v2. Also
remove the note about retpolines. The guest OS is usually treated
as a blackbox from host mgmt pov, so it won't have knowledge about
use of retpolines and thus should unconditionally expose spec-ctrl,
allowing the guest to decide whether to use it or not.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190307121838.6345-2-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Currently, the Cascadelake-Server, Icelake-Client, and
Icelake-Server are always generating the following warning:
qemu-system-x86_64: warning: \
host doesn't support requested feature: CPUID.07H:ECX [bit 4]
This happens because OSPKE was never returned by
GET_SUPPORTED_CPUID or x86_cpu_get_supported_feature_word().
OSPKE is a runtime flag automatically set by the KVM module or by
TCG code, was always cleared by x86_cpu_filter_features(), and
was not supposed to appear on the CPU model table.
Remove the OSPKE flag from the CPU model table entries, to avoid
the bogus warning and avoid returning invalid feature data on
query-cpu-* QMP commands. As OSPKE was always cleared by
x86_cpu_filter_features(), this won't have any guest-visible
impact.
Include a test case that should detect the problem if we introduce
a similar bug again.
Fixes: c7a88b52f6 ("i386: Add new model of Cascadelake-Server")
Fixes: 8a11c62da9 ("i386: Add new CPU model Icelake-{Server,Client}")
Cc: Tao Xu <tao3.xu@intel.com>
Cc: Robert Hoo <robert.hu@linux.intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190319200515.14999-1-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Now that kvm_arch_get_supported_cpuid() will only return
arch_capabilities if QEMU is able to initialize the MSR properly,
we know that the feature is safely migratable.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190125220606.4864-3-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
KVM has two bugs in the handling of MSR_IA32_ARCH_CAPABILITIES:
1) Linux commit commit 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES
is always supported") makes GET_SUPPORTED_CPUID return
arch_capabilities even if running on SVM. This makes "-cpu
host,migratable=off" incorrectly expose arch_capabilities on CPUID on
AMD hosts (where the MSR is not emulated by KVM).
2) KVM_GET_MSR_INDEX_LIST does not return MSR_IA32_ARCH_CAPABILITIES if
the MSR is not supported by the host CPU. This makes QEMU not
initialize the MSR properly at kvm_put_msrs() on those hosts.
Work around both bugs on the QEMU side, by checking if the MSR
was returned by KVM_GET_MSR_INDEX_LIST before returning the
feature flag on kvm_arch_get_supported_cpuid().
This has the unfortunate side effect of making arch_capabilities
unavailable on hosts without hardware support for the MSR until bug #2
is fixed on KVM, but I can't see another way to work around bug #1
without that side effect.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190125220606.4864-2-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
