Age | Commit message (Collapse) | Author |
|
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: 9711cd0dfc3fa414f7f64935713c07134ae67971
Fixes: 150ab54aa6934583180f88a2bd540bc6fc4fbff3
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>
|
|
'remotes/pmaydell/tags/pull-target-arm-20191126' into staging
target-arm queue:
* handle FTYPE flag correctly in v7M exception return
for v7M CPUs with an FPU (v8M CPUs were already correct)
* versal: Add the CRP as unimplemented
* Fix ISR_EL1 tracking when executing at EL2
* Honor HCR_EL2.TID3 trapping requirements
# gpg: Signature made Tue 26 Nov 2019 14:11:50 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-20191126:
target/arm: Honor HCR_EL2.TID3 trapping requirements
target/arm: Fix ISR_EL1 tracking when executing at EL2
hw/arm: versal: Add the CRP as unimplemented
target/arm: Fix handling of cortex-m FTYPE flag in EXCRET
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
into staging
ppc patch queue for 2019-11-26
Here's the first 4.2 hard freeze pull request from me. This has:
* A fix for some testcases that cause errors on older host kernels
(e.g. RHEL7), with our new default configuration of VSMT mode
* Changes to make VFIO devices interact properly with change of irq
chip caused by PAPR feature negotiation. This is more involved
than I would like, but it's a problem in real use cases and I
can't see an easier way to handle it.
* Fix an error with ms6522 counters for the g3beige machine
* Fix a coverity warning
# gpg: Signature made Tue 26 Nov 2019 05:52:16 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-20191126:
ppc/spapr_events: fix potential NULL pointer dereference in rtas_event_log_dequeue
mos6522: update counters when timer interrupts are off
spapr: Work around spurious warnings from vfio INTx initialization
spapr: Handle irq backend changes with VFIO PCI devices
vfio/pci: Respond to KVM irqchip change notifier
vfio/pci: Split vfio_intx_update()
kvm: Introduce KVM irqchip change notifier
pseries: fix migration-test and pxe-test
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
Add the CRP as unimplemented thus avoiding bus errors when
guests access these registers.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20191115154734.26449-2-edgar.iglesias@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
into staging
RISC-V Patches for 4.2-rc3
This tag contains two patches that I'd like to target for 4.2-rc3:
* A fix to the DT entry for the SiFive test finisher.
* A fix to the spike board's HTIF interface.
This passes "make check" and boots OE for me.
# gpg: Signature made Mon 25 Nov 2019 20:51:13 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.2-rc3:
hw/riscv: Add optional symbol callback ptr to riscv_load_kernel()
RISC-V: virt: This is a "sifive,test1" test finisher
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
rtas_event_log_dequeue
This fixes coverity issues 68911917:
360
CID 68911917: (NULL_RETURNS)
361. dereference: Dereferencing "source", which is known to be
"NULL".
361 if (source->mask & event_mask) {
362 break;
363 }
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
Message-Id: <1574685291-38176-1-git-send-email-pannengyuan@huawei.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
|
Even if the interrupts are off, counters must be updated because
they are running anyway and kernel can try to read them
(it's the case with g3beige kernel).
Reported-by: Andrew Randrianasulu <randrianasulu@gmail.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20191125141414.5015-1-laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
|
Traditional PCI INTx for vfio devices can only perform well if using
an in-kernel irqchip. Therefore, vfio_intx_update() issues a warning
if an in kernel irqchip is not available.
We usually do have an in-kernel irqchip available for pseries machines
on POWER hosts. However, because the platform allows feature
negotiation of what interrupt controller model to use, we don't
currently initialize it until machine reset. vfio_intx_update() is
called (first) from vfio_realize() before that, so it can issue a
spurious warning, even if we will have an in kernel irqchip by the
time we need it.
To workaround this, make a call to spapr_irq_update_active_intc() from
spapr_irq_init() which is called at machine realize time, before the
vfio realize. This call will be pretty much obsoleted by the later
call at reset time, but it serves to suppress the spurious warning
from VFIO.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
|
|
pseries machine type can have one of two different interrupt controllers in
use depending on feature negotiation with the guest. Usually this is
invisible to devices, because they route to a common set of qemu_irqs which
in turn dispatch to the correct back end.
VFIO passthrough devices, however, wire themselves up directly to the KVM
irqchip for performance, which means they are affected by this change in
interrupt controller. To get them to adjust correctly for the change in
irqchip, we need to fire the kvm irqchip change notifier.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
|
|
VFIO PCI devices already respond to the pci intx routing notifier, in order
to update kernel irqchip mappings when routing is updated. However this
won't handle the case where the irqchip itself is replaced by a different
model while retaining the same routing. This case can happen on
the pseries machine type due to PAPR feature negotiation.
To handle that case, add a handler for the irqchip change notifier, which
does much the same thing as the routing notifier, but is unconditional,
rather than being a no-op when the routing hasn't changed.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
|
|
This splits the vfio_intx_update() function into one part doing the actual
reconnection with the KVM irqchip (vfio_intx_update(), now taking an
argument with the new routing) and vfio_intx_routing_notifier() which
handles calls to the pci device intx routing notifier and calling
vfio_intx_update() when necessary. This will make adding support for the
irqchip change notifier easier.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
|
|
This patch adds an optional function pointer, "sym_cb", to
riscv_load_kernel() which provides the possibility to access the symbol
table during kernel loading.
The pointer is ignored, if supplied with Image or uImage file.
The Spike board requires the access to locate the HTIF symbols.
Fixes: 0ac24d56c5e7 ("hw/riscv: Split out the boot functions")
Buglink: https://bugs.launchpad.net/qemu/+bug/1835827
Signed-off-by: Siwei Zhuang <siwei.zhuang@data61.csiro.au>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
|
|
The test finisher implements the reset command, which means it's a
"sifive,test1" device. This is a backwards compatible change, so it's
also a "sifive,test0" device. I copied the odd idiom for adding a
two-string compatible field from the ARM virt board.
Fixes: 9a2551ed6f ("riscv: sifive_test: Add reset functionality")
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
|
|
staging
# gpg: Signature made Mon 25 Nov 2019 15:30:56 GMT
# gpg: using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211
* remotes/jasowang/tags/net-pull-request:
net/virtio: return error when device_opts arg is NULL
net/virtio: fix re-plugging of primary device
net/virtio: return early when failover primary alread added
net/virtio: fix dev_unplug_pending
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
virtio, pc: fixes
More small bugfixes.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Mon 25 Nov 2019 08:43:07 GMT
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# 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:
intel_iommu: TM field should not be in reserved bits
intel_iommu: refine SL-PEs reserved fields checking
virtio-input: fix memory leak on unrealize
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
This fixes CID 1407222.
Fixes: 9711cd0dfc3f ("net/virtio: add failover support")
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
|
|
failover_replug_primary was returning true on failure which lead to
re-plug not working when a migration failed. Fix this by returning
success when hotplug worked. This is a bug that was missed in last
round of testing but was tested succesfully with this version. Also
make sure we don't pass NULL to qdev_set_parent_bus().
This fixes CID 1407224.
Fixes: 9711cd0dfc3f ("net/virtio: add failover support")
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
|
|
Bail out when primary device was already added before.
This avoids printing a wrong warning message during reboot.
Fixes: 9711cd0dfc3f ("net/virtio: add failover support")
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
|
|
.dev_unplug_pending is set up by virtio-net code indepent of failover
support was set for the device or not. This gives a wrong result when
we check for existing primary devices in migration code.
Fix this by actually calling dev_unplug_pending() instead of just
checking if the function pointer was set. When the feature was not
negotiated dev_unplug_pending() will always return false. This prevents
us from going into the wait-unplug state when there's no primary device
present.
Fixes: 9711cd0dfc3f ("net/virtio: add failover support")
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
|
|
When dt is supported, TM field should not be Reserved(0).
Refer to VT-d Spec 9.8
Signed-off-by: Zhang, Qi <qi1.zhang@intel.com>
Signed-off-by: Qi, Yadong <yadong.qi@intel.com>
Message-Id: <20191125003321.5669-3-yadong.qi@intel.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>
|
|
1. split the resevred fields arrays into two ones,
2. large page only effect for L2(2M) and L3(1G), so
remove checking of L1 and L4 for large page.
Signed-off-by: Zhang, Qi <qi1.zhang@intel.com>
Signed-off-by: Qi, Yadong <yadong.qi@intel.com>
Message-Id: <20191125003321.5669-2-yadong.qi@intel.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>
|
|
Spotted by ASAN + minor stylistic change.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20191121095649.25453-1-marcandre.lureau@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
|
|
Some filesystems may return 0s in statfs (trivially, a FUSE filesystem
can do so). QEMU should handle this gracefully and just behave the
same as if statfs failed.
Signed-off-by: Dan Schatzberg <dschatzberg@fb.com>
Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
|
|
Fill the audio channel with required number of bytes to cover the
elapsed time. This prevents rate control reset, and avoids debug prints
like below
log:
Resetting rate control (65692 samples)
...
Resetting rate control (65721 samples)
...
Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 1573833408-2388-1-git-send-email-sai.pavan.boddu@xilinx.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
* microvm docs and fixes (Sergio, Liam)
* New processor features for Intel errata (myself, Pawan)
* Kconfig fixes (myself, Thomas)
* Revert mc146818rtc change (myself)
* Deprecate scsi-disk (myself)
* RTC fix (myself, Marcelo)
# gpg: Signature made Tue 19 Nov 2019 09:03:49 GMT
# gpg: using RSA key BFFBD25F78C7AE83
# 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:
mc146818rtc: fix timer interrupt reinjection again
Revert "mc146818rtc: fix timer interrupt reinjection"
scsi: deprecate scsi-disk
hw/i386: Move save_tsc_khz from PCMachineClass to X86MachineClass
docs/microvm.rst: add instructions for shutting down the guest
docs/microvm.rst: fix alignment in "Limitations"
vfio: vfio-pci requires EDID
hw/i386: Fix compiler warning when CONFIG_IDE_ISA is disabled
target/i386: Export TAA_NO bit to guests
target/i386: add PSCHANGE_NO bit for the ARCH_CAPABILITIES MSR
microvm: fix memory leak in microvm_fix_kernel_cmdline
scripts: Detect git worktrees for get_maintainer.pl --git
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
into staging
The DTrace via SystemTap backend can not support the dynamic '*' width
format. We failed at noticing it for the 4.1 release, and LP#1844817
was opened to track it. Fix this regression for the next release.
# gpg: Signature made Tue 19 Nov 2019 13:56:50 GMT
# gpg: using RSA key 89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (Phil) <philmd@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 89C1 E78F 601E E86C 8674 95CB A2A3 FD6E DEAD C0DE
* remotes/philmd-gitlab/tags/mips-next-20191119:
hw/mips/gt64xxx: Remove dynamic field width from trace events
hw/block/pflash: Remove dynamic field width from trace events
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.
We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
need this anymore. Instead, display the size of bytes accessed.
Fixes: ab6bff424f ("gt64xxx_pci: Convert debug printf to trace events")
Reported-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Buglink: https://bugs.launchpad.net/qemu/+bug/1844817
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
|
|
Since not all trace backends support dynamic field width in
format (dtrace via stap does not), replace by a static field
width instead.
We previously passed to the trace API 'width << 1' as the number
of hex characters to display (the dynamic field width). We don't
need this anymore. Instead, display the size of bytes accessed.
Fixes: e8aa2d95ea ("pflash: Simplify trace_pflash_io_read/write")
Fixes: c1474acd5d ("pflash: Simplify trace_pflash_data_read/write")
Reported-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Buglink: https://bugs.launchpad.net/qemu/+bug/1844817
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
|
|
The Linux kernel PHY driver sets AN_RESTART in the BMCR of the
PHY when autonegotiation is started.
Recently the kernel started to read back the PHY's AN_RESTART
bit and now checks whether the autonegotiation is complete and
the bit was cleared [1]. Otherwise the link status is down.
The emulated PHY needs to clear AN_RESTART immediately to inform
the kernel driver about the completion of autonegotiation phase.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c36757eb9dee
Signed-off-by: Linus Ziegert <linus.ziegert+qemu@holoplot.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20191104181604.21943-1-linus.ziegert+qemu@holoplot.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
A few configuration register writes need not update the spi bus state, so just
return after the register write.
Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Tested-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Message-id: 1573830705-14579-1-git-send-email-sai.pavan.boddu@xilinx.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
The current PL031 RTCICR register implementation always clears the
IRQ pending status on a register write, regardless of the value the
guest writes.
To justify that behavior, it references the ARM926EJ-S Development
Chip Reference Manual (DDI0287B) and indicates that said document
states that any write clears the internal IRQ state. It is indeed
true that in section 11.1 this document says:
"The interrupt is cleared by writing any data value to the
interrupt clear register RTCICR".
However, later in section 11.2.2 it contradicts itself by saying:
"Writing 1 to bit 0 of RTCICR clears the RTCINTR flag."
The latter statement matches the PL031 TRM (DDI0224C), which says:
"Writing 1 to bit position 0 clears the corresponding interrupt.
Writing 0 has no effect."
Let's assume that the self-contradictory DDI0287B is in error, and
follow the reference manual for the device itself, by making the
register write-one-to-clear.
Reported-by: Hendrik Borghorst <hborghor@amazon.de>
Signed-off-by: Alexander Graf <graf@amazon.com>
Message-id: 20191104115228.30745-1-graf@amazon.com
[PMM: updated commit message to note that DDI0287B says two
conflicting things]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
Commit 369b41359af46bded5799c9ef8be2b641d92e043 broke timer interrupt
reinjection when there is no period change by the guest. In that
case, old_period is 0, which ends up zeroing irq_coalesced (counter of
reinjected interrupts).
The consequence is Windows 7 is unable to synchronize time via NTP.
Easily reproducible by playing a fullscreen video with cirrus and VNC.
Fix by passing s->period when periodic_timer_update is called due to
expiration of the timer. With this change, old_period == 0 only
means that the periodic timer was off.
Reported-by: Marcelo Tosatti <mtosatti@redhat.com>
Co-developed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts commit b429de730174b388ea5760e3debb0d542ea3c261, except
that the reversal of the outer "if (period)" is left in.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
It's an old compatibility shim that just delegates to scsi-cd or scsi-hd.
Just like ide-drive, we don't need this.
Acked-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Attempting to migrate a VM using the microvm machine class results in the source
QEMU aborting with the following message/backtrace:
target/i386/machine.c:955:tsc_khz_needed: Object 0x555556608fa0 is not an
instance of type generic-pc-machine
abort()
object_class_dynamic_cast_assert()
vmstate_save_state_v()
vmstate_save_state()
vmstate_save()
qemu_savevm_state_complete_precopy()
migration_thread()
migration_thread()
migration_thread()
qemu_thread_start()
start_thread()
clone()
The access to the machine class returned by MACHINE_GET_CLASS() in
tsc_khz_needed() is crashing as it is trying to dereference a different
type of machine class object (TYPE_PC_MACHINE) to that of this microVM.
This can be resolved by extending the changes in the following commit
f0bb276bf8d5 ("hw/i386: split PCMachineState deriving X86MachineState from it")
and moving the save_tsc_khz field in PCMachineClass to X86MachineClass.
Fixes: f0bb276bf8d5 ("hw/i386: split PCMachineState deriving X86MachineState from it")
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Message-Id: <1574075605-25215-1-git-send-email-liam.merwick@oracle.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
hw/vfio/display.c needs the EDID subsystem, select it.
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
When CONFIG_IDE_ISA is disabled, compilation currently fails:
hw/i386/pc_piix.c: In function ‘pc_init1’:
hw/i386/pc_piix.c:81:9: error: unused variable ‘i’ [-Werror=unused-variable]
Move the variable declaration to the right code block to avoid
this problem.
Fixes: 4501d317b50e ("hw/i386/pc: Extract pc_i8259_create()")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20191115145049.26868-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
In microvm_fix_kernel_cmdline(), fw_cfg_modify_string() is duplicating
cmdline instead of taking ownership of it. Free it afterwards to avoid
leaking it.
Reported-by: Coverity (CID 1407218)
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Sergio Lopez <slp@redhat.com>
Message-Id: <20191112163423.91884-1-slp@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
hw/vfio/display.c needs the EDID subsystem, select it.
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
When an error occurs in migrate_add_blocker() it sets a
negative return value and uses error pointer we pass in.
Instead of just looking at the error pointer check for a negative return
value and avoid a coverity error because the return value is
set but never used. This fixes CID 1407219.
Reported-by: Coverity (CID 1407219)
Fixes: f045a0104c8c ("vfio: unplug failover primary device before migration")
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
When user tries to hotplug a VFIO device, but the operation fails
somewhere in the middle (in my testing it failed because of
RLIMIT_MEMLOCK forbidding more memory allocation), then a double
free occurs. In vfio_realize() the vdev->migration_blocker is
allocated, then something goes wrong which causes control to jump
onto 'error' label where the error is freed. But the pointer is
left pointing to invalid memory. Later, when
vfio_instance_finalize() is called, the memory is freed again.
In my testing the second hunk was sufficient to fix the bug, but
I figured the first hunk doesn't hurt either.
==169952== Invalid read of size 8
==169952== at 0xA47DCD: error_free (error.c:266)
==169952== by 0x4E0A18: vfio_instance_finalize (pci.c:3040)
==169952== by 0x8DF74C: object_deinit (object.c:606)
==169952== by 0x8DF7BE: object_finalize (object.c:620)
==169952== by 0x8E0757: object_unref (object.c:1074)
==169952== by 0x45079C: memory_region_unref (memory.c:1779)
==169952== by 0x45376B: do_address_space_destroy (memory.c:2793)
==169952== by 0xA5C600: call_rcu_thread (rcu.c:283)
==169952== by 0xA427CB: qemu_thread_start (qemu-thread-posix.c:519)
==169952== by 0x80A8457: start_thread (in /lib64/libpthread-2.29.so)
==169952== by 0x81C96EE: clone (in /lib64/libc-2.29.so)
==169952== Address 0x143137e0 is 0 bytes inside a block of size 48 free'd
==169952== at 0x4A342BB: free (vg_replace_malloc.c:530)
==169952== by 0xA47E05: error_free (error.c:270)
==169952== by 0x4E0945: vfio_realize (pci.c:3025)
==169952== by 0x76A4FF: pci_qdev_realize (pci.c:2099)
==169952== by 0x689B9A: device_set_realized (qdev.c:876)
==169952== by 0x8E2C80: property_set_bool (object.c:2080)
==169952== by 0x8E0EF6: object_property_set (object.c:1272)
==169952== by 0x8E3FC8: object_property_set_qobject (qom-qobject.c:26)
==169952== by 0x8E11DB: object_property_set_bool (object.c:1338)
==169952== by 0x5E7BDD: qdev_device_add (qdev-monitor.c:673)
==169952== by 0x5E81E5: qmp_device_add (qdev-monitor.c:798)
==169952== by 0x9E18A8: do_qmp_dispatch (qmp-dispatch.c:132)
==169952== Block was alloc'd at
==169952== at 0x4A35476: calloc (vg_replace_malloc.c:752)
==169952== by 0x51B1158: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.6)
==169952== by 0xA47357: error_setv (error.c:61)
==169952== by 0xA475D9: error_setg_internal (error.c:97)
==169952== by 0x4DF8C2: vfio_realize (pci.c:2737)
==169952== by 0x76A4FF: pci_qdev_realize (pci.c:2099)
==169952== by 0x689B9A: device_set_realized (qdev.c:876)
==169952== by 0x8E2C80: property_set_bool (object.c:2080)
==169952== by 0x8E0EF6: object_property_set (object.c:1272)
==169952== by 0x8E3FC8: object_property_set_qobject (qom-qobject.c:26)
==169952== by 0x8E11DB: object_property_set_bool (object.c:1338)
==169952== by 0x5E7BDD: qdev_device_add (qdev-monitor.c:673)
Fixes: f045a0104c8c ("vfio: unplug failover primary device before migration")
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
into staging
ppc patch queue 2019-11-15
Several fixes for 4.2.0-rc2:
fix mos6522 performance issue,
xive/xics issues,
fix /chosen device-tree on reset
and KVM default cpu-model for all machine classes
# gpg: Signature made Mon 18 Nov 2019 10:52:19 GMT
# gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
# gpg: issuer "lvivier@redhat.com"
# gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full]
# gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full]
# gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full]
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C
* remotes/vivier2/tags/ppc-for-4.2-pull-request:
mos6522: fix T1 and T2 timers
spapr/kvm: Set default cpu model for all machine classes
spapr: Add /chosen to FDT only at reset time to preserve kernel and initramdisk
ppc: Skip partially initialized vCPUs in 'info pic'
xive, xics: Fix reference counting on CPU objects
ppc: Add intc_destroy() handlers to SpaprInterruptController/PnvChip
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
With the Quadra 800 emulation, mos6522 timers processing can consume
until 70% of the host CPU time with an idle guest (I guess the problem
should also happen with PowerMac emulation).
On a recent system, it can be painless (except if you look at top), but
on an old host like a PowerMac G5 the guest kernel can be terribly slow
during the boot sequence (for instance, unpacking initramfs can take 15
seconds rather than only 3 seconds).
We can avoid this CPU overload by enabling QEMU internal timers only if
the mos6522 counter interrupts are enabled. Sometime the guest kernel
wants to read the counters values, but we don't need the timers to
update the counters.
With this patch applied, an idle Q800 consumes only 3% of host CPU time
(and the guest can boot in a decent time).
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20191102154919.17775-1-laurent@vivier.eu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
|
|
Since "spapr: Render full FDT on ibm,client-architecture-support" we build
the entire flatten device tree (FDT) twice - at the reset time and
when "ibm,client-architecture-support" (CAS) is called. The full FDT from
CAS is then applied on top of the SLOF internal device tree.
This is mostly ok, however there is a case when the QEMU is started with
-initrd and for some reason the guest decided to move/unpack the init RAM
disk image - the guest correctly notifies SLOF about the change but
at CAS it is overridden with the QEMU initial location addresses and
the guest may fail to boot if the original initrd memory was changed.
This fixes the problem by only adding the /chosen node at the reset time
to prevent the original QEMU's linux,initrd-start/linux,initrd-end to
override the updated addresses.
This only treats /chosen differently as we know there is a special case
already and it is unlikely anything else will need to change /chosen at CAS
we are better off not touching /chosen after we handed it over to SLOF.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Message-Id: <20191024041308.5673-1-aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
|
|
CPU_FOREACH() can race with vCPU hotplug/unplug on sPAPR machines, ie.
we may try to print out info about a vCPU with a NULL presenter pointer.
Check that in order to prevent QEMU from crashing.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <157192725327.3146912.12047076483178652551.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
|
|
When a VCPU gets connected to the XIVE interrupt controller, we add a
const link targetting the CPU object to the TCTX object. Similar links
are added to the ICP object when using the XICS interrupt controller.
As explained in <qom/object.h>:
* The caller must ensure that @target stays alive as long as
* this property exists. In the case @target is a child of @obj,
* this will be the case. Otherwise, the caller is responsible for
* taking a reference.
We're in the latter case for both XICS and XIVE. Add the missing
calls to object_ref() and object_unref().
This doesn't fix any known issue because the life cycle of the TCTX or
ICP happens to be shorter than the one of the CPU or XICS fabric, but
better safe than sorry.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <157192724770.3146912.15400869269097231255.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
|
|
SpaprInterruptControllerClass and PnvChipClass have an intc_create() method
that calls the appropriate routine, ie. icp_create() or xive_tctx_create(),
to establish the link between the VCPU and the presenter component of the
interrupt controller during realize.
There aren't any symmetrical call to be called when the VCPU gets unrealized
though. It is assumed that object_unparent() is the only thing to do.
This is questionable because the parenting logic around the CPU and
presenter objects is really an implementation detail of the interrupt
controller. It shouldn't be open-coded in the machine code.
Fix this by adding an intc_destroy() method that undoes what was done in
intc_create(). Also NULLify the presenter pointers to avoid having
stale pointers around. This will allow to reliably check if a vCPU has
a valid presenter.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <157192724208.3146912.7254684777515287626.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
|
|
Coreboot developers have requested that they have at least 32MB of flash
to load binaries. We currently have 32MB of flash, but it is split in
two to allow loading two flash binaries. Let's increase the flash size
from 32MB to 64MB to ensure we have a single region that is 32MB.
No QEMU release has include flash in the RISC-V virt machine, so this
isn't a breaking change.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
|
|
If memory allocation fails when using -mem-path, QEMU is supposed to print
out a message to indicate that fallback to anonymous RAM is deprecated. This
is done with error_printf() which does output buffering. As a consequence,
the message is only printed at the next flush, eg. when quiting QEMU, and
it also lacks a trailing newline:
qemu-system-ppc64: unable to map backing store for guest RAM: Cannot allocate memory
qemu-system-ppc64: warning: falling back to regular RAM allocation
QEMU 4.1.50 monitor - type 'help' for more information
(qemu) q
This is deprecated. Make sure that -mem-path specified path has sufficient resources to allocate -m specified RAM amountgreg@boss02:~/Work/qemu/qemu-spapr$
Add the missing \n to fix both issues.
Fixes: cb79224b7e4b "deprecate -mem-path fallback to anonymous RAM"
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <157304440026.351774.14607704217028190097.stgit@bahia.lan>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
|