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: 0ac24d56c5 ("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>
Version: GnuPG v1
iQEcBAABAgAGBQJd2/OwAAoJEO8Ells5jWIRE+AIAI428aJ1wov3CEOJHJEHeb9h
jS0N3TbPuBpqJILuDFyDtpQ7jPBejjaLccapgNQE2T69Iiqdt7yUSIV1rPHxLJrr
pramiG2QUufS584ZyMBF+ki4IhIr8IoNgxQuJeCJsm6+NJ82aWhAYhbt/a9SwcWz
d5nb9hR544CMuiWS43U3zmopnO7JF8vqYe7rEMrN6Jb+3KMHZ0yLFzs6+GajZubY
1SdzvhayvLnlEfAkCEgqsLg9OfnvdYvyOfYGtZg4GwUhYrZ7ysHKoaq9ZG0YBhFM
wgWgNHYfpY4cxvgxB6xYLYwDqoT+ePMikwB0bbtrQ00bYYKr3LL25+aXeouZsss=
=Oep6
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 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>
This fixes CID 1407222.
Fixes: 9711cd0dfc ("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: 9711cd0dfc ("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: 9711cd0dfc ("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: 9711cd0dfc ("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>
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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEicHnj2Ae6GyGdJXLoqP9bt6twN4FAl3T9KIACgkQoqP9bt6t
wN7sBA/9EXyDpqnHuVQ/BKqLxp47lTrcolD2tDC21Y7ITTqxgQ4jORqd0UFnV/JD
PgZkCn2slP4W45UW930K3nBBoibV/lwyH0FqW+Ilj0+ojFdhd/pLcObxoCjo4WUm
b+w1I/Iu1Dg6cGNZncfR3OUvTL1WrOSARXwGex4Bg1OdnlEwgqEQcem/QvY89IkK
fIsnzeNDGjJlJE50u/9wwZuGjgq71yD17nWGmqpEhrAMjI+/pNbOJPoJ9HQ6vedz
kWMx6gKFNXVB9G+SjAQf3xuaolFXtUHJb3gKYiVA3xrX6ypbUfuWqSYlUbenEGPL
ZAO2v6LKWopnv0f2pPUfs0N6YG/pDAdS6/ZlmOQzYIUQhyZr+cxkLgR6sG8ayVZP
KeQ18kbmhtpf4gJW0T575RNSCyv2Ns86XffVVdD7ExSoVleJApUUgYlL3NNDYTdS
1phED79HtvzK4+xf6EPZHixcKkWtjpdp4dCteKT7Wej+rFZbFsyur4ElpmL4WGJh
OwTwF2zY5QU++YEkM0o9KIovGYuAjh4frwmjuMstUNpsMUhujcIVOME4qbgyo/aV
Oxl4fgglPu4PgcW6l838sLwjIvqwItYKCuiwbxnsvWPxxYquPHcmCA9qyXpiLqnT
nMtFXxV9ClWGORnVvCcNypNoZ17IyDqMMj6XAfuC6+n8W/mr5UM=
=mVGc
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/mips-next-20191119' 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 369b41359a 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>
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
f0bb276bf8 ("hw/i386: split PCMachineState deriving X86MachineState from it")
and moving the save_tsc_khz field in PCMachineClass to X86MachineClass.
Fixes: f0bb276bf8 ("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: 4501d317b5 ("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: f045a0104c ("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: f045a0104c ("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>
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: cb79224b7e "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>
The boot.c code usually puts the CPU into NS mode directly when it is
booting a kernel. Since fc1120a7f5 this has included a
requirement to set NSACR to give NS state access to the FPU; we fixed
that for the usual code path in ece628fcf6. However, it is also
possible for a board model to request an alternative mode of booting,
where its 'board_setup' code hook runs in Secure state and is
responsible for doing the S->NS transition after it has done whatever
work it must do in Secure state. In this situation the board_setup
code now also needs to update NSACR.
This affects all boards which set info->secure_board_setup, which is
currently the 'raspi' and 'highbank' families. They both use the
common arm_write_secure_board_setup_dummy_smc().
Set the NSACR CP11 and CP10 bits in the code written by that
function, to allow FPU access in Non-Secure state when using dummy
SMC setup routine. Otherwise an AArch32 kernel booted on the
highbank or raspi boards will UNDEF as soon as it tries to use the
FPU.
Update the comment describing secure_board_setup to note the new
requirements on users of it.
This fixes a kernel panic when booting raspbian on raspi2.
Successfully tested with:
2017-01-11-raspbian-jessie-lite.img
2018-11-13-raspbian-stretch-lite.img
2019-07-10-raspbian-buster-lite.img
Fixes: fc1120a7f5
Signed-off-by: Clement Deschamps <clement.deschamps@greensocs.com>
Tested-by: Laurent Bonnans <laurent.bonnans@here.com>
Message-id: 20191104151137.81931-1-clement.deschamps@greensocs.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: updated comment to boot.h to note new requirement on
users of secure_board_setup; edited/rewrote commit message]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Now all the users of ptimers have converted to the transaction-based
API, we can remove ptimer_init_with_bh() and all the code paths
that are used only by bottom-half based ptimers, and tidy up the
documentation comments to consider the transaction-based API the
only possibility.
The code changes result from:
* s->bh no longer exists
* s->callback is now always non-NULL
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20191025142411.17085-1-peter.maydell@linaro.org
RXpkt.in_use is always 16 bit wide, but when the bus access mode is 32bit
and the endianness is big, we must access the second word and not the
first. This patch adjusts the offset according to the size and endianness.
This fixes DHCP for Q800 guest.
Fixes: be92084198 ("dp8393x: manage big endian bus")
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Tested-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20191106112341.23735-3-laurent@vivier.eu>
Move it from the stack.
It's only 24 bytes, and this simplifies the dp8393x_get()/
dp8393x_put() interface.
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20191106112341.23735-2-laurent@vivier.eu>
PIIX southbridge is also used by the Malta MIPS machine.
Split the PIIX3 southbridge from i440FX northbridge.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEicHnj2Ae6GyGdJXLoqP9bt6twN4FAl3B/CwACgkQoqP9bt6t
wN5frA/9FNpyolvQu5bEUAPsNv8wpWH/+XAxoHhdhAVZYPTMot6Iv2liwAav9GsU
9M4JK8qjcwvbN0yqkt6ZUjzhIZoXGnNVOEXVz/gUuk2EDr7EwXymsTwWDErIt0Ap
0IUEDfaISntxgf4vq7aPjXEk9644uZOn1MYuIm+oI8rEP6xj/fCj18TDQtGNlJRr
sgY5S9jbv+qxK402QB9B8gpXxcP2IO5WN6jAwgOsMOOqxALwAzPNqRbMEBsuGbwk
Aoj0jrC9h0Y8puAwl8DHbEOFAmf7YBskH2fyOjasUT1t7p1FreGNW7Esf7Oq34Ui
9G3CSUMN6rDVn0yVUd9qdv34imfa7eq9ci1gfzBYRg5VtQkC3vC2Tn5XrT7ZVABp
721KtCl701O+lSn3AyBcl9/lbBLdEaHDq/OPR/08vkmJBJ1hUP13KwvdFtYYwxPT
BCq6ZxTKNmPNNJCSEHYhkJ7J4lkPobipN8bNnAZB9xq58vjPXcmZmDKo0R1VanHN
JXLGw/ZM3wEaVEWi/P3qydo3Vshr1g/vr7ZB+xjgnfr+/bTfjWZ3UkMHvFW18HOP
n5VT2Hqnf9qZrBRaoDVy3dPCXDoXmBZx0urAKcP+J6/6UacvOS9G+e/cEFuNDGTe
SVqtALilkfAhuJBKUHw2gH3pb22fatDHYJ6hDMDHs3PvCcEGffg=
=cQ/y
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/mips-next-20191105' into staging
The i440FX northbridge is only used by the PC machine, while the
PIIX southbridge is also used by the Malta MIPS machine.
Split the PIIX3 southbridge from i440FX northbridge.
# gpg: Signature made Tue 05 Nov 2019 22:48:12 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-20191105: (21 commits)
hw/pci-host/i440fx: Remove the last PIIX3 traces
hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
hw/pci-host/piix: Fix code style issues
hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
hw/pci-host/piix: Move RCR_IOPORT register definition
hw/pci-host/piix: Extract piix3_create()
hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
hw/mips/mips_malta: Create IDE hard drive array dynamically
piix4: Add a MC146818 RTC Controller as specified in datasheet
piix4: Add an i8254 PIT Controller as specified in datasheet
piix4: Add an i8257 DMA Controller as specified in datasheet
piix4: Rename PIIX4 object to piix4-isa
Revert "irq: introduce qemu_irq_proxy()"
piix4: Add an i8259 Interrupt Controller as specified in datasheet
piix4: Add the Reset Control Register
MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit 65f14ab98d ("usb-host: skip reset for untouched devices")
filters out multiple usb device resets in a row. While this improves
the situation for usb some devices it doesn't work for others :-(
So go add a config option to make the behavior configurable.
Buglink: https://bugs.launchpad.net/bugs/1846451
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20191015064426.19454-1-kraxel@redhat.com
Host notifiers are used in several cases:
1. Traditional ioeventfd where virtqueue notifications are handled in
the main loop thread.
2. IOThreads (aio_handle_output) where virtqueue notifications are
handled in an IOThread AioContext.
3. vhost where virtqueue notifications are handled by kernel vhost or
a vhost-user device backend.
Most virtqueue notifications from the guest use the ioeventfd mechanism,
but there are corner cases where QEMU code calls virtio_queue_notify().
This currently honors the host notifier for the IOThreads
aio_handle_output case, but not for the vhost case. The result is that
vhost does not receive virtqueue notifications from QEMU when
virtio_queue_notify() is called.
This patch extends virtio_queue_notify() to set the host notifier
whenever it is enabled instead of calling the vq->(aio_)handle_output()
function directly. We track the host notifier state for each virtqueue
separately since some devices may use it only for certain virtqueues.
This fixes the vhost case although it does add a trip through the
eventfd for the traditional ioeventfd case. I don't think it's worth
adding a fast path for the traditional ioeventfd case because calling
virtio_queue_notify() is rare when ioeventfd is enabled.
Reported-by: Felipe Franciosi <felipe@nutanix.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20191105140946.165584-1-stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The virtual address that is provided by the guest in post_send and
post_recv operations is related to the guest address space. This address
space is unknown to the HCA resides on host so extra step in these
operations is needed to adjust the address to host virtual address.
This step, which is done in data-path affects performances.
An enhanced verion of MR registration introduced here
https://patchwork.kernel.org/patch/11044467/ can be used so that the
guest virtual address space for this MR is known to the HCA in host.
This will save the data-path adjustment.
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Message-Id: <20190818132107.18181-3-yuval.shaia@oracle.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
The PIIX3 is not tied to the i440FX and can even be used without it.
Move its creation to the machine code (pc_piix.c).
We have now removed the last trace of southbridge code in the i440FX
northbridge.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
We moved all the PIIX3 southbridge code out of hw/pci-host/piix.c,
it now only contains i440FX northbridge code.
Rename it to match the chipset modelled.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Move all the PIIX3 functions to a new file: hw/isa/piix3.c.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
We will move this code, fix its style first.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Esteban Bosse <estebanbosse@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The hw/pci-host/piix.c contains a mix of PIIX3 and i440FX chipsets
functions. To be able to split it, we need to export some
declarations first.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The IRQ Route Control registers definitions belong to the PIIX
chipset. We were only defining the 'A' register. Define the other
B, C and D registers, and use them.
Acked-by: Paul Durrant <paul@xen.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The RCR_IOPORT register belongs to the PIIX chipset.
Move the definition to "piix.h", and prepend the PIIX prefix.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Extract the PIIX3 creation code from the i440fx_init() function.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Esteban Bosse <estebanbosse@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
These devices implemented their load_state_old() handler 10 years
ago, previous to QEMU v0.12.
Since commit cc425b5ddf removed the pc-0.10 and pc-0.11 machines,
we can drop this code.
Note: the mips_r4k machine started to use the i8254 device just
after QEMU v0.5.0, but the MIPS machine types are not versioned,
so there is no migration compatibility issue removing this handler.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Now that we properly refactored the piix4_create() function, let's
move it to hw/isa/piix4.c where it belongs, so it can be reused
on other places.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The Malta board instantiate a PIIX4 chipset doing various
calls. Refactor all those related calls into a single
function: piix4_create().
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
In the next commit we'll refactor the PIIX4 code out of
mips_malta_init(). As a preliminary step, add the 'ide_drives'
variable and create the drive array dynamically.
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Remove mc146818rtc instanciated in malta board, to not have it twice.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20171216090228.28505-13-hpoussin@reactos.org>
[PMD: rebased, set RTC base_year to 2000]
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Remove i8254 instanciated in malta board, to not have it twice.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20171216090228.28505-10-hpoussin@reactos.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The i8257 is not a chipset on the Malta board, but is part of
the PIIX4 chipset.
Create the i8257 in the PIIX4 code, remove the one instantiated
in malta board, to not have it twice.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20171216090228.28505-9-hpoussin@reactos.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Esteban Bosse <estebanbosse@gmail.com>
[PMD: rebased, reworded description]
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Other piix4 parts are already named piix4-ide and piix4-usb-uhci.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20171216090228.28505-15-hpoussin@reactos.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Esteban Bosse <estebanbosse@gmail.com>
[PMD: rebased]
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This function isn't used anymore.
This reverts commit 22ec3283ef.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Esteban Bosse <estebanbosse@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Add ISA irqs as piix4 gpio in, and CPU interrupt request as piix4 gpio out.
Remove i8259 instanciated in malta board, to not have it twice.
We can also remove the now unused piix4_init() function.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20171216090228.28505-8-hpoussin@reactos.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
[PMD: rebased, updated includes, use ISA_NUM_IRQS in for loop]
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The RCR I/O port (0xcf9) is used to generate a hard reset or a soft reset.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <20171216090228.28505-7-hpoussin@reactos.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
[PMD: rebased, updated includes]
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEicHnj2Ae6GyGdJXLoqP9bt6twN4FAl2/Us4ACgkQoqP9bt6t
wN7dLhAAxlnmK9M7DeraiyCCVwgIzYL4sFssIAcIt5wbDg8p6od+hgeKcRwPKJbP
mg2a2Ehc1hoIJD3xUUVwJIkV12CONPnx+H3LEkJXY+w3ZqwbkNNJHy+5FBuC+h8P
1lTZDK6ulXkNR7OfeKys8Mzf6Ukf0TJsEuXHZWxC/e3I3rpf0+/FqP5QwHbi18Q2
4rCSy/59eaBiMBphlZHBncVOo1Kv1hKqpqSc9ddGj3uwyDpcjUThz4NEDhdXFE+r
0tKTPbv0f+z8CG9jAOgbmbFNFxwFb7D4uouwflFtNXleb5cdVGxQsAsJmYDvTmjP
3Qnvqiuw1BYRGpG1+54l0F82AThV1jlmlWVt/34PfwmGJRgMoTtDUJmW+SfjC3YT
MB+r78v4a6lavAxj780YIWVQzdvO4pG6fKKRbtMXNw4hyVxSWCBv1xC9ioKe1Xn1
LNI+rAY7ohYt/dN1aNipdFwk33NYHOOGDP2eU9GGL76tMrY5jK8i5KSqo1SNvxak
zpAJggMZXaG4BtGj7qCmMngQeC2yJwK1lou4P/S5A5OYDlHWjeszKBHa+hzQa/XH
3U8hEgRMjyeMzyyvh1OLDjWnxAMMeoPqb/hajmuZ1qM0oeBcKXbYtijNdAWIOK2q
AJeTeHWJ9WTkFvThwSSVDu6I6Snfhecvk96tKft0pr0rXYM6bsg=
=0aXg
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/fw_cfg-next-pull-request' into staging
Fix the fw_cfg reboot-timeout=-1 special value, add a test for it.
# gpg: Signature made Sun 03 Nov 2019 22:21:02 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/fw_cfg-next-pull-request:
tests/fw_cfg: Test 'reboot-timeout=-1' special value
fw_cfg: Allow reboot-timeout=-1 again
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Linux kernel 5.4 will introduce a new memory map for SWIM device.
(aee6bff1c325 ("m68k: mac: Revisit floppy disc controller base addresses"))
Until this release all MMIO are mapped between 0x50f00000 and 0x50f40000,
but it appears that for real hardware 0x50f00000 is not the base address:
the MMIO region spans 0x50000000 through 0x60000000, and 0x50040000 through
0x54000000 is repeated images of 0x50000000 to 0x50040000.
Fixed: 04e7ca8d0f ("hw/m68k: define Macintosh Quadra 800")
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20191104101513.29518-1-laurent@vivier.eu>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The Plug & Play region of the AHB/APB bridge can be accessed
by various word size, however the implementation is clearly
restricted to 32-bit:
static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
{
APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);
return apb_pnp->regs[offset >> 2];
}
Set the MemoryRegionOps::impl min/max fields to 32-bit, so
memory.c::access_with_adjusted_size() can adjust when the
access is not 32-bit.
This is required to run RTEMS on leon3, the grlib scanning
functions do byte accesses.
Reported-by: Jiri Gaisler <jiri@gaisler.se>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com>
Message-Id: <20191025110114.27091-3-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
PCIe requester IDs are used by modern IOMMUs to differentiate devices
in order to provide a unique IOVA address space per device. These
requester IDs are composed of the bus/device/function (BDF) of the
requesting device. Conventional PCI pre-dates this concept and is
simply a shared parallel bus where transactions are claimed by
decoding target ranges rather than the packetized, point-to-point
mechanisms of PCI-express. In order to interface conventional PCI
to PCIe, the PCIe-to-PCI bridge creates and accepts packetized
transactions on behalf of all downstream devices, using one of two
potential forms of a requester ID relating to the bridge itself or its
subordinate bus. All downstream devices are therefore aliased by the
bridge's requester ID and it's not possible for the IOMMU to create
unique IOVA spaces for devices downstream of such buses.
At least that's how it works on bare metal. Until now point we've
ignored this nuance of vIOMMU support in QEMU, creating a unique
AddressSpace per device regardless of the virtual bus topology.
Aside from simply being true to bare metal behavior, there are aspects
of a shared address space that we can use to our advantage when
designing a VM. For instance, a PCI device assignment scenario where
we have the following IOMMU group on the host system:
$ ls /sys/kernel/iommu_groups/1/devices/
0000:00:01.0 0000:01:00.0 0000:01:00.1
An IOMMU group is considered the smallest set of devices which are
fully DMA isolated from other devices by the IOMMU. In this case the
root port at 00:01.0 does not guarantee that it prevents peer to peer
traffic between the endpoints on bus 01: and the devices are therefore
grouped together. VFIO considers an IOMMU group to be the smallest
unit of device ownership and allows only a single shared IOVA space
per group due to the limitations of the isolation.
Therefore, if we attempt to create the following VM, we get an error:
qemu-system-x86_64 -machine q35... \
-device intel-iommu,intremap=on \
-device pcie-root-port,addr=1e.0,id=pcie.1 \
-device vfio-pci,host=1:00.0,bus=pcie.1,addr=0.0,multifunction=on \
-device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1
qemu-system-x86_64: -device vfio-pci,host=1:00.1,bus=pcie.1,addr=0.1: vfio \
0000:01:00.1: group 1 used in multiple address spaces
VFIO only allows a single IOVA space (AddressSpace) for both devices,
but we've placed them into a topology where the vIOMMU expects a
separate AddressSpace for each device. On bare metal we know that
a conventional PCI bus would provide the sort of aliasing we need
here, forcing the IOMMU to consider these devices to be part of a
single shared IOVA space. The support provided here does the same
for QEMU, such that we can create a conventional PCI topology to
expose equivalent AddressSpace sharing requirements to the VM:
qemu-system-x86_64 -machine q35... \
-device intel-iommu,intremap=on \
-device pcie-pci-bridge,addr=1e.0,id=pci.1 \
-device vfio-pci,host=1:00.0,bus=pci.1,addr=1.0,multifunction=on \
-device vfio-pci,host=1:00.1,bus=pci.1,addr=1.1
There are pros and cons to this configuration; it's not necessarily
recommended, it's simply a tool we can use to create configurations
which may provide additional functionality in spite of host hardware
limitations or as a benefit to the guest configuration or resource
usage. An incomplete list of pros and cons:
Cons:
a) Extended PCI configuration space is unavailable to devices
downstream of a conventional PCI bus. The degree to which this
is a drawback depends on the device and guest drivers.
b) Applying this topology to devices which are already isolated by
the host IOMMU (singleton IOMMU groups) will result in devices
which appear to be non-isolated to the VM (non-singleton groups).
This can limit configurations within the guest, such as userspace
drivers or nested device assignment.
Pros:
a) QEMU better emulates bare metal.
b) Configurations as above are now possible.
c) Host IOMMU resources and VM locked memory requirements are reduced
in vIOMMU configurations due to shared IOMMU domains on the host
and avoidance of duplicate locked memory accounting.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <157187083548.5439.14747141504058604843.stgit@gimli.home>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Rebuild hflags when modifying CPUState at boot.
Fixes: e979972a6a
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20191031040830.18800-2-edgar.iglesias@xilinx.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit ee5d0f89de added range checking on reboot-timeout
to only allow the range 0..65535; however both qemu and libvirt document
the special value -1 to mean don't reboot.
Allow it again.
Fixes: ee5d0f89de ("fw_cfg: Fix -boot reboot-timeout error checking")
RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20191025165706.177653-1-dgilbert@redhat.com>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <37ac197c-f20e-dd05-ff6a-13a2171c7148@redhat.com>
[PMD: Applied Laszlo's suggestions]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example 56 SPT (sectors per track).
No matter what QEMU will report - SeaBIOS, for large enough disks - will
use LBA translation, which will report 63 SPT instead.
In addition we cannot force SeaBIOS to rely on physical geometries at
all. A virtio-blk-pci virtual disk with 255 phyiscal heads cannot
report more than 16 physical heads when moved to an IDE controller,
since the ATA spec allows a maximum of 16 heads - this is an artifact of
virtualization.
By supplying the logical geometries directly we are able to support such
"exotic" disks.
We serialize this information in a similar way to the "bootorder"
interface.
The new fw_cfg entry is "bios-geometry".
Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com>
Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com>
Signed-off-by: Sam Eiderman <sameid@google.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Relevant devices are:
* ide-hd (and ide-cd, ide-drive)
* scsi-hd (and scsi-cd, scsi-disk, scsi-block)
* virtio-blk-pci
We do not call del_boot_device_lchs() for ide-* since we don't need to -
IDE block devices do not support unplugging.
Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com>
Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com>
Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com>
Signed-off-by: Sam Eiderman <sameid@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
We will need to add LCHS removal logic to scsi-hd's unrealize() in the
next commit.
Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com>
Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com>
Signed-off-by: Sam Eiderman <sameid@google.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Fixing tabbing in block related macros.
Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com>
Signed-off-by: Sam Eiderman <sameid@google.com>
Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com>
Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
It's an old compatibility shim that just delegates to ide-cd or ide-hd.
I'd like to refactor these some day, and getting rid of the super-object
will make that easier.
Either way, we don't need this.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
Message-id: 20191009224303.10232-2-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
- use --enable-plugins @ configure
- low impact introspection (-plugin empty.so to measure overhead)
- plugins cannot alter guest state
- example plugins included in source tree (tests/plugins)
- -d plugin to enable plugin output in logs
- check-tcg runs extra tests when plugins enabled
- documentation in docs/devel/plugins.rst
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAl23BZMACgkQ+9DbCVqe
KkRPegf/QHygZ4ER2jOaWEookxiOEcik+dzQKVGNqLNXeMLvo5fGjGVpFoFxSgfv
ZvCAL4xbW44zsYlVfh59tfn4Tu9qK7s7/qM3WXpHsmuvEuhoWef0Lt2jSe+D46Rs
KeG/aX+rHLUR8rr9eCgE+1/MQmxPUj3VUonkUpNkk2ebBbSNoLSOudB4DD9Vcyl7
Pya1kPvA6W9bwI20ZSWihE7flg13o62Pp+LgAFLrsfxXOxOMkPrU8Pp+B0Dvr+hL
5Oh0clZLhiRi75x+KVGZ90TVsoftdjYoOWGMOudS/+NNmqKT1NTLm0K1WJYyRMQ1
V0ne4/OcGNq7x8gcOx/xs09ADu5/VA==
=UXR/
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging
TCG Plugins initial implementation
- use --enable-plugins @ configure
- low impact introspection (-plugin empty.so to measure overhead)
- plugins cannot alter guest state
- example plugins included in source tree (tests/plugins)
- -d plugin to enable plugin output in logs
- check-tcg runs extra tests when plugins enabled
- documentation in docs/devel/plugins.rst
# gpg: Signature made Mon 28 Oct 2019 15:13:23 GMT
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* remotes/stsquad/tags/pull-tcg-plugins-281019-4: (57 commits)
travis.yml: enable linux-gcc-debug-tcg cache
MAINTAINERS: add me for the TCG plugins code
scripts/checkpatch.pl: don't complain about (foo, /* empty */)
.travis.yml: add --enable-plugins tests
include/exec: wrap cpu_ldst.h in CONFIG_TCG
accel/stubs: reduce headers from tcg-stub
tests/plugin: add hotpages to analyse memory access patterns
tests/plugin: add instruction execution breakdown
tests/plugin: add a hotblocks plugin
tests/tcg: enable plugin testing
tests/tcg: drop test-i386-fprem from TESTS when not SLOW
tests/tcg: move "virtual" tests to EXTRA_TESTS
tests/tcg: set QEMU_OPTS for all cris runs
tests/tcg/Makefile.target: fix path to config-host.mak
tests/plugin: add sample plugins
linux-user: support -plugin option
vl: support -plugin option
plugin: add qemu_plugin_outs helper
plugin: add qemu_plugin_insn_disas helper
plugin: expand the plugin_init function to include an info block
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use RCU_READ_LOCK_GUARD and WITH_RCU_READ_LOCK_GUARD
to replace the manual rcu_read_(un)lock calls.
I think the only change is virtio_load which was missing unlocks
in error paths; those end up being fatal errors so it's not
that important anyway.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20191028161109.60205-1-dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Use RCU_READ_LOCK_GUARD rather than the manual rcu_read_(un)lock call.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20191025103403.120616-3-dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Use RCU_READ_LOCK_GUARD instead of manual rcu_read_(un)lock
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20191025103403.120616-2-dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
As usual block all vfio-pci devices from being migrated, but make an
exception for failover primary devices. This is achieved by setting
unmigratable to 0 but also add a migration blocker for all vfio-pci
devices except failover primary devices. These will be unplugged before
migration happens by the migration handler of the corresponding
virtio-net standby device.
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <20191029114905.6856-12-jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch adds support to handle failover device pairs of a virtio-net
device and a (vfio-)pci device, where the virtio-net acts as the standby
device and the (vfio-)pci device as the primary.
The general idea is that we have a pair of devices, a (vfio-)pci and a
emulated (virtio-net) device. Before migration the vfio device is
unplugged and data flows to the emulated device, on the target side
another (vfio-)pci device is plugged in to take over the data-path. In the
guest the net_failover module will pair net devices with the same MAC
address.
To achieve this we need:
1. Provide a callback function for the should_be_hidden DeviceListener.
It is called when the primary device is plugged in. Evaluate the QOpt
passed in to check if it is the matching primary device. It returns
if the device should be hidden or not.
When it should be hidden it stores the device options in the VirtioNet
struct and the device is added once the VIRTIO_NET_F_STANDBY feature is
negotiated during virtio feature negotiation.
If the virtio-net devices are not realized at the time the (vfio-)pci
devices are realized, we need to connect the devices later. This way
we make sure primary and standby devices can be specified in any
order.
2. Register a callback for migration status notifier. When called it
will unplug its primary device before the migration happens.
3. Register a callback for the migration code that checks if a device
needs to be unplugged from the guest.
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191029114905.6856-11-jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
In "b06424de62 migration: Disable hotplug/unplug during migration" we
added a check to disable unplug for all devices until we have figured
out what works. For failover primary devices qdev_unplug() is called
from the migration handler, i.e. during migration.
This patch adds a flag to DeviceState which is set to false for all
devices and makes an exception for PCI devices that are also
primary devices in a failover pair.
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191029114905.6856-8-jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Set pending_deleted_event in DeviceState for failover
primary devices that were successfully unplugged by the Guest OS.
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191029114905.6856-5-jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Only the guest unplug request was triggered. This is needed for
the failover feature. In case of a failed migration we need to
plug the device back to the guest.
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191029114905.6856-4-jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch adds a failover_pair_id property to PCIDev which is
used to link the primary device in a failover pair (the PCI dev) to
a standby (a virtio-net-pci) device.
It only supports ethernet devices. Also currently it only supports
PCIe devices. The requirement for PCIe is because it doesn't support
other hotplug controllers at the moment. The failover functionality can
be added to other hotplug controllers like ACPI, SHCP,... later on.
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191029114905.6856-3-jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This adds support for hiding a device to the qbus and qdev APIs. The
first user of this will be the virtio-net failover feature but the API
introduced with this patch could be used to implement other features as
well, for example hiding pci devices when a pci bus is powered off.
qdev_device_add() is modified to check for a failover_pair_id
argument in the option string. A DeviceListener callback
should_be_hidden() is added. It can be used by a standby device to
inform qdev that this device should not be added now. The standby device
handler can store the device options to plug the device in at a later
point in time.
One reason for hiding the device is that we don't want to expose both
devices to the guest kernel until the respective virtio feature bit
VIRTIO_NET_F_STANDBY was negotiated and we know that the devices will be
handled correctly by the guest.
More information on the kernel feature this is using:
https://www.kernel.org/doc/html/latest/networking/net_failover.html
An example where the primary device is a vfio-pci device and the standby
device is a virtio-net device:
A device is hidden when it has an "failover_pair_id" option, e.g.
-device virtio-net-pci,...,failover=on,...
-device vfio-pci,...,failover_pair_id=net1,...
Signed-off-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191029114905.6856-2-jfreimann@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Version: GnuPG v1
iQEcBAABAgAGBQJdt6UAAAoJEO8Ells5jWIRdaAH/3+dufJuFijZY44VYbob92ud
lZR1dYah1fBL1bq0F2siFUb+/wgF1IXHJl9tuUJe8Kp0+hnsXji2s4Iuq5lNQoJj
wwMGziL1TPkhxwgy4jObIC+/bqZVrzAO4Cd+PARrSGAAbAqjxLPizOaf72/t4kdn
C2n87ZlR5k0EOPmUY6Y2DtHtrJ20usSS6EThGhdW7iPSzfQSGiOdRzfZrSiEV2XT
cuKbSzQxk7pbPcz4jIgLzaoA7FIXwm99dBosUkjPszNNFbO4+OPDNdUBanYuqmn/
0ZPe/9YZpEMV64ps/Ab7lx7YB04wZ+A9Etln2JULhBWXg/oyri9gsqgOc6bfCXg=
=uE5S
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging
# gpg: Signature made Tue 29 Oct 2019 02:33:36 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:
COLO-compare: Fix incorrect `if` logic
virtio-net: prevent offloads reset on migration
virtio: new post_load hook
net: add tulip (dec21143) driver
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Currently offloads disabled by guest via the VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
command are not preserved on VM migration.
Instead all offloads reported by guest features (via VIRTIO_PCI_GUEST_FEATURES)
get enabled.
What happens is: first the VirtIONet::curr_guest_offloads gets restored and offloads
are getting set correctly:
#0 qemu_set_offload (nc=0x555556a11400, csum=1, tso4=0, tso6=0, ecn=0, ufo=0) at net/net.c:474
#1 virtio_net_apply_guest_offloads (n=0x555557701ca0) at hw/net/virtio-net.c:720
#2 virtio_net_post_load_device (opaque=0x555557701ca0, version_id=11) at hw/net/virtio-net.c:2334
#3 vmstate_load_state (f=0x5555569dc010, vmsd=0x555556577c80 <vmstate_virtio_net_device>, opaque=0x555557701ca0, version_id=11)
at migration/vmstate.c:168
#4 virtio_load (vdev=0x555557701ca0, f=0x5555569dc010, version_id=11) at hw/virtio/virtio.c:2197
#5 virtio_device_get (f=0x5555569dc010, opaque=0x555557701ca0, size=0, field=0x55555668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
#6 vmstate_load_state (f=0x5555569dc010, vmsd=0x555556577ce0 <vmstate_virtio_net>, opaque=0x555557701ca0, version_id=11) at migration/vmstate.c:143
#7 vmstate_load (f=0x5555569dc010, se=0x5555578189e0) at migration/savevm.c:829
#8 qemu_loadvm_section_start_full (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2211
#9 qemu_loadvm_state_main (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2395
#10 qemu_loadvm_state (f=0x5555569dc010) at migration/savevm.c:2467
#11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
However later on the features are getting restored, and offloads get reset to
everything supported by features:
#0 qemu_set_offload (nc=0x555556a11400, csum=1, tso4=1, tso6=1, ecn=0, ufo=0) at net/net.c:474
#1 virtio_net_apply_guest_offloads (n=0x555557701ca0) at hw/net/virtio-net.c:720
#2 virtio_net_set_features (vdev=0x555557701ca0, features=5104441767) at hw/net/virtio-net.c:773
#3 virtio_set_features_nocheck (vdev=0x555557701ca0, val=5104441767) at hw/virtio/virtio.c:2052
#4 virtio_load (vdev=0x555557701ca0, f=0x5555569dc010, version_id=11) at hw/virtio/virtio.c:2220
#5 virtio_device_get (f=0x5555569dc010, opaque=0x555557701ca0, size=0, field=0x55555668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
#6 vmstate_load_state (f=0x5555569dc010, vmsd=0x555556577ce0 <vmstate_virtio_net>, opaque=0x555557701ca0, version_id=11) at migration/vmstate.c:143
#7 vmstate_load (f=0x5555569dc010, se=0x5555578189e0) at migration/savevm.c:829
#8 qemu_loadvm_section_start_full (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2211
#9 qemu_loadvm_state_main (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2395
#10 qemu_loadvm_state (f=0x5555569dc010) at migration/savevm.c:2467
#11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
Fix this by preserving the state in saved_guest_offloads field and
pushing out offload initialization to the new post load hook.
Cc: qemu-stable@nongnu.org
Signed-off-by: Mikhail Sennikovsky <mikhail.sennikovskii@cloud.ionos.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Post load hook in virtio vmsd is called early while device is processed,
and when VirtIODevice core isn't fully initialized. Most device
specific code isn't ready to deal with a device in such state, and
behaves weirdly.
Add a new post_load hook in a device class instead. Devices should use
this unless they specifically want to verify the migration stream as
it's processed, e.g. for bounds checking.
Cc: qemu-stable@nongnu.org
Suggested-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Mikhail Sennikovsky <mikhail.sennikovskii@cloud.ionos.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
David Gibson
Zhuang, Siwei (Data61, Kensington NSW)
Palmer Dabbelt
Peter Maydell
Jens Freimann
Qi, Yadong
Marc-André Lureau
Dan Schatzberg
Sai Pavan Boddu
Philippe Mathieu-Daudé
Linus Ziegert
Alexander Graf
Paolo Bonzini
Liam Merwick
Thomas Huth
Sergio Lopez
Michal Privoznik
Laurent Vivier
Alexey Kardashevskiy
Greg Kurz
Alistair Francis
Clement Deschamps
Gerd Hoffmann
Stefan Hajnoczi
Yuval Shaia
Philippe Mathieu-Daudé
Hervé Poussineau
Alex Williamson
Edgar E. Iglesias
Dr. David Alan Gilbert
Sam Eiderman
John Snow
Mikhail Sennikovsky
Michael S. Tsirkin