Due to too early RCT0 interrput, win10x32 may hang on booting.
This problem can be reproduced by doing power cycle on win10x32 guest.
In our environment, we have 10 win10x32 and stress power cycle.
The problem will happen about 20 rounds.

Below shows some log with comment:

The normal case:

22831@1551928392.984687:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928392.985655:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928392.985801:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.056710:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.077548:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 2, ICR 0, IMR 0
e1000: set_ics 2, ICR 2, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
22831@1551928393.102974:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
22831@1551928393.103267:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle
RX now
e1000: set_ics 0, ICR 2, IMR 9d <- unmask interrupt
e1000: RCTL: 255, mac_reg[RCTL] = 0x48002
e1000: set_ics 80, ICR 2, IMR 9d <- interrupt and work!
...

The bad case:

27744@1551930483.117766:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
27744@1551930483.118398:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.198063:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.218675:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: set_ics 0, ICR 0, IMR 0
e1000: ICR read: 0
e1000: set_ics 2, ICR 0, IMR 0
e1000: set_ics 2, ICR 2, IMR 0
e1000: RCTL: 0, mac_reg[RCTL] = 0x0
27744@1551930483.241768:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
27744@1551930483.241979:e1000x_rx_disabled Received packet dropped
because receive is disabled RCTL = 0
e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle
RX now
e1000: set_ics 80, ICR 2, IMR 0 <- flush queue (caused by setting RCTL)
e1000: set_ics 0, ICR 82, IMR 9d <- unmask interrupt and because 0x82&0x9d
!= 0 generate interrupt, hang on here...

To workaround this problem, simply delay flush queue. Also stop receiving
when timer is going to run.

Tested on CentOS, Win7SP1x64 and Win10x32.
Signed-off-by: Nyuchenlin <yuchenlin@synology.com>
Reviewed-by: NDmitry Fleytman <dmitry.fleytman@gmail.com>
Signed-off-by: NJason 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: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>

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: NPeter Maydell <peter.maydell@linaro.org>

pull-seccomp-20190327

# gpg: Signature made Wed 27 Mar 2019 12:12:39 GMT
# gpg:                using RSA key DF32E7C0F0FFF9A2
# gpg: Good signature from "Eduardo Otubo (Senior Software Engineer) <otubo@redhat.com>" [full]
# Primary key fingerprint: D67E 1B50 9374 86B4 0723  DBAB DF32 E7C0 F0FF F9A2

* remotes/otubo/tags/pull-seccomp-20190327:
  seccomp: report more useful errors from seccomp
  seccomp: don't kill process for resource control syscalls
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

* Kconfig improvements (msi_nonbroken, imply for default PCI devices)
* intel-iommu: sharing passthrough FlatViews (Peter)
* Fix for SEV with VFIO (Brijesh)
* Allow compilation without CONFIG_PARALLEL (Thomas)

# gpg: Signature made Thu 21 Mar 2019 16:42:24 GMT
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* remotes/bonzini/tags/for-upstream: (23 commits)
  virtio-vga: only enable for specific boards
  config-all-devices.mak: rebuild on reconfigure
  minikconf: fix parser typo
  intel-iommu: optimize nodmar memory regions
  test-announce-self: convert to qgraph
  hw/alpha/Kconfig: DP264 hardware requires e1000 network card
  hw/hppa/Kconfig: Dino board requires e1000 network card
  hw/sh4/Kconfig: r2d machine requires the rtl8139 network card
  hw/ppc/Kconfig: e500 based machines require virtio-net-pci device
  hw/ppc/Kconfig: Bamboo machine requires e1000 network card
  hw/mips/Kconfig: Fulong 2e board requires ati-vga/rtl8139 PCI devices
  hw/mips/Kconfig: Malta machine requires the pcnet network card
  hw/i386/Kconfig: enable devices that can be created by default
  hw/isa/Kconfig: PIIX4 southbridge requires USB UHCI
  hw/isa/Kconfig: i82378 SuperIO requires PC speaker device
  prep: do not select I82374
  hw/i386/Kconfig: PC uses I8257, not I82374
  hw/char/parallel: Make it possible to compile also without CONFIG_PARALLEL
  target/i386: sev: Do not pin the ram device memory region
  memory: Fix the memory region type assignment order
  ...
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

# Conflicts:
#	hw/rdma/Makefile.objs
#	hw/riscv/sifive_plic.c

target/xtensa fixes for v4.0:

- fix translation of FLIX bundles with multiple references to the same
  register;
- don't announce exit simcall;
- clean up tests/tcg/xtensa.

# gpg: Signature made Tue 26 Mar 2019 17:58:59 GMT
# gpg:                using RSA key 2B67854B98E5327DCDEB17D851F9CC91F83FA044
# gpg:                issuer "jcmvbkbc@gmail.com"
# gpg: Good signature from "Max Filippov <filippov@cadence.com>" [unknown]
# gpg:                 aka "Max Filippov <max.filippov@cogentembedded.com>" [full]
# gpg:                 aka "Max Filippov <jcmvbkbc@gmail.com>" [full]
# Primary key fingerprint: 2B67 854B 98E5 327D CDEB  17D8 51F9 CC91 F83F A044

