Commit Graph

57474 Commits

Author SHA1 Message Date
Alexey Kardashevskiy
2fb9636ebf vfio-pci: Remove unused fields from VFIOMSIXInfo
When support for multiple mappings per a region were added, this was
left behind, let's finish and remove unused bits.

Fixes: db0da029a1 ("vfio: Generalize region support")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-12-13 10:19:34 -07:00
Alexey Kardashevskiy
c6e7958eb7 vfio/spapr: Allow fallback to SPAPR TCE IOMMU v1
The vfio_iommu_spapr_tce driver advertises kernel's support for
v1 and v2 IOMMU support, however it is not always possible to use
the requested IOMMU type. For example, a pseries host platform does not
support dynamic DMA windows so v2 cannot initialize and QEMU fails to
start.

This adds a fallback to the v1 IOMMU if v2 cannot be used.

Fixes: 318f67ce13 ("vfio: spapr: Add DMA memory preregistering (SPAPR IOMMU v2)")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-12-13 10:19:33 -07:00
Liu, Yi L
f7f9c7b232 vfio/common: init giommu_list and hostwin_list of vfio container
The init of giommu_list and hostwin_list is missed during container
initialization.

Signed-off-by: Liu, Yi L <yi.l.liu@linux.intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-12-13 10:19:33 -07:00
Alex Williamson
2016986aed vfio: Fix vfio-kvm group registration
Commit 8c37faa475 ("vfio-pci, ppc64/spapr: Reorder group-to-container
attaching") moved registration of groups with the vfio-kvm device from
vfio_get_group() to vfio_connect_container(), but it missed the case
where a group is attached to an existing container and takes an early
exit.  Perhaps this is a less common case on ppc64/spapr, but on x86
(without viommu) all groups are connected to the same container and
thus only the first group gets registered with the vfio-kvm device.
This becomes a problem if we then hot-unplug the devices associated
with that first group and we end up with KVM being misinformed about
any vfio connections that might remain.  Fix by including the call to
vfio_kvm_device_add_group() in this early exit path.

Fixes: 8c37faa475 ("vfio-pci, ppc64/spapr: Reorder group-to-container attaching")
Cc: qemu-stable@nongnu.org # qemu-2.10+
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-12-13 10:19:32 -07:00
Peter Maydell
0a0dc59d27 Update version for v2.11.0 release
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-13 14:31:09 +00:00
Peter Maydell
6afd0c1998 Update version for v2.11.0-rc5 release
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-11 17:49:53 +00:00
Peter Maydell
7472e2efb0 target/arm: Generate UNDEF for 32-bit Thumb2 insns
The refactoring of commit 296e5a0a6c has a nasty bug:
it accidentally dropped the generation of code to raise
the UNDEF exception when disas_thumb2_insn() returns nonzero.
This means that 32-bit Thumb2 instruction patterns that
ought to UNDEF just act like nops instead. This is likely
to break any number of things, including the kernel's "disable
the FPU and use the UNDEF exception to identify when to turn
it back on again" trick.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1513006964-3371-1-git-send-email-peter.maydell@linaro.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2017-12-11 17:11:27 +00:00
Peter Maydell
2babfe0c92 Update version for v2.11.0-rc4 release
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-05 16:36:46 +00:00
Eric Farman
2994cb2ee2 vhost-scsi: add missing virtqueue_size parameter
Commit 5c0919d020 ("virtio-scsi: Add virtqueue_size parameter allowing
virtqueue size to be set.") introduced a new parameter to virtio-scsi.
Later, commit 9200361060 ("vhost-user-scsi: add missing virtqueue_size
param") added that parameter to the new vhost-user-scsi interface but
neglected the existing vhost-scsi interface it was built on.

Apply the same change to vhost-scsi, so that we can boot a guest with
a device defined.  This also avoids crashing a guest when hotplugging
a vhost-scsi device.

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Message-id: 20171201151538.6844-2-farman@linux.vnet.ibm.com
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-05 12:38:31 +00:00
Peter Maydell
88f714aa5a ppc patch queue 2017-12-05
Alas, this is yet another fix for ppc that I think it's worth
 squeezing into 2.11.  It's a really ugly fix for some pretty ugly
 code, but it does seem to address a real problem.  It's also a problem
 that's appeared relatively recently, since it was either created by,
 or made much easier to trigger by, by the merge of MTTCG.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAlomLXQACgkQbDjKyiDZ
 s5IHeg//X3JQ//s7BhmAAPERA4p/0bwuRZWk1T+zwypc1HZegjDfwMtH0GCjhabU
 OhVgdneuqFwHJEeWyLWLpEwHazX8hk9CYRYi186oblHgKtPaqXRI30Pnywni3hx6
 Bx4GFf84fZmPdibbE3IGNpyXOjUuAsx54MaWKpIZzYTTrZYUc2+W8DK7B9kiiAfm
 Tv1mWJxg7YVtnedB8wo+HyEjGL3V3Ww+09YmYqjJz+AQT05fFONYJddLjvnFInFs
 FtSqeF8KD86KbhPSWVJtSGwHMXO344F2ZhIjk57JwKDxDC/x/0Xg/7pmQ0RMSvxW
 phTHsQ0iCoJs0ix6B0ATlqxgMlVf5GkveqIkgxF8z9QrAjajHSHasVsBRbb+qaRS
 ozWdtYPHiN/+hjg8zEsmUR3yPtyHysk5KDWCq7rAt7thFEV6xTMfIDNAKDlwmE5i
 JhoTHLj+wH+l6q3/iuzQpSLTfymN2fA2f58IK+U1WUo0fHEg4bRW/dHz+SO6gJwV
 iTyl0Du2T5eaKGvfdB9jfGQXrmXcOu1yNLTD4pUG3cpGI57dPnoL+/Qq/gIQgmwl
 qBTCSlJWWoiwy0v7iEixd5ULDAG5l8niUyGNPTsN8PXtwProyfSvY/eHwEcrmwWo
 0lt+sJUywKEeL+TVnRdny4fFSOcb861m3GEYfAj/uSlYKLDjnaE=
 =L4ZT
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.11-20171205' into staging

ppc patch queue 2017-12-05

Alas, this is yet another fix for ppc that I think it's worth
squeezing into 2.11.  It's a really ugly fix for some pretty ugly
code, but it does seem to address a real problem.  It's also a problem
that's appeared relatively recently, since it was either created by,
or made much easier to trigger by, by the merge of MTTCG.

# gpg: Signature made Tue 05 Dec 2017 05:24:04 GMT
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.11-20171205:
  target/ppc: Fix system lockups caused by interrupt_request state corruption

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-05 10:00:48 +00:00
Richard Purdie
044897ef4a target/ppc: Fix system lockups caused by interrupt_request state corruption
Occasionally in Linux guests on x86_64 we're seeing logs like:

ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 00000100req 00000004

when they should read:

ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 00000100req 00000002

The "00000004" is CPU_INTERRUPT_EXITTB yet the code calls
cpu_interrupt(cs, CPU_INTERRUPT_HARD) ("00000002") in this function
just before the log message. Something is causing the HARD bit setting
to get lost.

The knock on effect of losing that bit is the decrementer timer interrupts
don't get delivered which causes the guest to sit idle in its idle handler
and 'hang'.

The issue occurs due to races from code which sets CPU_INTERRUPT_EXITTB.

Rather than poking directly into cs->interrupt_request, that code needs to:

a) hold BQL
b) use the cpu_interrupt() helper

This patch fixes the call sites to do this, fixing the hang. The calls
are made from a variety of contexts so a helper function is added to handle
the necessary locking. This can likely be improved and optimised in the future
but it ensures the code is correct and doesn't lockup as it stands today.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-12-05 12:28:42 +11:00
Peter Maydell
2a4c7e8391 Block layer patches for 2.11.0-rc4
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJaJXvPAAoJEH8JsnLIjy/WtG4P+wRXE/G4fyTDmnDJgYxZm6S8
 spC5BpnBWDuux1Vo5TKHzRX6T3attoWLWlHYDLwDmi/ZW6UIVpDchn6sb5MhsoXQ
 hb9Qwwir2A/fOFBda+YOfqXlFTk4Dn5FdJYsYuSt/k834ixAsobSCrVVhdyFrTEb
 NyJWAl+4eJ7omGthCdsiZpheUFU9XdW2t8oARcjt+eCscgLao99IRh12LfiKtH+4
 EmFtiEk6MaNStf+Yvr+B/ZG9JQJHQR/YvFRAiQ7ZUwXRNWOn1Wrg7bPNd8YVwMGd
 MbuZ2Hpl5oJMXZzi4kxyn9oQEJ426bbGRZgVg0rEiBlmCZXFGyJpth2f3PDO08Rj
 0edfuwF+ArAbNr9VQIjG7p/yFzRYB09F1SCp2MxFPUXjxBdoAU1C4GLfUKu8N8y2
 zMKl7Y9ngXzv8vk6NIH73/LuagAXHfnt5tsB3mb/fa1qySSX9Nx+zpm7ptpHiIrv
 xZNZalb9ev3KNF8JOYktpIySghBC2zNcpK9Ovfe8PwymEGNnlzzoYAcCVk7r1/LQ
 pc8i2LrD1t2ophwZZAPj2+D3UbUhkqvV3Mm4t7wMys3OGJM5hRv0BbABan3rARLY
 Q0jKrdLZDQZ5EL0GzbJphPeCbwkVLI4Ol8ZiAdQUasyDSLUOWaazUCcfJKUZVtTD
 JguEi1qB4hqcnOCCziq9
 =SOiX
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging

Block layer patches for 2.11.0-rc4

# gpg: Signature made Mon 04 Dec 2017 16:46:07 GMT
# gpg:                using RSA key 0x7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74  56FE 7F09 B272 C88F 2FD6

* remotes/kevin/tags/for-upstream:
  blockjob: Make block_job_pause_all() keep a reference to the jobs

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-04 17:19:04 +00:00
Alberto Garcia
3d5d319e12 blockjob: Make block_job_pause_all() keep a reference to the jobs
Starting from commit 40840e419b we are
pausing all block jobs during bdrv_reopen_multiple() to prevent any of
them from finishing and removing nodes from the graph while they are
being reopened.

It turns out that pausing a block job doesn't necessarily prevent it
from finishing: a paused block job can still run its exit function
from the main loop and call block_job_completed(). The mirror block
job in particular always goes to the main loop while it is paused (by
virtue of the bdrv_drained_begin() call in mirror_run()).

Destroying a paused block job during bdrv_reopen_multiple() has two
consequences:

   1) The references to the nodes involved in the job are released,
      possibly destroying some of them. If those nodes were in the
      reopen queue this would trigger the problem originally described
      in commit 40840e419b, crashing QEMU.

   2) At the end of bdrv_reopen_multiple(), bdrv_drain_all_end() would
      not be doing all necessary bdrv_parent_drained_end() calls.

