As it turns out we need to clear the ri controls and PSW enablement
bit to be architecture compliant.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20191203132813.2734-4-frankja@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
It defaults to returning 0 anyway and that return value is not
necessary, as 0 is also the default rc that the caller would return.
While doing that we can simplify the logic a bit and return early if
we inject a PGM exception.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20191129091713.4582-1-frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Let's improve readability by:
* Using constants for the subcodes
* Moving parameter checking into a function
* Removing subcode > 6 check as the default case catches that
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191127175046.4911-6-frankja@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Let's also move the clear reset function into the reset handler.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Message-Id: <20191127175046.4911-5-frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Let's move the intial reset into the reset handler and cleanup
afterwards.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191128083723.11937-1-frankja@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Let's start moving the cpu reset functions into a single function with
a switch/case, so we can later use fallthroughs and share more code
between resets.
This patch introduces the reset function by renaming cpu_reset().
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20191127175046.4911-3-frankja@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The initiating cpu needs to be reset with an initial reset. While
doing a normal reset followed by a initial reset is not wrong per se,
the Ultravisor will only allow the correct reset to be performed.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20191127175046.4911-2-frankja@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Add 5.0 machine types for arm/i440fx/q35/s390x/spapr.
For i440fx and q35, unversioned cpu models are still translated
to -v1; I'll leave changing this (if desired) to the respective
maintainers.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20191112104811.30323-1-cohuck@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Cooper Lake is intel's successor to Cascade Lake, the new
CPU model inherits features from Cascadelake-Server, while
add one platform associated new feature: AVX512_BF16. Meanwhile,
add STIBP for speculative execution.
Signed-off-by: Cathy Zhang <cathy.zhang@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Tao Xu <tao3.xu@intel.com>
Message-Id: <1571729728-23284-4-git-send-email-cathy.zhang@intel.com>
Reviewed-by: Bruce Rogers <brogers@suse.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
stibp feature is already added through the following commit.
0e89165829
Add a macro for it to allow CPU models to report it when host supports.
Signed-off-by: Cathy Zhang <cathy.zhang@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Tao Xu <tao3.xu@intel.com>
Message-Id: <1571729728-23284-3-git-send-email-cathy.zhang@intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Define MSR_ARCH_CAP_MDS_NO in the IA32_ARCH_CAPABILITIES MSR to allow
CPU models to report the feature when host supports it.
Signed-off-by: Cathy Zhang <cathy.zhang@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Tao Xu <tao3.xu@intel.com>
Message-Id: <1571729728-23284-2-git-send-email-cathy.zhang@intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Add -object iothread documentation to the man page, including references
to the query-iothread QMP command and qom-set syntax for adjusting
adaptive polling parameters at run-time.
Reported-by: Zhenyu Ye <yezhenyu2@huawei.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20191025122236.29815-1-stefanha@redhat.com
Message-Id: <20191025122236.29815-1-stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Virtio spec 1.1 (and earlier), 5.2.5.2 Driver Requirements: Device
Initialization:
"Devices SHOULD always offer VIRTIO_BLK_F_FLUSH, and MUST offer it if
they offer VIRTIO_BLK_F_CONFIG_WCE"
Currently F_CONFIG_WCE and F_WCE are not connected to each other.
Qemu will advertise F_CONFIG_WCE if config-wce argument is
set for virtio-blk device. And F_WCE is advertised only if
underlying block backend actually has it's caching enabled.
Fix this by advertising F_WCE if F_CONFIG_WCE is also advertised.
To preserve backwards compatibility with newer machine types make this
behaviour governed by "x-enable-wce-if-config-wce" virtio-blk-device
property and introduce hw_compat_4_2 with new property being off by
default for all machine types <= 4.2 (but don't introduce 4.3
machine type itself yet).
Signed-off-by: Evgeny Yakovlev <wrfsh@yandex-team.ru>
Message-Id: <1572978137-189218-1-git-send-email-wrfsh@yandex-team.ru>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The following MSI-X vectors are required:
* VIRTIO Configuration Change
* hiprio virtqueue
* requests virtqueues
Fix the calculation to reserve enough MSI-X vectors. Otherwise guest
drivers fall back to a sub-optional configuration where all virtqueues
share a single vector.
This change does not break live migration compatibility since
vhost-user-fs-pci devices are not migratable yet.
Reported-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20191209110759.35227-1-stefanha@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
The property doesn't make much sense for a vhost-user device.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20191116112016.14872-1-marcandre.lureau@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
It's been marked as deprecated since QEMU v4.1, time to remove it now.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Commit 7e46261368 converted virtfs-proxy-helper to using libcap-ng. There
aren't any users of libcap anymore. No need to install libcap-dev.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
We currently enable libcap-dev in build-clang to pick up the 9p proxy
helper. Paolo's patch changes (commit 7e46261368) that to use
libcap-ng, so switch to using it. This also means we'll be testing the
scsi pr manager and the bridge helper.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[groug, mention SHA1 that dropped libcap]
Signed-off-by: Greg Kurz <groug@kaod.org>
Libcap was dropped from virtio-9p (commit 7e46261368), so remove it from
the dockerfiles as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
[groug, mention SHA1 that dropped libcap]
Signed-off-by: Greg Kurz <groug@kaod.org>
- Fix a regression that broke bitmap deletion without a transaction,
and causes a crash with transaction (only transaction is new to 4.2),
when a qcow2 file contains persistent bitmaps from prior shutdown
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAl3uaBMACgkQp6FrSiUn
Q2rX+Af8Dn6cklzAizMLWCvXgEmbUhEvcVp5Gc9w34McCYokQaFDtNDuoShDIksa
F01uP3TlKYd8JoMiGihqVP1mcof8dyGBNMX1fVr2iYIet0h7OAtzOfatXiHmaz4g
r3utlx+0BHm+m9jhwsnCKp24ERa9izGmFQAIyaFLarGdasr29ArepCEXGXiOwtYF
RwD+ioolN9wDcOHjRrEVLHKKRkiX9dSnxKxENahf+M2hVXD+UfbX4cumYxBWOxJQ
qJpTznTA3BxRzUd3/Ue6NL0YmKmXLqHzyeX2Nc1NsdC485nCKn/QZtgI/8yAU0uL
6nseBGa1kgF4+97LwGmPKUmumcxGmQ==
=YAZ1
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-12-09' into staging
bitmap fix for 4.2-rc5
- Fix a regression that broke bitmap deletion without a transaction,
and causes a crash with transaction (only transaction is new to 4.2),
when a qcow2 file contains persistent bitmaps from prior shutdown
# gpg: Signature made Mon 09 Dec 2019 15:28:19 GMT
# gpg: using RSA key 71C2CC22B1C4602927D2F3AAA7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full]
# gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full]
# gpg: aka "[jpeg image of size 6874]" [full]
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* remotes/ericb/tags/pull-nbd-2019-12-09:
block/qcow2-bitmap: fix crash bug in qcow2_co_remove_persistent_dirty_bitmap
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Here is double bug:
First, return error but not set errp. This may lead to:
qmp block-dirty-bitmap-remove may report success when actually failed
block-dirty-bitmap-remove used in a transaction will crash, as
qmp_transaction will think that it returned success and will call
block_dirty_bitmap_remove_commit which will crash, as state->bitmap is
NULL
Second (like in anecdote), this case is not an error at all. As it is
documented in the comment above bdrv_co_remove_persistent_dirty_bitmap
definition, absence of bitmap is not an error, and similar case handled
at start of qcow2_co_remove_persistent_dirty_bitmap, it returns 0 when
there is no bitmaps at all.
But when there are some bitmaps, but not the requested one, it return
error with errp unset.
Fix that.
Trigger:
1. create persistent bitmap A
2. shutdown vm (bitmap A is synced)
3. start vm
4. create persistent bitmap B
5. remove bitmap B - it fails (and crashes if in transaction)
Potential workaround (rather invasive to ask clients to implement it):
1. create persistent bitmap A
2. shutdown vm
3. start vm
4. create persistent bitmap B
5. remember, that we want to remove bitmap B after vm shutdown
...
some other operations
...
6. vm shutdown
7. start vm in stopped mode, and remove all bitmaps marked for removing
8. stop vm
Fixes: b56a1e3175
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20191205193049.30666-1-vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
[eblake: commit message tweaks]
Signed-off-by: Eric Blake <eblake@redhat.com>
This is a last minute pull request for ppc-for-4.2. I know it's very
late in freeze, but this does fix a regression: a bad interaction
between the new qemu and SLOF device tree construction code means that
SLOF will crash if PCI to PCI bridges are included in the system.
This PR supersedes ppc-for-4.2-20191206. This one has only a more
minimal change to the firmware addressed only at fixing this bug and
not incorporating some other unrelated changes that happened in the
meantime.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAl3t0wMACgkQbDjKyiDZ
s5Jfsg//c8aRcQLJDYmdrMdmSh9t2rhXBG7lM+kRYa914HM9J3+Zk03NRJYmeEYn
NP05Vek0r6EE603dtHujcepfX5PiU5702fENv6aqSun24uionIVsN6NH8CElY93/
KcDY5xeNX9XOkZ2m6q+QRK8SxgSmB0fEgpQg2pcC3L5zCd7LQ4psaT/lCDY4Mvix
9l7WdrWKfY5GLZ1F54jX9Rulu4p8Bcy9jTkrddfyQK0/NMjuT3TsnJKt/CSGU0ar
CjTxxf8C2UTObXB2N6DPRruKQ2sB8Dwx6YXHY9k7pShRiFtBXAJBLOdawX/5MXXq
DYKl6hw0RNrzcGbyH4fgcIC7X/GoaAf+GSW3c0C6umHo+A63LTjnPvaPhM/Tzdw6
Z4UnWFZ+xVOuKBc1PAjTEzoQtnoxa8Rn9glnTKtgQ7N/GTwoTMmwLCA7zrbGOyk9
o1rx/87QpAob6idzZIxNWhNqQIFhKtAz9BjsCfpJIQDDPn2o+NbAQIU/QPKgN0LQ
rIpXDBM94jjhDkQ4S9HoqwI74AGQjzvUcT59bSsYpYD2UYZAjwAYEIj6gbOgpvJB
Hu1ujhl50gwgVGxYcfrxoJvURIsroaDNSYVyYVlnZBqIz83SE6LTyzas1GmDsgz5
GIGPMSr6aYKMTgRnDbHHs48bE1UGPybgnAek/tS5Ei3qoV5JJMs=
=ZWDP
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20191209' into staging
ppc patch queue 2019-12-09
This is a last minute pull request for ppc-for-4.2. I know it's very
late in freeze, but this does fix a regression: a bad interaction
between the new qemu and SLOF device tree construction code means that
SLOF will crash if PCI to PCI bridges are included in the system.
This PR supersedes ppc-for-4.2-20191206. This one has only a more
minimal change to the firmware addressed only at fixing this bug and
not incorporating some other unrelated changes that happened in the
meantime.
# gpg: Signature made Mon 09 Dec 2019 04:52:19 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.2-20191209:
pseries: Update SLOF firmware image
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
If kvm does not support VMX feature by nested=0, the kvm_vmx_basic
can't get the right value from MSR_IA32_VMX_BASIC register, which
make qemu coredump when qemu do KVM_SET_MSRS.
The coredump info:
error: failed to set MSR 0x480 to 0x0
kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Message-Id: <20191206071111.12128-1-yang.zhong@intel.com>
Reported-by: Catherine Ho <catherine.hecx@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Previous implementation in hvf_inject_interrupts() would always inject
VMCS_INTR_T_SWINTR even when VMCS_INTR_T_HWINTR was required. Now
correctly determine when VMCS_INTR_T_HWINTR is appropriate versus
VMCS_INTR_T_SWINTR.
Make sure to clear ins_len and has_error_code when ins_len isn't
valid and error_code isn't set.
Signed-off-by: Cameron Esfahani <dirty@apple.com>
Message-Id: <bf8d945ea1b423786d7802bbcf769517d1fd01f8.1575330463.git.dirty@apple.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
raw_aio_attach_aio_context() passes uninitialized Error *local_err by
reference to laio_init() via aio_setup_linux_aio(). When laio_init()
fails, it passes it on to error_setg_errno(), tripping error_setv()'s
assertion unless @local_err is null by dumb luck.
Fix by initializing @local_err properly.
Fixes: ed6e216171
Cc: Nishanth Aravamudan <naravamudan@digitalocean.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191130194240.10517-4-armbru@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Functions that take an Error ** parameter to pass an error to the
caller expect the parameter to point to null.
failover_replug_primary() violates this precondition in several
places:
* After qemu_opts_from_qdict() failed, *errp is no longer null.
Passing it to error_setg() is wrong, and will trip the assertion in
error_setv(). Messed up in commit 150ab54aa6 "net/virtio: fix
re-plugging of primary device". Simply drop the error_setg().
* Passing @errp to qemu_opt_set_bool(), hotplug_handler_pre_plug(),
and hotplug_handler_plug() is wrong. If one of the first two fails,
*errp is no longer null. Risks tripping the same assertion.
Moreover, continuing after such errors is unsafe. Messed up in
commit 9711cd0dfc "net/virtio: add failover support". Fix by
handling each error properly.
failover_replug_primary() crashes when passed a null @errp. Also
messed up in commit 9711cd0dfc. This bug can't bite as no caller
actually passes null. Fix it anyway.
Fixes: 9711cd0dfc
Fixes: 150ab54aa6
Cc: Jens Freimann <jfreimann@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191130194240.10517-3-armbru@redhat.com>
Reviewed-by: Jens Freimann <jfreimann@redhat.com>
virtio_net_handle_migration_primary() returns early when it can't
ensure n->primary_dev is non-null. Checking it again right after that
early return is redundant. Drop.
If n->primary_dev is null on entering failover_replug_primary(), @pdev
will become null, and pdev->partially_hotplugged will crash. Checking
n->primary_dev later is useless. It can't actually be null, because
its caller virtio_net_handle_migration_primary() ensures it isn't.
Drop the useless check.
Cc: Jens Freimann <jfreimann@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191130194240.10517-2-armbru@redhat.com>
Reviewed-by: Jens Freimann <jfreimann@redhat.com>
virtfs-proxy-helper is the only user of libcap; everyone else is using
the simpler libcap-ng API. Switch and remove the configure code to
detect libcap.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
[groug: - drop remaining -lcap from Makefile
- fix error message in configure]
Signed-off-by: Greg Kurz <groug@kaod.org>
It's broken so it's no longer helping. The latest Xcode is covered by
Cirrus.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20191127132430.3681-1-alex.bennee@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The existing s390 bios gets the LOADPARM information from the system using
an SCLP call that specifies a buffer length too small to contain all the
output.
The recent fixes in the SCLP code have exposed this bug, since now the
SCLP call will return an error (as per architecture) instead of
writing partially and completing successfully.
The solution is simply to specify the full page length as the SCCB
length instead of a smaller size.
Fixes: 832be0d8a3 ("s390x: sclp: Report insufficient SCCB length")
Fixes: 9a22473c70 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read Info")
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <1574944437-31182-1-git-send-email-imbrenda@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Janosch Frank
Cornelia Huck
Boris Fiuczynski
Eduardo Habkost
Cathy Zhang
Peter Maydell
Stefan Hajnoczi
Evgeny Yakovlev
Marc-André Lureau
Thomas Huth
Greg Kurz
Dr. David Alan Gilbert
Paolo Bonzini
Vladimir Sementsov-Ogievskiy
Alexey Kardashevskiy
Yang Zhong
Cameron Esfahani
Markus Armbruster
Alex Bennée
Claudio Imbrenda