* remotes/xtensa/tags/20190326-xtensa:
  tests/tcg/xtensa: clean up test set
  target/xtensa: don't announce exit simcall
  target/xtensa: fix break_dependency for repeated resources
Signed-off-by: NPeter 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: NAlistair Francis <alistair.francis@wdc.com>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NAlexander Graf <agraf@csgraf.de>
Acked-by: NDavid 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: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NEduardo 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: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NEduardo Otubo <otubo@redhat.com>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

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: NPeter Maydell <peter.maydell@linaro.org>

fixes for 4.0: ohci and ati-vga

# gpg: Signature made Tue 26 Mar 2019 14:05:40 GMT
# gpg:                using RSA key 4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full]
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>" [full]
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full]
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/fixes-20190326-pull-request:
  ati-vga: Fix indexed access to video memory
  ohci: don't die on ED_LINK_LIMIT overflow
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

target-arm queue:
 * Set SIMDMISC and FPMISC for 32-bit -cpu max
   (fixes regression from 3.1)
 * fix vCont packet handling when no thread is specified

# gpg: Signature made Tue 26 Mar 2019 13:09:48 GMT
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20190326:
  gdbstub: fix vCont packet handling when no thread is specified
  target/arm: Set SIMDMISC and FPMISC for 32-bit -cpu max
Signed-off-by: NPeter 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: e40e5204Reported-by: NLucien Murray-Pitts <lucienmp_antispam@yahoo.com>
Reported-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NLuc Michel <luc.michel@greensocs.com>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20190325110452.6756-1-luc.michel@greensocs.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Fixes: https://bugs.launchpad.net/bugs/1821430Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Message-id: 20190325161338.6536-1-richard.henderson@linaro.org
Signed-off-by: NPeter 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: NBALATON Zoltan <balaton@eik.bme.hu>
Message-id: 20190318223842.427CB7456B2@zero.eik.bme.hu
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Stop processing the descriptor list instead. The next frame timer tick will
resume the work

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705Suggested-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
Message-id: 20190321085212.10796-1-lvivier@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This makes the new BDRV_REQ_NO_FALLBACK flag available in the qemu-io
write command.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Acked-by: NEric 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: NKevin Wolf <kwolf@redhat.com>
Acked-by: NEric 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: NKevin Wolf <kwolf@redhat.com>
Acked-by: NEric 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: NKevin Wolf <kwolf@redhat.com>
Acked-by: NEric 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: NKevin Wolf <kwolf@redhat.com>
Acked-by: NEric 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: NKevin Wolf <kwolf@redhat.com>
Acked-by: NEric 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 8d9648cb
    "blockjob: fix user pause in block_job_error_action"
Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Tested-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

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: NPeter Maydell <peter.maydell@linaro.org>

base register is no rs1 not rs2 for fsw.
Signed-off-by: NKito Cheng <kito.cheng@gmail.com>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Pflash and firmware configuration patches for 2019-03-26

# gpg: Signature made Tue 26 Mar 2019 07:21:13 GMT
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-pflash-2019-03-26:
  pflash: Bury disabled code to limit device sizes
  pflash: Require backend size to match device, improve errors
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Miscellaneous patches for 2019-03-26

# gpg: Signature made Tue 26 Mar 2019 07:10:23 GMT
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-misc-2019-03-26:
  qapi/qmp-dispatch: fix return value in do_qmp_dispatch
  json: Fix off-by-one assert check in next_state()
  xen-block: Replace qdict_put_obj() by qdict_put() where appropriate
  util/error: Remove an unnecessary NULL check
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

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: NPeter 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 95d1f3ed and c8b153d7, v0.9.1.  Bury.
Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
[Extracted from a larger patch, extended to pflash_cfi02.c]
Signed-off-by: NMarkus 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: NAlex Bennée <alex.bennee@linaro.org>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20190319163551.32499-2-armbru@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>

There are no harm but just looks weird to return bool in
pointer-returning function. Introduced in 69240fe6 with the whole
failure-checking "if" chunk.
Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190325154748.66381-1-vsementsov@virtuozzo.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarkus 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: NLiam Merwick <liam.merwick@oracle.com>
Message-Id: <1553169472-25325-1-git-send-email-liam.merwick@oracle.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NLi Qiang <liq3ea@gmail.com>
Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
Signed-off-by: NMarkus 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: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20190313174433.12966-1-armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Acked-by: NPaul Durrant <paul.durrant@citrix.com>
Reviewed-by: NKevin Wolf <kwolf@redhat.com>

This NULL check was required while introduced in 680d16dc.
Later refactor added a NULL check in error_setv(), so this check
is now redundant.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190302223825.11192-2-philmd@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

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: NPeter 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=1686321Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan 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: NZhang Chen <chen.zhang@intel.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NZhang Chen <chen.zhang@intel.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

In this patch we add the processing state for COLOExitReason,
because we have to identify COLO in the failover processing state or
failover error state. In the way, we can handle all the failover state.
We have improved the description of the COLOExitReason by the way.
Signed-off-by: NZhang Chen <chen.zhang@intel.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>