I can reproduce problem 1) easily with iotest 030 by increasing
STREAM_BUFFER_SIZE from 512KB to 8MB in block/stream.c, or by tweaking
the iotest like in this example:

   https://lists.gnu.org/archive/html/qemu-block/2017-11/msg00934.html

This patch keeps an additional reference to all block jobs between
block_job_pause_all() and block_job_resume_all(), guaranteeing that
they are kept alive.

Signed-off-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-12-04 17:44:51 +01:00
Peter Maydell
e80a25611c pc, pci, virtio: fixes for rc3
A bunch of fixes all over the place.
 
 Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
 -----BEGIN PGP SIGNATURE-----
 
 iQEcBAABAgAGBQJaIYwZAAoJECgfDbjSjVRpeL0IAKSrsoe8c5WSwRWerRdlDE14
 EUjUtz3sEhTNC05fTX/t7OyBnuRaU3T3und0ZwArCR4gIE196yzj619ZOReYeoJp
 iPqqVTR6gPP7Y0IeeI56wV9wSyOH68n9JM4MOWdXjquSrJxrGg+fPxWXQH/pvmfy
 QEhFkg/kL48c1ezJUIIAFdU0I+NY4dSzuAjINgl2rdlEATIMQBsEnOlFSgwg1aTb
 pAPz/uOvVdstnnW2JiA0n0slU2Ix2eorHuv3B0J4wRb2mTD/uQWml0eaWYQf6cLu
 O3dgifkhuxwmm7kUedZGYtUSj9cHGLnH850ovo6mW1/Drte2SItCqrlsh230cW8=
 =ZiXl
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging

pc, pci, virtio: fixes for rc3

A bunch of fixes all over the place.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Fri 01 Dec 2017 17:06:33 GMT
# gpg:                using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* remotes/mst/tags/for_upstream:
  pc: fix crash on attempted cpu unplug
  virtio: check VirtQueue Vring object is set
  vhost: fix error check in vhost_verify_ring_mappings()
  dump-guest-memory.py: fix No symbol "vmcoreinfo_find"
  vhost: restore avail index from vring used index on disconnection
  virtio: Add queue interface to restore avail index from vring used index
  i386/msi: Correct mask of destination ID in MSI address

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-04 13:08:13 +00:00
Peter Maydell
495566ec38 ppc patch queue 2017-12-04
We are, alas, not yet to the bottom of ppc bugs.  This pull request
 fixes several more.  I believe they're important enough to include in
 2.11. despite the late date.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAlokw8gACgkQbDjKyiDZ
 s5Jc8A/6Ar6UyJnPEN3xxs+ax1tRBsfSf4QnoWvRsqNjdBI5uTiF3ebIz3HzcJ8l
 ztFxjiSfZsN+CfiqdBa0cAU0adF225HpZF8OaXeG1W+UfTJI9IrbReGj3xqB6A8P
 4X2X3fV0WxVAUV6BE1iT57wvm+x9HB4yO5/SkmDMzSumgVr6X709/x7Ln0TWeyt2
 LY6rSmfcWdgV0BYFg3brHSNh71gmDL4XhNoflTYEFGIdGMqcTLUkCwi7VVb0zfGe
 XXW/E6oEjX13RlSSN5eexMFb1Qef0673bTAQVADjGpan1wUXu9gYIKmrrTjBjHVt
 ENE3F0urmUFUC5Bg/AffAsZrCJmdq9/ycG6+bj8J4Gpitp1XzrsCYFY2L/j2yDvc
 cSvB7DBRNUsakjUwveT5rqcNsU+/fWtj0sqy9w2Z298XlHWirJWQ/W5EEQQrILln
 Q3posZp6LHybdzw6oF2ytxsZ3/q+foAMfzh54k4n+kMV4k6xHGPKr50ttoxmTNNr
 k/Ej7XcWhvLiZ74NErxP1iwdLSBR5v/RfrHx5fK87QSN+v87e/nZtfnnimQMjksM
 hlfALFbH1DxlKQPO7rCTktXZnZk6zO0DjU12UwYPJEL94HLPemaUTEBwwYGI8Ctq
 ZmyZgkzt0SD+3D0Hz4XSnlGW6wrkgzZe/LyvOIZGPvL4n2VzHKg=
 =fgoQ
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.11-20171204' into staging

ppc patch queue 2017-12-04

We are, alas, not yet to the bottom of ppc bugs.  This pull request
fixes several more.  I believe they're important enough to include in
2.11. despite the late date.

# gpg: Signature made Mon 04 Dec 2017 03:40:56 GMT
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.11-20171204:
  spapr: Include "pre-plugged" DIMMS in ram size calculation at reset
  target-ppc: Don't invalidate non-supported msr bits
  pseries: fix TCG migration

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-12-04 11:27:53 +00:00
David Gibson
768a20f3a4 spapr: Include "pre-plugged" DIMMS in ram size calculation at reset
At guest reset time, we allocate a hash page table (HPT) for the guest
based on the guest's RAM size.  If dynamic HPT resizing is not available we
use the maximum RAM size, if it is we use the current RAM size.

But the "current RAM size" calculation is incorrect - we just use the
"base" ram_size from the machine structure.  This doesn't include any
pluggable DIMMs that are already plugged at reset time.

This means that if you try to start a 'pseries' machine with a DIMM
specified on the command line that's much larger than the "base" RAM size,
then the guest will get a woefully inadequate HPT.  This can lead to a
guest freeze during boot as it runs out of HPT space during initial MMU
setup.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Greg Kurz <groug@kaod.org>
2017-12-04 11:31:22 +11:00
Igor Mammedov
75ba2ddb18 pc: fix crash on attempted cpu unplug
when qemu is started with '-no-acpi' CLI option, an attempt
to unplug a CPU using device_del results in null pointer
dereference at:

  #0 object_get_class
  #1 pc_machine_device_unplug_request_cb
  #2 qmp_marshal_device_del

