Version: GnuPG v1
iQEcBAABAgAGBQJcncmSAAoJEO8Ells5jWIRh8YH/2EXWKEBlN1TSWZQrL3ifq+4
OS1335yGK34uQrZEvhgpGlHDuvwUn+1ma8YHgkpGGohQaOb91FqDZLQi6aZ1/XBX
2aLt46XSgvp3y9EO2dVeFepW2dTyAPZMCkWEvJINXpRQQ6X2iu0iDjZoqB3aA8dU
UP8I3FsoFOg4A2haiMxBgGhldf9VCAJtoKrMoxOOgDhCypwZPqSlmRn3QeqO0MmG
aVDt5MBqKIXMmG2cUDy+KvsylGXtZ9VisvIU4UAIJaUGEopuYygEYQQhETN9uAXK
ts6yWdfAU438NcNoFnChrNeHwQS8TuZlV1pcV7xQ2gaKB1cS3I+MGWOzTTWD/zs=
=4PKd
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging
# gpg: Signature made Fri 29 Mar 2019 07:30:26 GMT
# gpg: using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211
* remotes/jasowang/tags/net-pull-request:
net: tap: use qemu_set_nonblock
MAINTAINERS: Update the latest email address
e1000: Delay flush queue when receive RCTL
net/socket: learn to talk with a unix dgram socket
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Here's a set of bugfixes for ppc, aimed at qemu-4.0 during hard freeze.
We have one cleanup that's not strictly a bugfix, but will avoid an
ugly external interface making it to a released version.
We have one change to generic code to tweak the semantics of
qemu_getrampagesize() which fixes a bug for ppc. This does have a
possible impact on s390x which uses this function for a different
purpose. I've discussed with David Hildenbrand and Igor Mammedov,
however and we think it won't immediately break anything due to some
existing bugs in the s390 usage. David H will be following up with
some s390 fixes in that area.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAlydkLUACgkQbDjKyiDZ
s5KYWw/+MWHPjYrgq2YqWr5VwRFhjV3gg86sQKCq+k/OhRl1ALmQ8DIDA5IBU/zf
EmFPOdE4hvaCbYRLDyBL5ayVR/obu1+J3SHo1gDNAoXnpSIoTN+a2DeL8qfQekQL
0EyPnARHlZZiHVM7YWyKIKUKpsptT5TRuZrUmM4pWXNWhk3qF39XQ0gCnMqdfd5U
n8qcKKz9UxlFPkhyw/mGveMV1eJTlw1EQCyvUsfCgoK0LljDUvlZPCOI/O2jupPn
mL7CifCm2yPs9ZuEgr/YSNYUCk96gf4hTdN2FiqdZWYbgUQaMDW/HtL6DwR5jI1W
IXqnD7qsJxrHzsw9ZWBTjcK1PGaw2UMnuHNemI/T6sZP7UIsU3DmKsVA14GEWVBa
zdO9HxQNa+UjKKtpTijqGxga3jya236a2ssgTr871chWs6cPH2db/iHNUM15ri1J
wVFmQpAJrLNy5KLGL8Mgs6muH4DVaefKhWdGy3A/l5ThDZp0yAb27sYwVqzHm7P8
L+jbEoWqRgplkVOtx9jCBjiuca5Sdwi2uhZ5Q6bjEwTPcMU90J6NcsN92/QvEuod
Tmx/SZs81Pzg8Icq7AMbPbHaVYLy6pDlxIE8KX5wCrhqbWaH2UaxBU2M8mDOdxS5
AihcQA+KUwnBiRRLaANTGnfJ3FZMNak7qwBP6clNKpazsv53f7Q=
=sHfP
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190329' into staging
ppc patch queue 2019-03-29
Here's a set of bugfixes for ppc, aimed at qemu-4.0 during hard freeze.
We have one cleanup that's not strictly a bugfix, but will avoid an
ugly external interface making it to a released version.
We have one change to generic code to tweak the semantics of
qemu_getrampagesize() which fixes a bug for ppc. This does have a
possible impact on s390x which uses this function for a different
purpose. I've discussed with David Hildenbrand and Igor Mammedov,
however and we think it won't immediately break anything due to some
existing bugs in the s390 usage. David H will be following up with
some s390 fixes in that area.
# gpg: Signature made Fri 29 Mar 2019 03:27:49 GMT
# gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full]
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-4.0-20190329:
exec: Only count mapped memory backends for qemu_getrampagesize()
spapr/irq: Add XIVE sanity checks on non-P9 machines
spapr: Simplify handling of host-serial and host-model values
target/ppc: Fix QEMU crash with stxsdx
target/ppc: Improve comment of bcctr used for spectre v2 mitigation
target/ppc: Consolidate 64-bit server processor detection in a helper
target/ppc: Enable "decrement and test CTR" version of bcctr
target/ppc: Fix TCG temporary leaks in gen_bcond()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The fcntl will change the flags directly, use qemu_set_nonblock()
instead.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
-net socket has a fd argument, and may be passed pre-opened sockets.
TCP sockets use framing.
UDP sockets have datagram boundaries.
When given a unix dgram socket, it will be able to read from it, but
will attempt to send on the dgram_dst, which is unset. The other end
will not receive the data.
Let's teach -net socket to recognize a UNIX DGRAM socket, and use the
regular send() command (without dgram_dst).
This makes running slirp out-of-process possible that
way (python pseudo-code):
a, b = socket.socketpair(socket.AF_UNIX, socket.SOCK_DGRAM)
subprocess.Popen('qemu -net socket,fd=%d -net user' % a.fileno(), shell=True)
subprocess.Popen('qemu ... -net nic -net socket,fd=%d' % b.fileno(), shell=True)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
qemu_getrampagesize() works out the minimum host page size backing any of
guest RAM. This is required in a few places, such as for POWER8 PAPR KVM
guests, because limitations of the hardware virtualization mean the guest
can't use pagesizes larger than the host pages backing its memory.
However, it currently checks against *every* memory backend, whether or not
it is actually mapped into guest memory at the moment. This is incorrect.
This can cause a problem attempting to add memory to a POWER8 pseries KVM
guest which is configured to allow hugepages in the guest (e.g.
-machine cap-hpt-max-page-size=16m). If you attempt to add non-hugepage,
you can (correctly) create a memory backend, however it (correctly) will
throw an error when you attempt to map that memory into the guest by
'device_add'ing a pc-dimm.
What's not correct is that if you then reset the guest a startup check
against qemu_getrampagesize() will cause a fatal error because of the new
memory object, even though it's not mapped into the guest.
This patch corrects the problem by adjusting find_max_supported_pagesize()
(called from qemu_getrampagesize() via object_child_foreach) to exclude
non-mapped memory backends.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
On non-P9 machines, the XIVE interrupt mode is not advertised, see
spapr_dt_ov5_platform_support(). Add a couple of checks on the machine
configuration to filter bogus setups and prevent OS failures :
Interrupt modes
CPU/Compat XICS XIVE dual
P8/P8 OK QEMU failure (1) OK (3)
P9/P8 OK QEMU failure (2) OK (3)
P9/P9 OK OK OK
(1) CPU exception model is incompatible with XIVE and the presenters
will fail to realize.
(2) CPU exception model is compatible with XIVE, but the XIVE CAS
advertisement is dropped when in POWER8 mode. So we could ended up
booting with the XIVE DT properties but without the HCALLs. Avoid
confusing Linux with such settings and fail under QEMU.
(3) force XICS in machine init
Remove the check on XIVE-only machines in spapr_machine_init(), which
has now become redundant.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190328100044.11408-1-clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
27461d69a0 "ppc: add host-serial and host-model machine attributes
(CVE-2019-8934)" introduced 'host-serial' and 'host-model' machine
properties for spapr to explicitly control the values advertised to the
guest in device tree properties with the same names.
The previous behaviour on KVM was to unconditionally populate the device
tree with the real host serial number and model, which leaks possibly
sensitive information about the host to the guest.
To maintain compatibility for old machine types, we allowed those props
to be set to "passthrough" to take the value from the host as before. Or
they could be set to "none" to explicitly omit the device tree items.
Special casing specific values on what's otherwise a user supplied string
is very ugly. So, this patch simplifies things by implementing the
backwards compatibility in a different way: we have a machine class flag
set for the older machines, and we only load the host values into the
device tree if A) they're not set by the user and B) we have that flag set.
This does mean that the "passthrough" functionality is no longer available
with the current machine type. That's ok though: if a user or management
layer really wants the information passed through they can read it
themselves (OpenStack Nova already does something similar for x86).
It also means the user can't explicitly ask for the values to be omitted
on the old machine types. I think that's an acceptable trade-off: if you
care enough about not leaking the host information you can either move to
the new machine type, or use a dummy value for the properties.
For the new machine type, this also removes an odd inconsistency
between running on a POWER and non-POWER (or non-Linux) hosts: if the
host information couldn't be read from where we expect (in the host's
device tree as exposed by Linux), we'd fallback to omitting the guest
device tree items.
While we're there, improve some poorly worded comments, and the help text
for the properties.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Greg Kurz <groug@kaod.org>
I've been hitting several QEMU crashes while running a fedora29 ppc64le
guest under TCG. Each time, this would occur several minutes after the
guest reached login:
Fedora 29 (Twenty Nine)
Kernel 4.20.6-200.fc29.ppc64le on an ppc64le (hvc0)
Web console: https://localhost:9090/
localhost login:
tcg/tcg.c:3211: tcg fatal error
This happens because a bug crept up in the gen_stxsdx() helper when it
was converted to use VSR register accessors by commit 8b3b2d75c7
"target/ppc: introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers
for VSR register access".
The code creates a temporary, passes it directly to gen_qemu_st64_i64()
and then to set_cpu_vrsh()... which looks like this was mistakenly
coded as a load instead of a store.
Reverse the logic: read the VSR to the temporary first and then store
it to memory.
Fixes: 8b3b2d75c7
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155371035249.2038502.12364252604337688538.stgit@bahia.lan>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155359567174.1794128.3183997593369465355.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We use PPC_SEGMENT_64B in various places to guard code that is specific
to 64-bit server processors compliant with arch 2.x. Consolidate the
logic in a helper macro with an explicit name.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155327783157.1283071.3747129891004927299.stgit@bahia.lan>
Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Even if all ISAs up to v3 indeed mention:
If the "decrement and test CTR" option is specified (BO2=0), the
instruction form is invalid.
The UMs of all existing 64-bit server class processors say:
If BO[2] = 0, the contents of CTR (before any update) are used as the
target address and for the test of the contents of CTR to resolve the
branch. The contents of the CTR are then decremented and written back
to the CTR.
The linux kernel has spectre v2 mitigation code that relies on a
BO[2] = 0 variant of bcctr, which is now activated by default on
spapr, even with TCG. This causes linux guests to panic with
the default machine type under TCG.
Since any CPU model can provide its own behaviour for invalid forms,
we could possibly introduce a new instruction flag to handle this.
In practice, since the behaviour is shared by all 64-bit server
processors starting with 970 up to POWER9, let's reuse the
PPC_SEGMENT_64B flag. Caveat: this may have to be fixed later if
POWER10 introduces a different behaviour.
The existing behaviour of throwing a program interrupt is kept for
all other CPU models.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155327782604.1283071.10640596307206921951.stgit@bahia.lan>
Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A single patch updating the MAINTAINERS file for 4.0.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9sSsRtSTSGjTuM6PIeENKd+XcFQFAlybrIgACgkQIeENKd+X
cFTOBAf+PO66rn/0Lc9Q6HzTBZF8tYZiiybb57t+LE6xyJ73RMu2e77XIBmAPGNl
Kizs1KoR7MVgkYoBfHWr6EStpQx5FBv+Nm0okHJ1M5orCGymrKg14Ndg8xKIu+V4
WisYPF/V07sAJ1Z5D4+YYXzq/lvmQkM2F1cOolUka+D60RcVI8Zwx/yQTRoTcxMr
gabrmmwQjDxjST6TrpW6PxsGKj2qag6DQJGvQ6GfrAESpGImiHlQr78ELDfi/Fyi
fA4F7SFIyX9X+7OF4FDLvBm4rpamqfnLwJw+Vka3C4hzgRjZIxjwovR83KHiOhr1
nY7KmQxitjrBT+IHmKT7cPTJeZWwjQ==
=t6jJ
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/alistair/tags/pull-device-tree-20190327' into staging
Device Tree Pull Request for 4.0
A single patch updating the MAINTAINERS file for 4.0.
# gpg: Signature made Wed 27 Mar 2019 17:02:00 GMT
# gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full]
# Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054
* remotes/alistair/tags/pull-device-tree-20190327:
MAINTAINERS: Update the device tree maintainers
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Remove Alex as a Device Tree maintainer as requested by him. Add myself
as a maintainer to avoid it being orphaned. Also add David as a
Reviewer (R) as he is the libfdt and DTC maintainer.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alexander Graf <agraf@csgraf.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Most of the seccomp functions return errnos as a negative return
value. The code is currently ignoring these and reporting a generic
error message for all seccomp failure scenarios making debugging
painful. Report a more precise error from each failed call and include
errno if it is available.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Eduardo Otubo <otubo@redhat.com>
The Mesa library tries to set process affinity on some of its threads in
order to optimize its performance. Currently this results in QEMU being
immediately terminated when seccomp is enabled.
Mesa doesn't consider failure of the process affinity settings to be
fatal to its operation, but our seccomp policy gives it no choice in
gracefully handling this denial.
It is reasonable to consider that malicious code using the resource
control syscalls to be a less serious attack than if they were trying
to spawn processes or change UIDs and other such things. Generally
speaking changing the resource control setting will "merely" affect
quality of service of processes on the host. With this in mind, rather
than kill the process, we can relax the policy for these syscalls to
return the EPERM errno value. This allows callers to detect that QEMU
does not want them to change resource allocations, and apply some
reasonable fallback logic.
The main downside to this is for code which uses these syscalls but does
not check the return value, blindly assuming they will always
succeeed. Returning an errno could result in sub-optimal behaviour.
Arguably though such code is already broken & needs fixing regardless.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Eduardo Otubo <otubo@redhat.com>
- Fix slow pre-zeroing in qemu-img convert
- Test case for block job pausing on I/O errors
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcmkUAAAoJEH8JsnLIjy/WYWcQAJaDWuowiFZ8myUcv46+A3tE
WjTUrXKe+hUYUzuEWdpIHjvx4paogfu0Qo+8EdBWphYsSKPqqxQb0wFMtaxD4fC6
jN3p/7LYyc2ce6puquX7yoBvXcIiTZimTLodf4Go3t4eDAcR88X75S0GSLqTWFT0
qWpxOpDlWhBACPRAjQCQT4dez3rBtgaD6IXmBXX0BQjzsDtRCeg68PZyN1WAcT20
KosatuEyaO6H2N9LbBMFFvfpO8rTaObY9F4jKFuFKw4iwjaWe8zCeoCXVBd7r+G4
vVzvCC+JZN/2KgBi8bX2CjID/CGiSOWNsVmBjylWWdWUsql/z0k1c9taqULfb4t9
unUIbsK/iATW5Pa1rBkoFK2spS5UEAMyGyqx5dtJoKOq8UMdheWYrqNRAgZ4jbg0
IE08Qgdh9+gA9mVHvy880ZAlPSPsUegeYGAZ/kS1yeNqkts2oStFKwyYZ1MXNUyJ
rVTUtT1Zs8oxKg8mVQ0tq6M+boDksPhnB995eVuQy5Uo5pI8viXrceX1QcrRNFZP
7FEoc0lMPlPWHbGuJPamxKLLKcAKrp7aVGfWb4CGvGKoKDNcs8reQ3odPXLdQ1qa
LjFnOos6EXf3Rrl5d5jXEPdmjrw6oPmTPiOReie+ktwPuzNFV3wZHnTrbqoYAoWl
blKdSV1xhTZRkMy4aCbz
=wQ4/
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches:
- Fix slow pre-zeroing in qemu-img convert
- Test case for block job pausing on I/O errors
# gpg: Signature made Tue 26 Mar 2019 15:28:00 GMT
# gpg: using RSA key 7F09B272C88F2FD6
# 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:
qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK
qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing
file-posix: Support BDRV_REQ_NO_FALLBACK for zero writes
block: Advertise BDRV_REQ_NO_FALLBACK in filter drivers
block: Add BDRV_REQ_NO_FALLBACK
block: Remove error messages in bdrv_make_zero()
iotests: add 248: test resume mirror after auto pause on ENOSPC
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The vCont packet accepts a series of actions, each being applied on a
given thread ID. Giving no thread ID for an action is valid and means
"all threads".
This commit fixes vCont packets being incorrectly rejected when no
thread ID was given for an action.
In multiprocess mode, the GDB Remote Protocol specification is unclear
on what "all threads" means. We choose to apply the action on all
threads of all attached processes.
This commit is based on the initial fix by Lucien Murray-Pitts.
Fixes: e40e5204af
Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com>
Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Luc Michel <luc.michel@greensocs.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190325110452.6756-1-luc.michel@greensocs.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Coverity (CID 1399700) found that this was wrong so instead of trying
to do it by hand use existing access functions that should work better.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-id: 20190318223842.427CB7456B2@zero.eik.bme.hu
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This makes the new BDRV_REQ_NO_FALLBACK flag available in the qemu-io
write command.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
If qemu-img convert sees that the target image isn't zero-initialised
yet, it tries to do an efficient zero write for the whole image first
to save the overhead of repeated explicit zero writes during the
conversion. Obviously, this provides only an advantage if the
pre-zeroing is actually efficient. Otherwise, we can end up writing
zeroes slowly while zeroing out the whole image, and then overwrite the
same blocks again with real data, potentially doubling the written data.
Pass BDRV_REQ_NO_FALLBACK to blk_make_zero() to avoid this case. If we
can't efficiently zero out, we'll instead write explicit zeroes only if
there is no data to be written to a block.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
We know that the kernel implements a slow fallback code path for
BLKZEROOUT, so if BDRV_REQ_NO_FALLBACK is given, we shouldn't call it.
The other operations we call in the context of .bdrv_co_pwrite_zeroes
should usually be quick, so no modification should be needed for them.
If we ever notice that there are additional problematic cases, we can
still make these conditional as well.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
Filter drivers that support .bdrv_co_pwrite_zeroes can safely advertise
BDRV_REQ_NO_FALLBACK because they just forward the request flags to
their child node.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
For qemu-img convert, we want an operation that zeroes out the whole
image if this can be done efficiently, but that returns an error
otherwise so we don't write explicit zeroes and immediately overwrite
them with the real data, potentially doubling the amount of data to be
written.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
There is only a single caller of bdrv_make_zero(), which is qemu-img
convert. If the function fails, we just fall back to a different method
of zeroing out blocks on the target image. There is no good reason to
print error messages on stderr when the higher level operation will
actually succeed.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Eric Blake <eblake@redhat.com>
Test that mirror job actually resume on resume command after being
automatically paused on ENOSPC error.
It's a follow-up test for 8d9648cbf3
"blockjob: fix user pause in block_job_error_action"
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Tested-by: John Snow <jsnow@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Sorry for sending two back-to-back pull requests. It looks like I
misunderstood Kito and there were actually two patches necessary to fix
the GCC test suite runs.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEAM520YNJYN/OiG3470yhUCzLq0EFAlyZ/OQTHHBhbG1lckBk
YWJiZWx0LmNvbQAKCRDvTKFQLMurQfdZEACqhvpBme021q04Bw6b3Q+Xh55CKt4U
Ay0APaTIlfAWIugJo9U/qefj8bG+j4ODsY4RwJ3qa3Kt9XcF8/JpJbK+3VgSjO+M
OZymL2xTLf59r4pK/am5Tbbbmz0Afo3mNPoACwmcBsQl9f5NNy0hpaoB95a+bppC
yN6YNfkEX1QKfYvzkkWmgmb9RPDwziDqitQbz0cfVoChtmVgcChFrY2YPCKQKz2H
jB33jHXVrKC5kMm6HUWpiyipfivi0vvutK3c+Vgr3pd6hMwRycqzfAO/CnfrQaf6
m4Z9vcon0NUZhofa5Qxwf+z2GUEu/vxpDepC4GmxIkOZnBZSeP6KH+fp1JqomWpM
VP+FhPenXbpSrOQvsYedyzhHT2a71wML18vDfBZw0sPRhqn7GoRGX4lOOjjfUjbE
yMzQy9RTbJ/j5xJUjIjqifVWH8AtTWLvdLt0dyGEfWaW+8Bt65gbT6N+nyiIs7We
CmdadoTytn3ehZIBAbHIodXFuwj9TipvaLPVzVxTAEIbiybjPONnVHLryqMYs4s8
KXSQoZEO8OkIU67XH3StECpzHc2gJC0GrWaD4v2kjYez8VNrlMKPaLqotSKusXbR
KLym87nw+Miadqh/lZ3iHqwvpO+vai0f6wz7YiMCCl14k8wgIz1+3e4w9TnrezBD
zemWGz/wdNq8eg==
=negc
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-4.0-rc1-v2' into staging
A second RISC-V Patch for 4.0.0-rc1
Sorry for sending two back-to-back pull requests. It looks like I
misunderstood Kito and there were actually two patches necessary to fix
the GCC test suite runs.
# gpg: Signature made Tue 26 Mar 2019 10:20:20 GMT
# gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41
# gpg: issuer "palmer@dabbelt.com"
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown]
# gpg: aka "Palmer Dabbelt <palmer@sifive.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: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41
* remotes/palmer/tags/riscv-for-master-4.0-rc1-v2:
target/riscv: Fix wrong expanding for c.fswsp
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
base register is no rs1 not rs2 for fsw.
Signed-off-by: Kito Cheng <kito.cheng@gmail.com>
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
If this is too late I'm OK with it being in rc2, but it fixes a concrete
regression and nobody has complained yet so I'd prefer it to be in rc1
if possible.
The fix is to zero-extend the inputs to DIVUW and REMUW, which was
exposed by the GCC test suite.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEAM520YNJYN/OiG3470yhUCzLq0EFAlyZvowTHHBhbG1lckBk
YWJiZWx0LmNvbQAKCRDvTKFQLMurQWSoD/0aEguPUC2iDtJY8Tw5ZMl3KIZgA5I1
TI0Ik/8SvhXNLv9TJzx4c44qfLJ3EWtii7W7hmvxBUKilgmykNY1CnThDT/vEXSk
jK4OBBFRLtBAKva6n7XxDaebJ7d3KLJm76Ff+d/B8qHy+bP+PAPWnpmH+9snxAqf
/MImgrz3YUeYT3pQjeJVbpJjCOAcnEMk6syOKPsEzppFaWnoFWMzto1eGSkpi7/w
28MzUV+1pb/MhlwpJf7NxlEDYbmx+vT/LP8dgT+IRlynk9HkaZ+Vpjm93o1rJlpo
Imm3rbW2OjtwrY5IyyUgoGgxmVG2Riwb+Y71giJ9XeXB35FUt2UFtOod/BdkznWp
dt61zzf1j/bD6QfJfN8iy8jR6uHxN/f+9beh4nCQivF09fSsf2NO6lGeNNSOVvdh
vQiHZgDygpsnw4dZwOd7sLZTeQPUt3gtQB67a3PUiHVLW6Dy0IhoaAColVlpvilD
xSB7FsmqKDobFmo7FLShIHgBcdq3irGOvCuGgHH82XMGMBX2PRpSg6VLjN4QWfAR
V1VujOs8icU0Np+0XowuOYCjE+vnvodgM3Rm4LhE41RHogWqBorE/lOCj74di5rG
gdCSbHeHMjbsai4MkSIJnzxafprfJBbvWwodUVv4bAJ89YdJRHN3PmrlSMAe7/ol
Xo2c2HkZ5t27QA==
=wgpv
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-4.0-rc1' into staging
A Single RISC-V Patch for 4.0-rc1
If this is too late I'm OK with it being in rc2, but it fixes a concrete
regression and nobody has complained yet so I'd prefer it to be in rc1
if possible.
The fix is to zero-extend the inputs to DIVUW and REMUW, which was
exposed by the GCC test suite.
# gpg: Signature made Tue 26 Mar 2019 05:54:20 GMT
# gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41
# gpg: issuer "palmer@dabbelt.com"
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown]
# gpg: aka "Palmer Dabbelt <palmer@sifive.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: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41
* remotes/palmer/tags/riscv-for-master-4.0-rc1:
target/riscv: Zero extend the inputs of divuw and remuw
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We disabled code to limit device sizes to 8, 16, 32 or 64MiB more than
a decade ago in commit 95d1f3edd5 and c8b153d794, v0.9.1. Bury.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[Extracted from a larger patch, extended to pflash_cfi02.c]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190319163551.32499-3-armbru@redhat.com>
We reject undersized backends with a rather enigmatic "failed to read
the initial flash content" error. For instance:
$ qemu-system-ppc64 -S -display none -M sam460ex -drive if=pflash,format=raw,file=eins.img
qemu-system-ppc64: Initialization of device cfi.pflash02 failed: failed to read the initial flash content
We happily accept oversized images, ignoring their tail. Throwing
away parts of firmware that way is pretty much certain to end in an
even more enigmatic failure to boot.
Require the backend's size to match the device's size exactly. Report
mismatch like this:
qemu-system-ppc64: Initialization of device cfi.pflash01 failed: device requires 1048576 bytes, block backend provides 512 bytes
Improve the error for actual read failures to "can't read block
backend".
To avoid duplicating even more code between the two pflash device
models, do all that in new helper blk_check_size_and_read_all().
The error reporting can still be confusing. For instance:
qemu-system-ppc64 -S -display none -M taihu -drive if=pflash,format=raw,file=eins.img -drive if=pflash,unit=1,format=raw,file=zwei.img
qemu-system-ppc64: Initialization of device cfi.pflash02 failed: device requires 2097152 bytes, block backend provides 512 bytes
Leaves the user guessing which of the two -drive is wrong. Mention
the issue in a TODO comment.
Suggested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190319163551.32499-2-armbru@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
There are no harm but just looks weird to return bool in
pointer-returning function. Introduced in 69240fe62d with the whole
failure-checking "if" chunk.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190325154748.66381-1-vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
The assert checking if the value of lexer->state in next_state(),
which is used as an index to the 'json_lexer' array, incorrectly
checks for an index value less than or equal to ARRAY_SIZE(json_lexer).
Fix assert so that it just checks for an index less than the array size.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-Id: <1553169472-25325-1-git-send-email-liam.merwick@oracle.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Patch created mechanically by rerunning:
$ spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-file scripts/cocci-macro-file.h \
--dir hw/block --in-place
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190313174433.12966-1-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
This NULL check was required while introduced in 680d16dcb7.
Later refactor added a NULL check in error_setv(), so this check
is now redundant.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190302223825.11192-2-philmd@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
- Rebase last pull request
- Drop multifd
- several other minor fixesLaLaLa
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJcmRP1AAoJEPSH7xhYctcjVDcP/iZoCgMDn0BVzYFamRAIvtlh
1h1ElV+Jx49bHRvDRs0RaTSIlowqnbMY5yiTfn0L7aSbOr8KLEbs+i+jo5moF3+Q
50TNxGTDF/WWvl+z8X3WljwDPYBnG7mYeDBNBk+8V2RI/DvV2uAdm29VPmPN/Kc8
hW8S6kXRAQekkkt0BOkXHXWQlmvzHS9RqQoZ0dETP9GqcT7cJ6HDZJu8akiz6Oz3
r0Hek41EVQirjfKL+Sm5BluiiuvNcdFGsYK/TqLiCpnHolNUboMnIhXiTX2BJRf7
TEK8UGrbgXa3SarszCBxjsjMFYRJlq6Vi7ZQ54Ly7+wFr09jhIDgt9AlEr0YjOj4
8AgGF6nKYmFahQuKvJ1xMrgY3EccBDWXJKBwcnnd5zMJyVGlNtUUs7f7pSA3V/oG
wEDMzmxcpKxK3A9jpPBgEN4ev0oKaR+rxAdy5NPTU7kMZV651JXt2pOirGm5AL2V
soKiiSklUZ7VpJ998PnGj7pO4LL8xWW3Pi4mzlH6dv+Aw9T2L9vY8rPFEktOJ4V5
8qB9PERlAG/KbpVH2lrkUFFk4sfxBmVTG+SppwCk4I6/eSaDuO3pjXcuwiFaIyqT
kHLsBVT0kLEYeE6zty2YHvjIEmAyaJxr2HezWquQ9xQOezDl1s3wjVGRFJ6xZDKn
uMHI4j2i5UWA8B73inh0
=kjyq
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/juanquintela/tags/migration-pull-request' into staging
Pull request
- Rebase last pull request
- Drop multifd
- several other minor fixesLaLaLa
# gpg: Signature made Mon 25 Mar 2019 17:46:29 GMT
# gpg: using RSA key F487EF185872D723
# gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full]
# gpg: aka "Juan Quintela <quintela@trasno.org>" [full]
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723
* remotes/juanquintela/tags/migration-pull-request:
migration/postcopy: Update the bandwidth during postcopy
Migration/colo.c: Make user obtain the last COLO mode info after failover
Migration/colo.c: Add the necessary checks for colo_do_failover
Migration/colo.c: Add new COLOExitReason to handle all failover state
Migration/colo.c: Fix COLO failover status error
migration/rdma: Check qemu_rdma_init_one_block
migration: add support for a "tls-authz" migration parameter
multifd: Drop x-
multifd: Add some padding
multifd: Change default packet size
multifd: Be flexible about packet size
multifd: Drop x-multifd-page-count parameter
multifd: Create new next_packet_size field
multifd: Rename "size" member to pages_alloc
multifd: Only send pages when packet are not empty
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The recently added max-postcopy-bandwidth parameter is only read
at the transition from precopy->postcopy where as the older
max-bandwidth parameter updates the migration bandwidth when changed
even if the migration is already running.
Fix this discrepency so that:
a) You can change the bandwidth during postcopy by setting
max-postcopy-bandwidth
b) Changing max-bandwidth during postcopy has no effect
(it currently changes the postcopy bandwidth which isn't
expected).
Fixes: 7e555c6c
bz: https://bugzilla.redhat.com/show_bug.cgi?id=1686321
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
Add the last_colo_mode to save the status after failover.
This patch can solve the issue that user want to get last colo mode
use query_colo_status after failover.
Signed-off-by: Zhang Chen <chen.zhang@intel.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