which is caused by pcms->acpi_dev == NULL due to ACPI support
being disabled.

Considering that ACPI support is necessary for unplug to work,
check that it's enabled and fail unplug request gracefully
if no acpi device were found.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01 19:05:58 +02:00
Prasad J Pandit
758ead31c7 virtio: check VirtQueue Vring object is set
A guest could attempt to use an uninitialised VirtQueue object
or unset Vring.align leading to a arithmetic exception. Add check
to avoid it.

Reported-by: Zhangboxian <zhangboxian@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2017-12-01 19:05:58 +02:00
Greg Kurz
2fe45ec3bf vhost: fix error check in vhost_verify_ring_mappings()
Since commit f1f9e6c5 "vhost: adapt vhost_verify_ring_mappings() to
virtio 1 ring layout", we check the mapping of each part (descriptor
table, available ring and used ring) of each virtqueue separately.

The checking of a part is done by the vhost_verify_ring_part_mapping()
function: it returns either 0 on success or a negative errno if the
part cannot be mapped at the same place.

Unfortunately, the vhost_verify_ring_mappings() function checks its
return value the other way round. It means that we either:
- only verify the descriptor table of the first virtqueue, and if it
  is valid we ignore all the other mappings
- or ignore all broken mappings until we reach a valid one

ie, we only raise an error if all mappings are broken, and we consider
all mappings are valid otherwise (false success), which is obviously
wrong.

This patch ensures that vhost_verify_ring_mappings() only returns
success if ALL mappings are okay.

Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01 19:05:58 +02:00
Marc-André Lureau
d36d0a9d15 dump-guest-memory.py: fix No symbol "vmcoreinfo_find"
When qemu is compiled without debug, the dump gdb python script can fail with:

Error occurred in Python command: No symbol "vmcoreinfo_find" in current context.

Because vmcoreinfo_find() is inlined and not exported.

Use the underlying object_resolve_path_type() to get the instance instead.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01 19:05:58 +02:00
Maxime Coquelin
2ae39a113a vhost: restore avail index from vring used index on disconnection
vhost_virtqueue_stop() gets avail index value from the backend,
except if the backend is not responding.

It happens when the backend crashes, and in this case, internal
state of the virtio queue is inconsistent, making packets
to corrupt the vring state.

With a Linux guest, it results in following error message on
backend reconnection:

[   22.444905] virtio_net virtio0: output.0:id 0 is not a head!
[   22.446746] net enp0s3: Unexpected TXQ (0) queue failure: -5
[   22.476360] net enp0s3: Unexpected TXQ (0) queue failure: -5

Fixes: 283e2c2adc ("net: virtio-net discards TX data after link down")
Cc: qemu-stable@nongnu.org
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01 19:05:58 +02:00
Maxime Coquelin
2d4ba6cc74 virtio: Add queue interface to restore avail index from vring used index
In case of backend crash, it is not possible to restore internal
avail index from the backend value as vhost_get_vring_base
callback fails.

This patch provides a new interface to restore internal avail index
from the vring used index, as done by some vhost-user backend on
reconnection.

Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01 19:05:58 +02:00
Chao Gao
861fec459b i386/msi: Correct mask of destination ID in MSI address
According to SDM 10.11.1, only [19:12] bits of MSI address are
Destination ID, change the mask to avoid ambiguity for VT-d spec
has used the bit 4 to indicate a remappable interrupt request.

Signed-off-by: Chao Gao <chao.gao@intel.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01 18:28:15 +02:00
Kurban Mallachiev
be1b21e885 target-ppc: Don't invalidate non-supported msr bits
The msr invalidation code (commits 993eb and 2360b) inverts all
bits except MSR_TGPR and MSR_HVB. On non PowerPC 601 processors
this leads to incorrect change of excp_prefix in hreg_store_msr()
function. The problem is that new msr value get multiplied by msr_mask
and inverted msr does not, thus values of MSR_EP bit in new msr value
and inverted msr are distinct, so that excp_prefix changes but should
not.

Signed-off-by: Kurban Mallachiev <mallachiev@ispras.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-11-30 14:56:42 +11:00
Laurent Vivier
0c86b2df78 pseries: fix TCG migration
Migration of pseries is broken with TCG because
QEMU tries to restore KVM MMU state unconditionally.

The result is a SIGSEGV in kvm_vm_ioctl():

  #0  kvm_vm_ioctl (s=0x0, type=-2146390353)
      at qemu/accel/kvm/kvm-all.c:2032
  #1  0x00000001003e3e2c in kvmppc_configure_v3_mmu (cpu=<optimized out>,
      radix=<optimized out>, gtse=<optimized out>, proc_tbl=<optimized out>)
      at qemu/target/ppc/kvm.c:396
  #2  0x00000001002f8b88 in spapr_post_load (opaque=0x1019103c0,
      version_id=<optimized out>) at qemu/hw/ppc/spapr.c:1578
  #3  0x000000010059e4cc in vmstate_load_state (f=0x106230000,
      vmsd=0x1009479e0 <vmstate_spapr>, opaque=0x1019103c0,
      version_id=<optimized out>) at qemu/migration/vmstate.c:165
  #4  0x00000001005987e0 in vmstate_load (f=<optimized out>, se=<optimized out>)
      at qemu/migration/savevm.c:748

This patch fixes the problem by not calling the KVM function with the
TCG mode.

Fixes: d39c90f5f3 ("spapr: Fix migration of Radix guests")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-11-30 13:57:51 +11:00
Peter Maydell
c11d61271b Update version for v2.11.0-rc3 release
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-29 17:59:34 +00:00
Peter Maydell
915308bc3f Block layer patches for 2.11.0-rc3
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJaHtFZAAoJEH8JsnLIjy/WYRoP/RK99nDFweOwaoBfUCyT3uc3
 mHFtc5Jvo4gxkPSn0wDg+KuJ5z+BRk4S+CgyF+9Wny3ZJMiRAAt/BfNMofj4hfdD
 BPF5jLkvoClAFrqZe6keBadRfYjQPuhtLvrBMDoG294VsyvKoYMVrEOMV5PaWY4r
 RaHZY6OiADmNeMj3gCTRAae9KEGWlZ64FeYyizp1kWMwjH6I3jRZguGgA+409K0e
 pwJQLOUT6IaSibOuFn88IeayDy8h+XheH+FxlV0rVRRZ3rulxlpWPtUV2EE6L7rx
 iQk2eC+r4393sH6Owj0oVTlSCPCx4k7nZeIALcnHh6Muh/dV9mSMzItXP9ZV8YlP
 sAJByXoHdH3fcfSnHA7yP27pYmt0EuaVlIT+I9d4lh0bB/xRMzd5GDsx63xkzHuI
 kVTIQj04bYt2E3sdqfNbu/eC4imakmNIjxD+jgamNLM64XIIfKpCjkguR9oO4+5V
 o1A868QxJhiFlDNmaT7fLeeFw2z5pRAoOpTyMbOVYF3q2oj2qT6yIEvGxroE0cfX
 pYKnCaXI/GQrx9cbRgxBM97bsepeK8MI3/aDjxrtyaYnr0wzzdJYIfuooAhC3C/c
 965pioeYqxcwauJ7thHkiPkefI1Qbl1yvMrH8iSW43bh1wm2u6V+UYCBtZSk/0e7
 cbh//qd78KgmjdjdHyLw
 =ATxJ
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging

Block layer patches for 2.11.0-rc3

# gpg: Signature made Wed 29 Nov 2017 15:25:13 GMT
# gpg:                using RSA key 0x7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74  56FE 7F09 B272 C88F 2FD6

* remotes/kevin/tags/for-upstream:
  block/nfs: fix nfs_client_open for filesize greater than 1TB
  blockjob: reimplement block_job_sleep_ns to allow cancellation
  blockjob: introduce block_job_do_yield
  blockjob: remove clock argument from block_job_sleep_ns
  block: Expect graph changes in bdrv_parent_drained_begin/end
  blockjob: Remove the job from the list earlier in block_job_unref()
  QAPI & interop: Clarify events emitted by 'block-job-cancel'
  qemu-options: Mention locking option of file driver
  docs: Add image locking subsection
  iotests: fix 075 and 078

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-29 16:25:23 +00:00
Kevin Wolf
5591c001a1 One block patch for 2.11.0-rc3
-----BEGIN PGP SIGNATURE-----
 
 iQEcBAABAgAGBQJaHsQWAAoJEPQH2wBh1c9ARJgH/0QgyhOOx7+LaRzCYEt6r0MQ
 ucl1y8JC7qLBoN4Dlg2y8omo3mKYxTTldBA9nNp3T6f7YvrWsdElwcDWSkEnt5hj
 4O4GrRPsPx5vpeuQUW9kaUMSanoUw7R2lf0dx8h2/GGFLCuTAm3P91frAJSfidaS
 yH9sNeuC/BcU4iol8QEpQiK11dUSowYCvaLGPeTaeWnxK502DBtce/1bQias3w5y
 r8/regb36mTJTXkvjfTXPSlqsKTCh2Nx5y/a6mef3yhbIPG74K1Kn90p+zMtWi25
 67J2scZGRSwpeyGu+s4KrOV24VBhknGhShjhGgdDmxasWsOhoTPM/Z0KZbeJDvM=
 =fVmh
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'mreitz/tags/pull-block-2017-11-29' into queue-block

One block patch for 2.11.0-rc3

# gpg: Signature made Wed Nov 29 15:28:38 2017 CET
# gpg:                using RSA key F407DB0061D5CF40
# gpg: Good signature from "Max Reitz <mreitz@redhat.com>"
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1  1829 F407 DB00 61D5 CF40

* mreitz/tags/pull-block-2017-11-29:
  block/nfs: fix nfs_client_open for filesize greater than 1TB

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29 15:37:31 +01:00
Peter Lieven
f1a7ff770f block/nfs: fix nfs_client_open for filesize greater than 1TB
DIV_ROUND_UP(st.st_size, BDRV_SECTOR_SIZE) was overflowing ret (int) if
st.st_size is greater than 1TB.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Lieven <pl@kamp.de>
Message-id: 1511798407-31129-1-git-send-email-pl@kamp.de
Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-11-29 15:28:15 +01:00
Paolo Bonzini
fc24908e7d blockjob: reimplement block_job_sleep_ns to allow cancellation
This reverts the effects of commit 4afeffc857 ("blockjob: do not allow
coroutine double entry or entry-after-completion", 2017-11-21)

This fixed the symptom of a bug rather than the root cause. Canceling the
wait on a sleeping blockjob coroutine is generally fine, we just need to
make it work correctly across AioContexts.  To do so, use a QEMUTimer
that calls block_job_enter.  Use a mutex to ensure that block_job_enter
synchronizes correctly with block_job_sleep_ns.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-By: Jeff Cody <jcody@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29 15:26:21 +01:00
Paolo Bonzini
356f59b875 blockjob: introduce block_job_do_yield
Hide the clearing of job->busy in a single function, and set it
in block_job_enter.  This lets block_job_do_yield verify that
qemu_coroutine_enter is not used while job->busy = false.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-By: Jeff Cody <jcody@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29 15:11:14 +01:00
Paolo Bonzini
5bf1d5a73a blockjob: remove clock argument from block_job_sleep_ns
All callers are using QEMU_CLOCK_REALTIME, and it will not be possible to
support more than one clock when block_job_sleep_ns switches to a single
timer stored in the BlockJob struct.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Tested-By: Jeff Cody <jcody@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29 15:11:02 +01:00
Kevin Wolf
02d213009d block: Expect graph changes in bdrv_parent_drained_begin/end
The .drained_begin/end callbacks can (directly or indirectly via
aio_poll()) cause block nodes to be removed or the current BdrvChild to
point to a different child node.

Use QLIST_FOREACH_SAFE() to make sure we don't access invalid
BlockDriverStates or accidentally continue iterating the parents of the
new child node instead of the node we actually came from.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Jeff Cody <jcody@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-29 14:22:03 +01:00
Alberto Garcia
0a3e155f3f blockjob: Remove the job from the list earlier in block_job_unref()
When destroying a block job in block_job_unref() we should remove it
from the job list before calling block_job_remove_all_bdrv().

This is because removing the BDSs can trigger an aio_poll() and wake
up other jobs that might attempt to use the block job list. If that
happens the job we're currently destroying should not be in that list
anymore.

Signed-off-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-28 16:59:24 +01:00
Peter Maydell
844496f3e5 nbd patches for 2017-11-28
Eric Blake - 0/2 fix two NBD server CVEs
 -----BEGIN PGP SIGNATURE-----
 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
 
 iQEcBAABCAAGBQJaHV11AAoJEKeha0olJ0NqhL0IAJOHoH7yej3P4qPlJMO0BJ3s
 ACVUOvF+4Ms4nAjXlpqZh59ZU83rH8Q5NuyJn2k7dotVY9nvaKQGqgT/FB9Gqq0G
 hUOGCSDsF/4olyUkq4tcCD5gRc962YFEPr7TCbAXufZmxKFHDNnW32wyo3NtKQfR
 Ph7YA9pNOgf0u2Y9/sjhz2CQn6svB6NDswgHvHqTvSHQyLTSH0G5u0HSbAB6X/SZ
 swz9blEDiV5OVb53TpYSzgzVGZjWlfesCpUV2hTVSOeZ/koUhKf9H87msj9n5itt
 hyvgANehDBDMbSLNc3irHPaN9kL5ulmYdCmyssepXe77/QRokQ69ZhqUxIRofvU=
 =Igjs
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2017-11-28' into staging

nbd patches for 2017-11-28

Eric Blake - 0/2 fix two NBD server CVEs

# gpg: Signature made Tue 28 Nov 2017 12:58:29 GMT
# gpg:                using RSA key 0xA7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>"
# gpg:                 aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>"
# gpg:                 aka "[jpeg image of size 6874]"
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2  F3AA A7A1 6B4A 2527 436A

* remotes/ericb/tags/pull-nbd-2017-11-28:
  nbd/server: CVE-2017-15118 Stack smash on large export name
  nbd/server: CVE-2017-15119 Reject options larger than 32M

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-28 13:12:48 +00:00
Eric Blake
51ae4f8455 nbd/server: CVE-2017-15118 Stack smash on large export name
Introduced in commit f37708f6b8 (2.10).  The NBD spec says a client
can request export names up to 4096 bytes in length, even though
they should not expect success on names longer than 256.  However,
qemu hard-codes the limit of 256, and fails to filter out a client
that probes for a longer name; the result is a stack smash that can
potentially give an attacker arbitrary control over the qemu
process.

The smash can be easily demonstrated with this client:
$ qemu-io f raw nbd://localhost:10809/$(printf %3000d 1 | tr ' ' a)

If the qemu NBD server binary (whether the standalone qemu-nbd, or
the builtin server of QMP nbd-server-start) was compiled with
-fstack-protector-strong, the ability to exploit the stack smash
into arbitrary execution is a lot more difficult (but still
theoretically possible to a determined attacker, perhaps in
combination with other CVEs).  Still, crashing a running qemu (and
losing the VM) is bad enough, even if the attacker did not obtain
full execution control.

CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
2017-11-28 06:58:01 -06:00
Eric Blake
fdad35ef6c nbd/server: CVE-2017-15119 Reject options larger than 32M
The NBD spec gives us permission to abruptly disconnect on clients
that send outrageously large option requests, rather than having
to spend the time reading to the end of the option.  No real
option request requires that much data anyways; and meanwhile, we
already have the practice of abruptly dropping the connection on
any client that sends NBD_CMD_WRITE with a payload larger than 32M.

For comparison, nbdkit drops the connection on any request with
more than 4096 bytes; however, that limit is probably too low
(as the NBD spec states an export name can theoretically be up
to 4096 bytes, which means a valid NBD_OPT_INFO could be even
longer) - even if qemu doesn't permit exports longer than 256
bytes.

It could be argued that a malicious client trying to get us to
read nearly 4G of data on a bad request is a form of denial of
service.  In particular, if the server requires TLS, but a client
that does not know the TLS credentials sends any option (other
than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
payload of nearly 4G, then the server was keeping the connection
alive trying to read all the payload, tying up resources that it
would rather be spending on a client that can get past the TLS
handshake.  Hence, this warranted a CVE.

Present since at least 2.5 when handling known options, and made
worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
to handle unknown options.

CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
2017-11-28 06:42:26 -06:00
Peter Maydell
a914f04c23 Merge qio 2017/11/28 v1
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABCAAGBQJaHT8kAAoJEL6G67QVEE/fAwsQAJ1v9Qa8jUaqC5G58hnpR++f
 wtBtp6+wO2xJhrwlIQwWwOZ6NJysljQ8gPekAMjsKXunFC8eoclfJFOLDkVMo88Q
 UREXbxDCjBpcBP/+WpdFmCS7TllWSu/vWlQBOPbgjB9ggQv/lvqJJLpcpkYKo2ea
 xR3cAvgKtHWZTW3X/Wkv45Co8NVKap3f4q4BXXKPCQyzIfbuM/JAV+AqvrCNCo6B
 2LNK7JWfHqnfuQQ7cZ/9ogBMuaLqN5XnX7+cyPI41v3WBaoktTqXjanwcAUXWXGN
 dsOfO4CdNdToOGgGV61gh2bKuuVuABLWmlIIVC2fwEAymzx+k70EWKXCzxYLTfr3
 VfBcXZlYMPWVRcZYFjJWS6YumYnCIT17u1+V0Rq7misIvJpPS3nwjtKzZtjStOwU
 +WZRRgz7zlyI/d1zQjl6PjqNaTScejRwZgs+snGZpYPvmYMVVh8S7SRlfGIif/PE
 3g86pezIWeDnLaWFI2/S6F4qiCtqk02tO21Xylg/LM9O9HZaDP9wIZ66IPVC6JLT
 QoTHECExlceGjV+wLX9T9CRkMeMNHpTp57rsH0K03rofe4DHPL66EiansFu4KGQn
 o4ayxQWn/rzS731h6V6otl4YWuhFFs7KRHuNe6IioenqBZX30/uh9DuKg4yORLOB
 6XUSZe4HcvaJcudTY1QM
 =Jm6n
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/berrange/tags/pull-qio-2017-11-28-1' into staging

Merge qio 2017/11/28 v1

# gpg: Signature made Tue 28 Nov 2017 10:49:08 GMT
# gpg:                using RSA key 0xBE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>"
# gpg:                 aka "Daniel P. Berrange <berrange@redhat.com>"
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF

* remotes/berrange/tags/pull-qio-2017-11-28-1:
  sockets: avoid crash when cleaning up sockets for an invalid FD

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-28 11:52:11 +00:00
Daniel P. Berrange
2d7ad7c05e sockets: avoid crash when cleaning up sockets for an invalid FD
If socket_listen_cleanup is passed an invalid FD, then querying the socket
local address will fail. We must thus be prepared for the returned addr to
be NULL

Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-11-28 10:48:04 +00:00
Peter Maydell
c7e1f823ae -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
 
 iQEcBAABAgAGBQJaHN7TAAoJEO8Ells5jWIRkYYH/jUDWH5/LXVnA+2R8/k8/jQL
 wyXvVKdAJloU1MZ1N49dpPifkQjLcRZ2CD0o+5W91z1WSOj4966/+C9+nNsogJpn
 08hq01zdnquNQf/4z1Gl2hoIYQe/z1AaDCNuI1py/vUDh4+VwkxXBtf8DSeBveja
 1+qdg+NCWWrwp9f5cygR9F4tOI+HfYjqI6nqIBsITXeQ3zPUbs+1Ry1YRJ+kUKqI
 xixxKm2M2sYKHtEFTtHQpvEMbKxuuEaGGZ6uHgm6t7HIcGE1YOn1NIPa4AvTfeFO
 2tKcynR0c3Svhq07b3M/JrnPhjQgOfOUwzaLB5sHNThkjV65jS0/23M5cTvo5tI=
 =mazL
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging

# gpg: Signature made Tue 28 Nov 2017 03:58:11 GMT
# gpg:                using RSA key 0xEF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>"
# 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:
  virtio-net: don't touch virtqueue if vm is stopped

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-28 10:03:26 +00:00
Jason Wang
70e53e6e4d virtio-net: don't touch virtqueue if vm is stopped
Guest state should not be touched if VM is stopped, unfortunately we
didn't check running state and tried to drain tx queue unconditionally
in virtio_net_set_status(). A crash was then noticed as a migration
destination when user type quit after virtqueue state is loaded but
before region cache is initialized. In this case,
virtio_net_drop_tx_queue_data() tries to access the uninitialized
region cache.

Fix this by only dropping tx queue data when vm is running.

Fixes: 283e2c2adc ("net: virtio-net discards TX data after link down")
Cc: Yuri Benditovich <yuri.benditovich@daynix.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2017-11-28 11:54:50 +08:00
Kashyap Chamarthy
c117bb14ff QAPI & interop: Clarify events emitted by 'block-job-cancel'
When you cancel an in-progress 'mirror' job (or "active `block-commit`")
with QMP `block-job-cancel`, it emits the event: BLOCK_JOB_CANCELLED.
However, when `block-job-cancel` is issued *after* `drive-mirror` has
indicated (via the event BLOCK_JOB_READY) that the source and
destination have reached synchronization:

    [...] # Snip `drive-mirror` invocation & outputs
    {
      "execute":"block-job-cancel",
      "arguments":{
        "device":"virtio0"
      }
    }

    {"return": {}}

It (`block-job-cancel`) will counterintuitively emit the event
'BLOCK_JOB_COMPLETED':

    {
      "timestamp":{
        "seconds":1510678024,
        "microseconds":526240
      },
      "event":"BLOCK_JOB_COMPLETED",
      "data":{
        "device":"virtio0",
        "len":41126400,
        "offset":41126400,
        "speed":0,
        "type":"mirror"
      }
    }

But this is expected behaviour, where the _COMPLETED event indicates
that synchronization has successfully ended (and the destination now has
a point-in-time copy, which is at the time of cancel).

So add a small note to this effect in 'block-core.json'.  While at it,
also update the "Live disk synchronization -- drive-mirror and
blockdev-mirror" section in 'live-block-operations.rst'.

(Thanks: Max Reitz for reminding me of this caveat on IRC.)

Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-27 14:59:35 +01:00
Peter Maydell
5e19aed59a ppc patch queue 2017-11-27
This series contains a couple of migration fixes for hash guests on
 POWER9 radix MMU hosts.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAloblCMACgkQbDjKyiDZ
 s5LHjRAAy/hpTIcZvrV48Rem48aI+aWP8f0CJBkywkqZIDZFpUPimSr7ETO6Bhhy
 bwLNY1oQSbEdsl7G/B1gpxLK2VkiNVkBUOZVP59yfydVXzw30b6pedoRJN3rpyax
 ex+rSNkfW/ZA4zmjHT2jvrokj+mxRSj1IvjLglfPgAiLaIaKVurWFkOQzP/LLbUB
 IleMRj2Jvh4WS9HIXNfErgyfiwHqdIKdAL5+a5v97J20qTy3Pvz6e8WSItQjUYF1
 RqN5lPDX3a+s0nXRxO4Nko1vLN2gFFqI5sK/M3TcwrMZnoiXfaY50rDQyxxA1Ycu
 leyuIqqopIQDRCAvkHYO6DCS2P2k+BTLQ0K7LcNRgOmMdyqMbOrTQVLQKyNFDQaZ
 4d2OSogJwEI1nFgsBnxXmIT8Lkyydc9j/nFg0q2xpV2ADdHzBv4bgrNW6go2OSkl
 RpV6kViB4Drhkt/oYJ6+NaObDUTPxoD9sAJ+wHFQcUvGgj41zHDDvOF1MuyKxNgc
 xVNE1oUZB4XjsXIIiY6FVR50+OX8ygZSOAjUlDg5cWA4B5k14g7IHQTMPsu4D6p0
 UiGyfNobuQfxV+lhF4kcm0OnlG+AD2EVOmgiwGumg39wzMFOaIw7qxcYbFjUCsAo
 2M0x9wrXw0pslhx2SsVQITtHdiQsOFWap4LqUBR5tmxxPYm5wmk=
 =F0lq
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.11-20171127' into staging

ppc patch queue 2017-11-27

This series contains a couple of migration fixes for hash guests on
POWER9 radix MMU hosts.

# gpg: Signature made Mon 27 Nov 2017 04:27:15 GMT
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.11-20171127:
  target/ppc: Fix setting of cpu->compat_pvr on incoming migration
  target/ppc: Move setting of patb_entry on hash table init

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-27 11:16:20 +00:00
Fam Zheng
1878eaff9b qemu-options: Mention locking option of file driver
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-27 11:25:41 +01:00
Fam Zheng
b1d1cb2728 docs: Add image locking subsection
This documents the image locking feature and explains when and how
related options can be used.

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-27 11:25:41 +01:00
John Snow
45f1882a9e iotests: fix 075 and 078
Both of these tests are for formats which now stipulate that they are
read-only. Adjust the tests to match.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Lukáš Doktor <ldoktor@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-11-27 11:25:41 +01:00
Suraj Jitindar Singh
e07cc19295 target/ppc: Fix setting of cpu->compat_pvr on incoming migration
cpu->compat_pvr is used to store the current compat mode of the cpu.

On the receiving side during incoming migration we check compatibility
with the compat mode by calling ppc_set_compat(). However we fail to set
the compat mode with the hypervisor since the "new" compat mode doesn't
differ from the current (due to a "cpu->compat_pvr != compat_pvr" check).
This means that kvm runs the vcpus without a compat mode, which is the
incorrect behaviour. The implication being that a compatibility mode
will never be in effect after migration.

To fix this so that the compat mode is correctly set with the
hypervisor, store the desired compat mode and reset cpu->compat_pvr to
zero before calling ppc_set_compat().

Fixes: 5dfaa532 ("ppc: fix ppc_set_compat() with KVM PR")

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-11-27 12:20:11 +11:00
Suraj Jitindar Singh
ee4d9ecc36 target/ppc: Move setting of patb_entry on hash table init
The patb_entry is used to store the location of the process table in
guest memory. The msb is also used to indicate the mmu mode of the
guest, that is patb_entry & 1 << 63 ? radix_mode : hash_mode.

Currently we set this to zero in spapr_setup_hpt_and_vrma() since if
this function gets called then we know we're hash. However some code
paths, such as setting up the hpt on incoming migration of a hash guest,
call spapr_reallocate_hpt() directly bypassing this higher level
function. Since we assume radix if the host is capable this results in
the msb in patb_entry being left set so in spapr_post_load() we call
kvmppc_configure_v3_mmu() and tell the host we're radix which as
expected means addresses cannot be translated once we actually run the cpu.

To fix this move the zeroing of patb_entry into spapr_reallocate_hpt().

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-11-27 12:20:11 +11:00
Peter Maydell
e7b47c22e2 osdep.h: Make TIME_MAX handle different time_t types
In our various supported host OSes, the time_t type may be either 32
or 64 bit, and could in theory also be either signed or unsigned.
Notably, in OpenBSD time_t is a 64 bit type even if 'long' is 32
bits, so using LONG_MAX for TIME_MAX is incorrect.

Use an approach suggested by Paolo Bonzini which calculates
the maximum value of the type rather than hardcoding it;
to do this we use the TYPE_MAXIMUM macro from Gnulib.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1511452598-6077-1-git-send-email-peter.maydell@linaro.org
2017-11-24 13:23:36 +00:00
Eric Auger
79283dda30 hw/arm/virt: Add 2.11 machine type
Add virt-2.11 machine type.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1511516626-21178-1-git-send-email-eric.auger@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-24 11:28:56 +00:00