OSDN Git Service

qmiga/qemu.git
19 months agohw/input/ps2.c: Convert TYPE_PS2_{KBD, MOUSE}_DEVICE to 3-phase reset
Peter Maydell [Wed, 9 Nov 2022 17:00:09 +0000 (17:00 +0000)]
hw/input/ps2.c: Convert TYPE_PS2_{KBD, MOUSE}_DEVICE to 3-phase reset

Convert the child classes TYPE_PS2_KBD_DEVICE and
TYPE_PS2_MOUSE_DEVICE to the 3-phase reset system.  This allows us to
stop using the old device_class_set_parent_reset() function.

We don't need to register an 'exit' phase function for the
subclasses, because they have no work to do in that phase.  Passing
NULL to resettable_class_set_parent_phases() will result in the
parent class method being called for that phase, so we don't need to
register a function purely to chain to the parent 'exit' phase
function.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221109170009.3498451-3-peter.maydell@linaro.org

19 months agohw/input/ps2: Convert TYPE_PS2_DEVICE to 3-phase reset
Peter Maydell [Wed, 9 Nov 2022 17:00:08 +0000 (17:00 +0000)]
hw/input/ps2: Convert TYPE_PS2_DEVICE to 3-phase reset

Convert the parent class TYPE_PS2_DEVICE to 3-phase reset.  Note that
we need an 'exit' phase function as well as the usual 'hold' phase
function, because changing outbound IRQ line state is only permitted
in 'exit'.  (Strictly speaking it's not supposed to be done in a
legacy reset handler either, but you can often get away with it.)

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20221109170009.3498451-2-peter.maydell@linaro.org

19 months agohw: Remove device_legacy_reset()
Peter Maydell [Fri, 16 Dec 2022 15:55:28 +0000 (15:55 +0000)]
hw: Remove device_legacy_reset()

The device_legacy_reset() function is now not used anywhere, so we
can remove the implementation.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agoqdev: Remove qdev_reset_all() and qbus_reset_all()
Peter Maydell [Fri, 16 Dec 2022 15:55:27 +0000 (15:55 +0000)]
qdev: Remove qdev_reset_all() and qbus_reset_all()

Remove the qdev_reset_all() and qbus_reset_all() functions, now we
have moved all the callers over to the new device_cold_reset() and
bus_cold_reset() functions.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agoReplace use of qdev_reset_all() with device_cold_reset()
Peter Maydell [Fri, 16 Dec 2022 15:55:27 +0000 (15:55 +0000)]
Replace use of qdev_reset_all() with device_cold_reset()

The legacy function qdev_reset_all() performs a recursive reset,
starting from a qdev.  However, it does not permit any of the devices
in the tree to use three-phase reset, because device reset goes
through the device_legacy_reset() function that only calls the single
DeviceClass::reset method.

Switch to using the device_cold_reset() function instead.  This also
performs a recursive reset, where first the children are reset and
then finally the parent, but it uses the new (...in 2020...)
Resettable mechanism, which supports both the old style single-reset
method and also the new 3-phase reset handling.

This commit changes the five remaining uses of this function.

Commit created with:
 sed -i -e 's/qdev_reset_all/device_cold_reset/g' hw/i386/xen/xen_platform.c hw/input/adb.c hw/remote/vfio-user-obj.c hw/s390x/s390-virtio-ccw.c hw/usb/dev-uas.c

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/hyperv/vmbus: Use device_cold_reset() and bus_cold_reset()
Peter Maydell [Fri, 16 Dec 2022 15:55:26 +0000 (15:55 +0000)]
hw/hyperv/vmbus: Use device_cold_reset() and bus_cold_reset()

In the vmbus code we currently use the legacy functions
qdev_reset_all() and qbus_reset_all().  These perform a recursive
reset, starting from either a qbus or a qdev.  However they do not
permit any of the devices in the tree to use three-phase reset,
because device reset goes through the device_legacy_reset() function
that only calls the single DeviceClass::reset method.

Switch to using the device_cold_reset() and bus_cold_reset()
functions.  These also perform a recursive reset, where first the
children are reset and then finally the parent, but they use the new
(...in 2020...) Resettable mechanism, which supports both the old
style single-reset method and also the new 3-phase reset handling.

This should be a no-behaviour-change commit which just reduces the
use of a deprecated API.

Commit created with:
  sed -i -e 's/qdev_reset_all/device_cold_reset/g;s/qbus_reset_all/bus_cold_reset/g' hw/hyperv/*.c

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agopci: Use device_cold_reset() and bus_cold_reset()
Peter Maydell [Fri, 16 Dec 2022 15:55:26 +0000 (15:55 +0000)]
pci: Use device_cold_reset() and bus_cold_reset()

In the PCI subsystem we currently use the legacy function
qdev_reset_all() and qbus_reset_all().  These perform a recursive
reset, starting from either a qbus or a qdev.  However they do not
permit any of the devices in the tree to use three-phase reset,
because device reset goes through the device_legacy_reset() function
that only calls the single DeviceClass::reset method.

Switch to using the device_cold_reset() and bus_cold_reset()
functions.  These also perform a recursive reset, where first the
children are reset and then finally the parent, but they use the new
(...in 2020...) Resettable mechanism, which supports both the old
style single-reset method and also the new 3-phase reset handling.

This should be a no-behaviour-change commit which just reduces the
use of a deprecated API.

Commit created with:
 sed -i -e 's/qdev_reset_all/device_cold_reset/g;s/qbus_reset_all/bus_cold_reset/g' hw/pci/*.c

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/s390x/s390-pci-inst.c: Use device_cold_reset() to reset PCI devices
Peter Maydell [Fri, 16 Dec 2022 15:55:24 +0000 (15:55 +0000)]
hw/s390x/s390-pci-inst.c: Use device_cold_reset() to reset PCI devices

The semantic difference between the deprecated device_legacy_reset()
function and the newer device_cold_reset() function is that the new
function resets both the device itself and any qbuses it owns,
whereas the legacy function resets just the device itself and nothing
else.

In s390-pci-inst.c we use device_legacy_reset() to reset an
S390PCIBusDevice.  This device doesn't have any child qbuses, so the
functions do the same thing and we can stop using the deprecated one.

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agoMerge tag 'pull-request-2022-12-15' of https://gitlab.com/thuth/qemu into staging
Peter Maydell [Thu, 15 Dec 2022 21:39:56 +0000 (21:39 +0000)]
Merge tag 'pull-request-2022-12-15' of https://gitlab.com/thuth/qemu into staging

* s390x PCI fixes and improvements (for the ISM device)
* Fix emulated MVCP and MVCS s390x instructions
* Clean-ups for the e1000e qtest
* Enable qtests on Windows
* Update FreeBSD CI to version 12.4
* Check --disable-tcg for ppc64 in the CI
* Improve scripts/make-releases a little bit
* Many other misc small clean-ups and fixes here and there

# gpg: Signature made Thu 15 Dec 2022 15:05:44 GMT
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg:                 aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg:                 aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg:                 aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2022-12-15' of https://gitlab.com/thuth/qemu: (23 commits)
  tests/qtest/vhost-user-blk-test: don't abort all qtests on missing envar
  .gitlab/issue_templates: Move suggestions into comments
  gitlab-ci: Check building ppc64 without TCG
  FreeBSD: Upgrade to 12.4 release
  tests/qtest: Enable qtest build on Windows
  .gitlab-ci.d/windows.yml: Exclude qTests from 64-bit CI job for now
  .gitlab-ci.d/windows.yml: Keep 64-bit and 32-bit build scripts consistent
  .gitlab-ci.d/windows.yml: Unify the prerequisite packages
  tests/qtest/libqos/e1000e: Correctly group register accesses
  tests/qtest/e1000e-test: De-duplicate constants
  tests/qtest/libqos/e1000e: Remove "other" interrupts
  hw: Include the VMWare devices only in the x86 targets
  MAINTAINERS: Add documentation files to the corresponding sections
  util/oslib-win32: Remove obsolete reference to g_poll code
  util/qemu-config: Fix "query-command-line-options" to provide the right values
  scripts/make-release: Only clone single branches to speed up the script
  scripts/make-release: Add a simple help text for the script
  monitor/misc: Remove superfluous include statements
  target/s390x: The MVCP and MVCS instructions are not privileged
  target/s390x/tcg/mem_helper: Test the right bits in psw_key_valid()
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agoMerge tag 'pull-target-arm-20221215-1' of https://git.linaro.org/people/pmaydell...
Peter Maydell [Thu, 15 Dec 2022 17:40:57 +0000 (17:40 +0000)]
Merge tag 'pull-target-arm-20221215-1' of https://git.linaro.org/people/pmaydell/qemu-arm into staging

target-arm queue:
 * hw/arm/virt: Add properties to allow more granular
   configuration of use of highmem space
 * target/arm: Add Cortex-A55 CPU
 * hw/intc/arm_gicv3: Fix GICD_TYPER ITLinesNumber advertisement
 * Implement FEAT_EVT
 * Some 3-phase-reset conversions for Arm GIC, SMMU
 * hw/arm/boot: set initrd with #address-cells type in fdt
 * hw/misc: Move some arm-related files from specific_ss into softmmu_ss
 * Restrict arm_cpu_exec_interrupt() to TCG accelerator

# gpg: Signature made Thu 15 Dec 2022 17:38:36 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]
# gpg:                 aka "Peter Maydell <peter@archaic.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* tag 'pull-target-arm-20221215-1' of https://git.linaro.org/people/pmaydell/qemu-arm: (28 commits)
  target/arm: Restrict arm_cpu_exec_interrupt() to TCG accelerator
  hw/misc: Move some arm-related files from specific_ss into softmmu_ss
  hw/arm/boot: set initrd with #address-cells type in fdt
  hw/intc: Convert TYPE_KVM_ARM_ITS to 3-phase reset
  hw/intc: Convert TYPE_ARM_GICV3_ITS to 3-phase reset
  hw/intc: Convert TYPE_ARM_GICV3_ITS_COMMON to 3-phase reset
  hw/intc: Convert TYPE_KVM_ARM_GICV3 to 3-phase reset
  hw/intc: Convert TYPE_ARM_GICV3_COMMON to 3-phase reset
  hw/intc: Convert TYPE_ARM_GIC_KVM to 3-phase reset
  hw/intc: Convert TYPE_ARM_GIC_COMMON to 3-phase reset
  hw/arm: Convert TYPE_ARM_SMMUV3 to 3-phase reset
  hw/arm: Convert TYPE_ARM_SMMU to 3-phase reset
  target/arm: Report FEAT_EVT for TCG '-cpu max'
  target/arm: Implement HCR_EL2.TID4 traps
  target/arm: Implement HCR_EL2.TICAB,TOCU traps
  target/arm: Implement HCR_EL2.TTLBOS traps
  target/arm: Implement HCR_EL2.TTLBIS traps
  target/arm: Allow relevant HCR bits to be written for FEAT_EVT
  hw/intc/arm_gicv3: Fix GICD_TYPER ITLinesNumber advertisement
  target/arm: Add Cortex-A55 CPU
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agotarget/arm: Restrict arm_cpu_exec_interrupt() to TCG accelerator
Philippe Mathieu-Daudé [Wed, 14 Dec 2022 14:27:14 +0000 (14:27 +0000)]
target/arm: Restrict arm_cpu_exec_interrupt() to TCG accelerator

When building with --disable-tcg on Darwin we get:

  target/arm/cpu.c:725:16: error: incomplete definition of type 'struct TCGCPUOps'
    cc->tcg_ops->do_interrupt(cs);
    ~~~~~~~~~~~^

Commit 083afd18a9 ("target/arm: Restrict cpu_exec_interrupt()
handler to sysemu") limited this block to system emulation,
but neglected to also limit it to TCG.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-id: 20221209110823.59495-1-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/misc: Move some arm-related files from specific_ss into softmmu_ss
Thomas Huth [Wed, 14 Dec 2022 14:27:14 +0000 (14:27 +0000)]
hw/misc: Move some arm-related files from specific_ss into softmmu_ss

The header target/arm/kvm-consts.h checks CONFIG_KVM which is marked as
poisoned in common code, so the files that include this header have to
be added to specific_ss and recompiled for each, qemu-system-arm and
qemu-system-aarch64. However, since the kvm headers are only optionally
used in kvm-constants.h for some sanity checks, we can additionally
check the NEED_CPU_H macro first to avoid the poisoned CONFIG_KVM macro,
so kvm-constants.h can also be used from "common" files (without the
sanity checks - which should be OK since they are still done from other
target-specific files instead). This way, and by adjusting some other
include statements in the related files here and there, we can move some
files from specific_ss into softmmu_ss, so that they only need to be
compiled once during the build process.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221202154023.293614-1-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agoMerge tag 'next-8.0-pull-request' of https://gitlab.com/juan.quintela/qemu into staging
Peter Maydell [Thu, 15 Dec 2022 14:52:12 +0000 (14:52 +0000)]
Merge tag 'next-8.0-pull-request' of https://gitlab.com/juan.quintela/qemu into staging

Migration patches for 8.0

Hi

This are the patches that I had to drop form the last PULL request because they werent fixes:
- AVX2 is dropped, intel posted a fix, I have to redo it
- Fix for out of order channels is out
  Daniel nacked it and I need to redo it

# gpg: Signature made Thu 15 Dec 2022 09:38:29 GMT
# gpg:                using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723
# gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full]
# gpg:                 aka "Juan Quintela <quintela@trasno.org>" [full]
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03  4B82 F487 EF18 5872 D723

* tag 'next-8.0-pull-request' of https://gitlab.com/juan.quintela/qemu:
  migration: Drop rs->f
  migration: Remove old preempt code around state maintainance
  migration: Send requested page directly in rp-return thread
  migration: Move last_sent_block into PageSearchStatus
  migration: Make PageSearchStatus part of RAMState
  migration: Add pss_init()
  migration: Introduce pss_channel
  migration: Teach PSS about host page
  migration: Use atomic ops properly for page accountings
  migration: Yield bitmap_mutex properly when sending/sleeping
  migration: Remove RAMState.f references in compression code
  migration: Trivial cleanup save_page_header() on same block check
  migration: Cleanup xbzrle zero page cache update logic
  migration: Add postcopy_preempt_active()
  migration: Take bitmap mutex when completing ram migration
  migration: Export ram_release_page()
  migration: Export ram_transferred_ram()
  multifd: Create page_count fields into both MultiFD{Recv,Send}Params
  multifd: Create page_size fields into both MultiFD{Recv,Send}Params

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agotests/qtest/vhost-user-blk-test: don't abort all qtests on missing envar
Christian Schoenebeck [Fri, 25 Nov 2022 15:58:53 +0000 (16:58 +0100)]
tests/qtest/vhost-user-blk-test: don't abort all qtests on missing envar

This test requires environment variable QTEST_QEMU_STORAGE_DAEMON_BINARY
to be defined for running. If not, it would immediately abort all qtests
and prevent other, unrelated tests from running.

To fix that, just skip vhost-user-blk-test instead and log a message
about missing environment variable.

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <E1oybRD-0005D5-5r@lizzy.crudebyte.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months ago.gitlab/issue_templates: Move suggestions into comments
Thomas Huth [Thu, 1 Dec 2022 13:37:56 +0000 (14:37 +0100)]
.gitlab/issue_templates: Move suggestions into comments

Many users forget to remove the suggestions from the bug template
when creating a new issue. So when searching for strings like "s390x"
or "Windows", you get a lot of unrelated issues in the results.
Thus let's move the suggestions into HTML comments - so they will
still show up in the markdown when editing the bug, while being
hidden/ignored in the final text or in the search queries.

Message-Id: <20221201133756.77216-1-thuth@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agogitlab-ci: Check building ppc64 without TCG
Thomas Huth [Thu, 8 Dec 2022 10:15:27 +0000 (11:15 +0100)]
gitlab-ci: Check building ppc64 without TCG

Building QEMU for ppc64 hosts with --disable-tcg used to break a couple
of times in the past, see e.g. commit a01b64cee7 ("target/ppc: Put do_rfi
under a TCG-only block") or commit 049b4ad669 ("target/ppc: Fix build
warnings when building with 'disable-tcg'"), so we should test this in
our CI to avoid such regressions.

Message-Id: <20221208101527.36873-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agoFreeBSD: Upgrade to 12.4 release
Brad Smith [Thu, 8 Dec 2022 06:52:21 +0000 (01:52 -0500)]
FreeBSD: Upgrade to 12.4 release

Upgrade to 12.4 release

Signed-off-by: Brad Smith <brad@comstyle.com>
Message-Id: <Y5GJpW/1s+NEah98@humpty.home.comstyle.com>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed by: Warner Losh <imp@bsdimp.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agotests/qtest: Enable qtest build on Windows
Bin Meng [Fri, 25 Nov 2022 11:41:00 +0000 (19:41 +0800)]
tests/qtest: Enable qtest build on Windows

Now that we have fixed various test case issues as seen when running
on Windows, let's enable the qtest build on Windows.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20221125114100.3184790-4-bmeng.cn@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months ago.gitlab-ci.d/windows.yml: Exclude qTests from 64-bit CI job for now
Bin Meng [Fri, 25 Nov 2022 11:40:59 +0000 (19:40 +0800)]
.gitlab-ci.d/windows.yml: Exclude qTests from 64-bit CI job for now

qTests don't run successfully with "--without-default-devices",
so let's exclude the qtests from CI for now.

Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20221125114100.3184790-3-bmeng.cn@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months ago.gitlab-ci.d/windows.yml: Keep 64-bit and 32-bit build scripts consistent
Bin Meng [Fri, 25 Nov 2022 11:40:58 +0000 (19:40 +0800)]
.gitlab-ci.d/windows.yml: Keep 64-bit and 32-bit build scripts consistent

At present the build scripts of 32-bit and 64-bit are inconsistent.
Let's keep them consistent for easier maintenance.

While we are here, add some comments to explain that for the 64-bit
job, "--without-default-devices" is a must have, at least for now.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20221125114100.3184790-2-bmeng.cn@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months ago.gitlab-ci.d/windows.yml: Unify the prerequisite packages
Bin Meng [Fri, 25 Nov 2022 11:40:57 +0000 (19:40 +0800)]
.gitlab-ci.d/windows.yml: Unify the prerequisite packages

At present the prerequisite packages for 64-bit and 32-bit builds
are slightly different. Let's use the same packages for both for
easier maintenance in the future.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Message-Id: <20221125114100.3184790-1-bmeng.cn@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agotests/qtest/libqos/e1000e: Correctly group register accesses
Akihiko Odaki [Thu, 10 Nov 2022 11:45:49 +0000 (20:45 +0900)]
tests/qtest/libqos/e1000e: Correctly group register accesses

Add a newline after E1000_TCTL write and make it clear that E1000_TCTL
write is what enabling transmit.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20221110114549.66081-1-akihiko.odaki@daynix.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agotests/qtest/e1000e-test: De-duplicate constants
Akihiko Odaki [Thu, 10 Nov 2022 11:44:26 +0000 (20:44 +0900)]
tests/qtest/e1000e-test: De-duplicate constants

De-duplicate constants found in e1000e_send_verify() and
e1000e_receive_verify() to avoid mismatch and improve readability.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20221110114426.65951-1-akihiko.odaki@daynix.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agotests/qtest/libqos/e1000e: Remove "other" interrupts
Akihiko Odaki [Thu, 10 Nov 2022 11:40:45 +0000 (20:40 +0900)]
tests/qtest/libqos/e1000e: Remove "other" interrupts

The "other" kind of interrupts are not used in the tests.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20221110114045.65544-1-akihiko.odaki@daynix.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agohw: Include the VMWare devices only in the x86 targets
Thomas Huth [Tue, 13 Dec 2022 09:46:54 +0000 (10:46 +0100)]
hw: Include the VMWare devices only in the x86 targets

It seems a little bit weird that the para-virtualized x86 VMWare
devices "vmware-svga" and "vmxnet3" also show up in non-x86 targets.
They are likely pretty useless there (since the guest OSes likely
do not have any drivers for those enabled), so let's change this and
only enable those devices by default for the classical x86 targets.

Message-Id: <20221213095144.42355-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agoMAINTAINERS: Add documentation files to the corresponding sections
Thomas Huth [Mon, 12 Dec 2022 17:48:41 +0000 (18:48 +0100)]
MAINTAINERS: Add documentation files to the corresponding sections

A lot of files in the docs directory do not have a maintainer according to
our MAINTAINERS file, though they can be clearly associated with one of the
sections in there. Add the files now so that our scripts/get_maintainer.pl
script can output the right maintainer for them.

Message-Id: <20221212174841.201003-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agoutil/oslib-win32: Remove obsolete reference to g_poll code
Thomas Huth [Thu, 8 Dec 2022 13:32:57 +0000 (14:32 +0100)]
util/oslib-win32: Remove obsolete reference to g_poll code

The comment about g_poll is not required here anymore since
the corresponding code has been removed a while ago already.

Fixes: b4c6036faa ("configure: bump min required glib version to 2.56")
Message-Id: <20221208133257.95673-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agoutil/qemu-config: Fix "query-command-line-options" to provide the right values
Thomas Huth [Fri, 11 Nov 2022 14:13:23 +0000 (15:13 +0100)]
util/qemu-config: Fix "query-command-line-options" to provide the right values

The "query-command-line-options" command uses a hand-crafted list
of options that should be returned for the "machine" parameter.
This is pretty much out of sync with reality, for example settings
like "kvm_shadow_mem" or "accel" are not parameters for the machine
anymore. Also, there is no distinction between the targets here, so
e.g. the s390x-specific values like "loadparm" in this list also
show up with the other targets like x86_64.

Let's fix this now by geting rid of the hand-crafted list and by
querying the properties of the machine classes instead to assemble
the list.

Fixes: 0a7cf217d8 ("fix regression of qmp_query_command_line_options")
Message-Id: <20221111141323.246267-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agoscripts/make-release: Only clone single branches to speed up the script
Thomas Huth [Mon, 28 Nov 2022 09:25:52 +0000 (10:25 +0100)]
scripts/make-release: Only clone single branches to speed up the script

Using --single-branch and --depth 1 here helps to speed up the process
a little bit and helps to save some networking bandwidth.

Message-Id: <20221128092555.37102-3-thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agoscripts/make-release: Add a simple help text for the script
Thomas Huth [Mon, 28 Nov 2022 09:25:51 +0000 (10:25 +0100)]
scripts/make-release: Add a simple help text for the script

Print a simple help text if the script has been called with the
wrong amount of parameters.

Message-Id: <20221128092555.37102-2-thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agomonitor/misc: Remove superfluous include statements
Thomas Huth [Mon, 28 Nov 2022 13:35:14 +0000 (14:35 +0100)]
monitor/misc: Remove superfluous include statements

These #includes are not required anymore (the likely got superfluous
with commit da76ee76f7 - "hmp-commands-info: move info_cmds content
out of monitor.c").

Message-Id: <20221128133514.220919-1-thuth@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agotarget/s390x: The MVCP and MVCS instructions are not privileged
Thomas Huth [Mon, 5 Dec 2022 12:58:52 +0000 (13:58 +0100)]
target/s390x: The MVCP and MVCS instructions are not privileged

The "MOVE TO PRIMARY/SECONDARY" instructions can also be called
from problem state. We just should properly check whether the
secondary-space access key is valid here, too, and inject a
privileged program exception if it is invalid.

Message-Id: <20221205125852.81848-1-thuth@redhat.com>
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agotarget/s390x/tcg/mem_helper: Test the right bits in psw_key_valid()
Thomas Huth [Mon, 5 Dec 2022 14:20:43 +0000 (15:20 +0100)]
target/s390x/tcg/mem_helper: Test the right bits in psw_key_valid()

The PSW key mask is a 16 bit field, and the psw_key variable is
in the range from 0 to 15, so it does not make sense to use
"0x80 >> psw_key" for testing the bits here. We should use 0x8000
instead.

Message-Id: <20221205142043.95185-1-thuth@redhat.com>
Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agos390x/pci: reset ISM passthrough devices on shutdown and system reset
Matthew Rosato [Fri, 9 Dec 2022 19:57:00 +0000 (14:57 -0500)]
s390x/pci: reset ISM passthrough devices on shutdown and system reset

ISM device firmware stores unique state information that can
can cause a wholesale unmap of the associated IOMMU (e.g. when
we get a termination signal for QEMU) to trigger firmware errors
because firmware believes we are attempting to invalidate entries
that are still in-use by the guest OS (when in fact that guest is
in the process of being terminated or rebooted).
To alleviate this, register both a shutdown notifier (for unexpected
termination cases e.g. virsh destroy) as well as a reset callback
(for cases like guest OS reboot).  For each of these scenarios, trigger
PCI device reset; this is enough to indicate to firmware that the IOMMU
is no longer in-use by the guest OS, making it safe to invalidate any
associated IOMMU entries.

Fixes: 15d0e7942d3b ("s390x/pci: don't fence interpreted devices without MSI-X")
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Message-Id: <20221209195700.263824-1-mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
[thuth: Adjusted the hunk in s390-pci-vfio.c due to different context]
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agos390x/pci: shrink DMA aperture to be bound by vfio DMA limit
Matthew Rosato [Fri, 28 Oct 2022 19:47:58 +0000 (15:47 -0400)]
s390x/pci: shrink DMA aperture to be bound by vfio DMA limit

Currently, s390x-pci performs accounting against the vfio DMA
limit and triggers the guest to clean up mappings when the limit
is reached. Let's go a step further and also limit the size of
the supported DMA aperture reported to the guest based upon the
initial vfio DMA limit reported for the container (if less than
than the size reported by the firmware/host zPCI layer).  This
avoids processing sections of the guest DMA table during global
refresh that, for common use cases, will never be used anway, and
makes exhausting the vfio DMA limit due to mismatch between guest
aperture size and host limit far less likely and more indicitive
of an error.

Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Message-Id: <20221028194758.204007-4-mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agos390x/pci: coalesce unmap operations
Matthew Rosato [Fri, 28 Oct 2022 19:47:57 +0000 (15:47 -0400)]
s390x/pci: coalesce unmap operations

Currently, each unmapped page is handled as an individual iommu
region notification.  Attempt to group contiguous unmap operations
into fewer notifications to reduce overhead.

Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Message-Id: <20221028194758.204007-3-mjrosato@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
19 months agohw/arm/boot: set initrd with #address-cells type in fdt
Schspa Shi [Wed, 14 Dec 2022 14:27:13 +0000 (14:27 +0000)]
hw/arm/boot: set initrd with #address-cells type in fdt

We use 32bit value for linux,initrd-[start/end], when we have
loader_start > 4GB, there will be a wrong initrd_start passed
to the kernel, and the kernel will report the following warning.

[    0.000000] ------------[ cut here ]------------
[    0.000000] initrd not fully accessible via the linear mapping -- please check your bootloader ...
[    0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:355 arm64_memblock_init+0x158/0x244
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W          6.1.0-rc3-13250-g30a0b95b1335-dirty #28
[    0.000000] Hardware name: Horizon Sigi Virtual development board (DT)
[    0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    0.000000] pc : arm64_memblock_init+0x158/0x244
[    0.000000] lr : arm64_memblock_init+0x158/0x244
[    0.000000] sp : ffff800009273df0
[    0.000000] x29: ffff800009273df0 x28: 0000001000cc0010 x27: 0000800000000000
[    0.000000] x26: 000000000050a3e2 x25: ffff800008b46000 x24: ffff800008b46000
[    0.000000] x23: ffff800008a53000 x22: ffff800009420000 x21: ffff800008a53000
[    0.000000] x20: 0000000004000000 x19: 0000000004000000 x18: 00000000ffff1020
[    0.000000] x17: 6568632065736165 x16: 6c70202d2d20676e x15: 697070616d207261
[    0.000000] x14: 656e696c20656874 x13: 0a2e2e2e20726564 x12: 0000000000000000
[    0.000000] x11: 0000000000000000 x10: 00000000ffffffff x9 : 0000000000000000
[    0.000000] x8 : 0000000000000000 x7 : 796c6c756620746f x6 : 6e20647274696e69
[    0.000000] x5 : ffff8000093c7c47 x4 : ffff800008a2102f x3 : ffff800009273a88
[    0.000000] x2 : 80000000fffff038 x1 : 00000000000000c0 x0 : 0000000000000056
[    0.000000] Call trace:
[    0.000000]  arm64_memblock_init+0x158/0x244
[    0.000000]  setup_arch+0x164/0x1cc
[    0.000000]  start_kernel+0x94/0x4ac
[    0.000000]  __primary_switched+0xb4/0xbc
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000001000000000-0x0000001007ffffff]

This doesn't affect any machine types we currently support, because
for all of our machine types the RAM starts well below the 4GB
mark, but it does demonstrate that we're not currently writing
the device-tree properties quite as intended.

To fix it, we can change it to write these values to the dtb using a
type width matching #address-cells.  This is the intended size for
these dtb properties, and is how u-boot, for instance, writes them,
although in practice the Linux kernel will cope with them being any
width as long as they're big enough to fit the value.

Signed-off-by: Schspa Shi <schspa@gmail.com>
Message-id: 20221129160724.75667-1-schspa@gmail.com
[PMM: tweaked commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/intc: Convert TYPE_KVM_ARM_ITS to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:13 +0000 (14:27 +0000)]
hw/intc: Convert TYPE_KVM_ARM_ITS to 3-phase reset

Convert the TYPE_KVM_ARM_ITS device to 3-phase reset.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221109161444.3397405-10-peter.maydell@linaro.org

19 months agohw/intc: Convert TYPE_ARM_GICV3_ITS to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:12 +0000 (14:27 +0000)]
hw/intc: Convert TYPE_ARM_GICV3_ITS to 3-phase reset

Convert the TYPE_ARM_GICV3_ITS device to 3-phase reset.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221109161444.3397405-9-peter.maydell@linaro.org

19 months agohw/intc: Convert TYPE_ARM_GICV3_ITS_COMMON to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:12 +0000 (14:27 +0000)]
hw/intc: Convert TYPE_ARM_GICV3_ITS_COMMON to 3-phase reset

Convert the TYPE_ARM_GICV3_ITS_COMMON parent class to 3-phase reset.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20221109161444.3397405-8-peter.maydell@linaro.org

19 months agohw/intc: Convert TYPE_KVM_ARM_GICV3 to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:12 +0000 (14:27 +0000)]
hw/intc: Convert TYPE_KVM_ARM_GICV3 to 3-phase reset

Convert the TYPE_KVM_ARM_GICV3 device to 3-phase reset.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221109161444.3397405-7-peter.maydell@linaro.org

19 months agohw/intc: Convert TYPE_ARM_GICV3_COMMON to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:11 +0000 (14:27 +0000)]
hw/intc: Convert TYPE_ARM_GICV3_COMMON to 3-phase reset

Convert the TYPE_ARM_GICV3_COMMON parent class to 3-phase reset.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221109161444.3397405-6-peter.maydell@linaro.org

19 months agohw/intc: Convert TYPE_ARM_GIC_KVM to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:11 +0000 (14:27 +0000)]
hw/intc: Convert TYPE_ARM_GIC_KVM to 3-phase reset

Now we have converted TYPE_ARM_GIC_COMMON, we can convert the
TYPE_ARM_GIC_KVM subclass to 3-phase reset.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221109161444.3397405-5-peter.maydell@linaro.org

19 months agohw/intc: Convert TYPE_ARM_GIC_COMMON to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:11 +0000 (14:27 +0000)]
hw/intc: Convert TYPE_ARM_GIC_COMMON to 3-phase reset

Convert the TYPE_ARM_GIC_COMMON device to 3-phase reset.  This is a
simple no-behaviour-change conversion.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20221109161444.3397405-4-peter.maydell@linaro.org

19 months agohw/arm: Convert TYPE_ARM_SMMUV3 to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:10 +0000 (14:27 +0000)]
hw/arm: Convert TYPE_ARM_SMMUV3 to 3-phase reset

Convert the TYPE_ARM_SMMUV3 device to 3-phase reset.  The legacy
reset method doesn't do anything that's invalid in the hold phase, so
the conversion only requires changing it to a hold phase method, and
using the 3-phase versions of the "save the parent reset method and
chain to it" code.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20221109161444.3397405-3-peter.maydell@linaro.org

19 months agohw/arm: Convert TYPE_ARM_SMMU to 3-phase reset
Peter Maydell [Wed, 14 Dec 2022 14:27:10 +0000 (14:27 +0000)]
hw/arm: Convert TYPE_ARM_SMMU to 3-phase reset

Convert the TYPE_ARM_SMMU device to 3-phase reset.  The legacy method
doesn't do anything that's invalid in the hold phase, so the
conversion is simple and not a behaviour change.

Note that we must convert this base class before we can convert the
TYPE_ARM_SMMUV3 subclass -- transitional support in Resettable
handles "chain to parent class reset" when the base class is 3-phase
and the subclass is still using legacy reset, but not the other way
around.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20221109161444.3397405-2-peter.maydell@linaro.org

19 months agotarget/arm: Report FEAT_EVT for TCG '-cpu max'
Peter Maydell [Wed, 14 Dec 2022 14:27:10 +0000 (14:27 +0000)]
target/arm: Report FEAT_EVT for TCG '-cpu max'

Update the ID registers for TCG's '-cpu max' to report the
FEAT_EVT Enhanced Virtualization Traps support.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
19 months agotarget/arm: Implement HCR_EL2.TID4 traps
Peter Maydell [Wed, 14 Dec 2022 14:27:09 +0000 (14:27 +0000)]
target/arm: Implement HCR_EL2.TID4 traps

For FEAT_EVT, the HCR_EL2.TID4 trap allows trapping of the cache ID
registers CCSIDR_EL1, CCSIDR2_EL1, CLIDR_EL1 and CSSELR_EL1 (and
their AArch32 equivalents).  This is a subset of the registers
trapped by HCR_EL2.TID2, which includes all of these and also the
CTR_EL0 register.

Our implementation already uses a separate access function for
CTR_EL0 (ctr_el0_access()), so all of the registers currently using
access_aa64_tid2() should also be checking TID4.  Make that function
check both TID2 and TID4, and rename it appropriately.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
19 months agotarget/arm: Implement HCR_EL2.TICAB,TOCU traps
Peter Maydell [Wed, 14 Dec 2022 14:27:09 +0000 (14:27 +0000)]
target/arm: Implement HCR_EL2.TICAB,TOCU traps

For FEAT_EVT, the HCR_EL2.TICAB bit allows trapping of the ICIALLUIS
and IC IALLUIS cache maintenance instructions.

The HCR_EL2.TOCU bit traps all the other cache maintenance
instructions that operate to the point of unification:
 AArch64 IC IVAU, IC IALLU, DC CVAU
 AArch32 ICIMVAU, ICIALLU, DCCMVAU

The two trap bits between them cover all of the cache maintenance
instructions which must also check the HCR_TPU flag.  Turn the old
aa64_cacheop_pou_access() function into a helper function which takes
the set of HCR_EL2 flags to check as an argument, and call it from
new access_ticab() and access_tocu() functions as appropriate for
each cache op.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
19 months agotarget/arm: Implement HCR_EL2.TTLBOS traps
Peter Maydell [Wed, 14 Dec 2022 14:27:09 +0000 (14:27 +0000)]
target/arm: Implement HCR_EL2.TTLBOS traps

For FEAT_EVT, the HCR_EL2.TTLBOS bit allows trapping on EL1
use of TLB maintenance instructions that operate on the
outer shareable domain:

TLBI VMALLE1OS, TLBI VAE1OS, TLBI ASIDE1OS,TLBI VAAE1OS,
TLBI VALE1OS, TLBI VAALE1OS, TLBI RVAE1OS, TLBI RVAAE1OS,
TLBI RVALE1OS, and TLBI RVAALE1OS.

(There are no AArch32 outer-shareable TLB maintenance ops.)

Implement the trapping.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
19 months agotarget/arm: Implement HCR_EL2.TTLBIS traps
Peter Maydell [Wed, 14 Dec 2022 14:27:08 +0000 (14:27 +0000)]
target/arm: Implement HCR_EL2.TTLBIS traps

For FEAT_EVT, the HCR_EL2.TTLBIS bit allows trapping on EL1 use of
TLB maintenance instructions that operate on the inner shareable
domain:

AArch64:
 TLBI VMALLE1IS, TLBI VAE1IS, TLBI ASIDE1IS, TLBI VAAE1IS,
 TLBI VALE1IS, TLBI VAALE1IS, TLBI RVAE1IS, TLBI RVAAE1IS,
 TLBI RVALE1IS, and TLBI RVAALE1IS.

AArch32:
 TLBIALLIS, TLBIMVAIS, TLBIASIDIS, TLBIMVAAIS, TLBIMVALIS,
 and TLBIMVAALIS.

Add the trapping support.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
19 months agotarget/arm: Allow relevant HCR bits to be written for FEAT_EVT
Peter Maydell [Wed, 14 Dec 2022 14:27:08 +0000 (14:27 +0000)]
target/arm: Allow relevant HCR bits to be written for FEAT_EVT

FEAT_EVT adds five new bits to the HCR_EL2 register: TTLBIS, TTLBOS,
TICAB, TOCU and TID4.  These allow the guest to enable trapping of
various EL1 instructions to EL2.  In this commit, add the necessary
code to allow the guest to set these bits if the feature is present;
because the bit is always zero when the feature isn't present we
won't need to use explicit feature checks in the "trap on condition"
tests in the following commits.

Note that although full implementation of the feature (mandatory from
Armv8.5 onward) requires all five trap bits, the ID registers permit
a value indicating that only TICAB, TOCU and TID4 are implemented,
which might be the case for CPUs between Armv8.2 and Armv8.5.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
19 months agohw/intc/arm_gicv3: Fix GICD_TYPER ITLinesNumber advertisement
Luke Starrett [Wed, 14 Dec 2022 14:27:07 +0000 (14:27 +0000)]
hw/intc/arm_gicv3: Fix GICD_TYPER ITLinesNumber advertisement

The ARM GICv3 TRM describes that the ITLinesNumber field of GICD_TYPER
register:

"indicates the maximum SPI INTID that the GIC implementation supports"

As SPI #0 is absolute IRQ #32, the max SPI INTID should have accounted
for the internal 16x SGI's and 16x PPI's.  However, the original GICv3
model subtracted off the SGI/PPI.  Cosmetically this can be seen at OS
boot (Linux) showing 32 shy of what should be there, i.e.:

    [    0.000000] GICv3: 224 SPIs implemented

Though in hw/arm/virt.c, the machine is configured for 256 SPI's.  ARM
virt machine likely doesn't have a problem with this because the upper
32 IRQ's don't actually have anything meaningful wired. But, this does
become a functional issue on a custom use case which wants to make use
of these IRQ's.  Additionally, boot code (i.e. TF-A) will only init up
to the number (blocks of 32) that it believes to actually be there.

Signed-off-by: Luke Starrett <lukes@xsightlabs.com>
Message-id: AM9P193MB168473D99B761E204E032095D40D9@AM9P193MB1684.EURP193.PROD.OUTLOOK.COM
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agotarget/arm: Add Cortex-A55 CPU
Timofey Kutergin [Wed, 14 Dec 2022 14:27:07 +0000 (14:27 +0000)]
target/arm: Add Cortex-A55 CPU

The Cortex-A55 is one of the newer armv8.2+ CPUs; in particular
it supports the Privileged Access Never (PAN) feature. Add
a model of this CPU, so you can use a CPU type on the virt
board that models a specific real hardware CPU, rather than
having to use the QEMU-specific "max" CPU type.

Signed-off-by: Timofey Kutergin <tkutergin@gmail.com>
Message-id: 20221121150819.2782817-1-tkutergin@gmail.com
[PMM: tweaked commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: build SMBIOS 19 table
Mihai Carabas [Wed, 14 Dec 2022 14:27:07 +0000 (14:27 +0000)]
hw/arm/virt: build SMBIOS 19 table

Use the base_memmap to build the SMBIOS 19 table which provides the address
mapping for a Physical Memory Array (from spec [1] chapter 7.20).

This was present on i386 from commit c97294ec1b9e36887e119589d456557d72ab37b5
("SMBIOS: Build aggregate smbios tables and entry point").

[1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.5.0.pdf

The absence of this table is a breach of the specs and is
detected by the FirmwareTestSuite (FWTS), but it doesn't
cause any known problems for guest OSes.

Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com>
Message-id: 1668789029-5432-1-git-send-email-mihai.carabas@oracle.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: Add properties to disable high memory regions
Gavin Shan [Wed, 14 Dec 2022 14:27:06 +0000 (14:27 +0000)]
hw/arm/virt: Add properties to disable high memory regions

The 3 high memory regions are usually enabled by default, but they may
be not used. For example, VIRT_HIGH_GIC_REDIST2 isn't needed by GICv2.
This leads to waste in the PA space.

Add properties ("highmem-redists", "highmem-ecam", "highmem-mmio") to
allow users selectively disable them if needed. After that, the high
memory region for GICv3 or GICv4 redistributor can be disabled by user,
the number of maximal supported CPUs needs to be calculated based on
'vms->highmem_redists'. The follow-up error message is also improved
to indicate if the high memory region for GICv3 and GICv4 has been
enabled or not.

Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20221029224307.138822-8-gshan@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: Add 'compact-highmem' property
Gavin Shan [Wed, 14 Dec 2022 14:27:06 +0000 (14:27 +0000)]
hw/arm/virt: Add 'compact-highmem' property

After the improvement to high memory region address assignment is
applied, the memory layout can be changed, introducing possible
migration breakage. For example, VIRT_HIGH_PCIE_MMIO memory region
is disabled or enabled when the optimization is applied or not, with
the following configuration. The configuration is only achievable by
modifying the source code until more properties are added to allow
users selectively disable those high memory regions.

  pa_bits              = 40;
  vms->highmem_redists = false;
  vms->highmem_ecam    = false;
  vms->highmem_mmio    = true;

  # qemu-system-aarch64 -accel kvm -cpu host    \
    -machine virt-7.2,compact-highmem={on, off} \
    -m 4G,maxmem=511G -monitor stdio

  Region             compact-highmem=off         compact-highmem=on
  ----------------------------------------------------------------
  MEM                [1GB         512GB]        [1GB         512GB]
  HIGH_GIC_REDISTS2  [512GB       512GB+64MB]   [disabled]
  HIGH_PCIE_ECAM     [512GB+256MB 512GB+512MB]  [disabled]
  HIGH_PCIE_MMIO     [disabled]                 [512GB       1TB]

In order to keep backwords compatibility, we need to disable the
optimization on machine, which is virt-7.1 or ealier than it. It
means the optimization is enabled by default from virt-7.2. Besides,
'compact-highmem' property is added so that the optimization can be
explicitly enabled or disabled on all machine types by users.

Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
Message-id: 20221029224307.138822-7-gshan@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: Improve high memory region address assignment
Gavin Shan [Wed, 14 Dec 2022 14:27:06 +0000 (14:27 +0000)]
hw/arm/virt: Improve high memory region address assignment

There are three high memory regions, which are VIRT_HIGH_REDIST2,
VIRT_HIGH_PCIE_ECAM and VIRT_HIGH_PCIE_MMIO. Their base addresses
are floating on highest RAM address. However, they can be disabled
in several cases.

(1) One specific high memory region is likely to be disabled by
    code by toggling vms->highmem_{redists, ecam, mmio}.

(2) VIRT_HIGH_PCIE_ECAM region is disabled on machine, which is
    'virt-2.12' or ealier than it.

(3) VIRT_HIGH_PCIE_ECAM region is disabled when firmware is loaded
    on 32-bits system.

(4) One specific high memory region is disabled when it breaks the
    PA space limit.

The current implementation of virt_set_{memmap, high_memmap}() isn't
optimized because the high memory region's PA space is always reserved,
regardless of whatever the actual state in the corresponding
vms->highmem_{redists, ecam, mmio} flag. In the code, 'base' and
'vms->highest_gpa' are always increased for case (1), (2) and (3).
It's unnecessary since the assigned PA space for the disabled high
memory region won't be used afterwards.

Improve the address assignment for those three high memory region by
skipping the address assignment for one specific high memory region if
it has been disabled in case (1), (2) and (3). The memory layout may
be changed after the improvement is applied, which leads to potential
migration breakage. So 'vms->highmem_compact' is added to control if
the improvement should be applied. For now, 'vms->highmem_compact' is
set to false, meaning that we don't have memory layout change until it
becomes configurable through property 'compact-highmem' in next patch.

Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
Message-id: 20221029224307.138822-6-gshan@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: Introduce virt_get_high_memmap_enabled() helper
Gavin Shan [Wed, 14 Dec 2022 14:27:05 +0000 (14:27 +0000)]
hw/arm/virt: Introduce virt_get_high_memmap_enabled() helper

This introduces virt_get_high_memmap_enabled() helper, which returns
the pointer to vms->highmem_{redists, ecam, mmio}. The pointer will
be used in the subsequent patches.

No functional change intended.

Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
Message-id: 20221029224307.138822-5-gshan@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: Introduce variable region_base in virt_set_high_memmap()
Gavin Shan [Wed, 14 Dec 2022 14:27:05 +0000 (14:27 +0000)]
hw/arm/virt: Introduce variable region_base in virt_set_high_memmap()

This introduces variable 'region_base' for the base address of the
specific high memory region. It's the preparatory work to optimize
high memory region address assignment.

No functional change intended.

Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
Message-id: 20221029224307.138822-4-gshan@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: Rename variable size to region_size in virt_set_high_memmap()
Gavin Shan [Wed, 14 Dec 2022 14:27:05 +0000 (14:27 +0000)]
hw/arm/virt: Rename variable size to region_size in virt_set_high_memmap()

This renames variable 'size' to 'region_size' in virt_set_high_memmap().
Its counterpart ('region_base') will be introduced in next patch.

No functional change intended.

Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
Message-id: 20221029224307.138822-3-gshan@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agohw/arm/virt: Introduce virt_set_high_memmap() helper
Gavin Shan [Wed, 14 Dec 2022 14:27:04 +0000 (14:27 +0000)]
hw/arm/virt: Introduce virt_set_high_memmap() helper

This introduces virt_set_high_memmap() helper. The logic of high
memory region address assignment is moved to the helper. The intention
is to make the subsequent optimization for high memory region address
assignment easier.

No functional change intended.

Signed-off-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
Message-id: 20221029224307.138822-2-gshan@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agoMerge tag 'pull-misc-2022-12-14' of https://repo.or.cz/qemu/armbru into staging
Peter Maydell [Thu, 15 Dec 2022 10:13:46 +0000 (10:13 +0000)]
Merge tag 'pull-misc-2022-12-14' of https://repo.or.cz/qemu/armbru into staging

Miscellaneous patches for 2022-12-14

# gpg: Signature made Wed 14 Dec 2022 15:23:02 GMT
# gpg:                using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653
# gpg:                issuer "armbru@redhat.com"
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* tag 'pull-misc-2022-12-14' of https://repo.or.cz/qemu/armbru:
  ppc4xx_sdram: Simplify sdram_ddr_size() to return
  block/vmdk: Simplify vmdk_co_create() to return directly
  cleanup: Tweak and re-run return_directly.cocci
  io: Tidy up fat-fingered parameter name
  qapi: Use returned bool to check for failure (again)
  sockets: Use ERRP_GUARD() where obviously appropriate
  qemu-config: Use ERRP_GUARD() where obviously appropriate
  qemu-config: Make config_parse_qdict() return bool
  monitor: Use ERRP_GUARD() in monitor_init()
  monitor: Simplify monitor_fd_param()'s error handling
  error: Move ERRP_GUARD() to the beginning of the function
  error: Drop a few superfluous ERRP_GUARD()
  error: Drop some obviously superfluous error_propagate()
  Drop more useless casts from void * to pointer

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agomigration: Drop rs->f
Peter Xu [Tue, 11 Oct 2022 21:55:59 +0000 (17:55 -0400)]
migration: Drop rs->f

Now with rs->pss we can already cache channels in pss->pss_channels.  That
pss_channel contains more infromation than rs->f because it's per-channel.
So rs->f could be replaced by rss->pss[RAM_CHANNEL_PRECOPY].pss_channel,
while rs->f itself is a bit vague now.

Note that vanilla postcopy still send pages via pss[RAM_CHANNEL_PRECOPY],
that's slightly confusing but it reflects the reality.

Then, after the replacement we can safely drop rs->f.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Remove old preempt code around state maintainance
Peter Xu [Tue, 11 Oct 2022 21:55:58 +0000 (17:55 -0400)]
migration: Remove old preempt code around state maintainance

With the new code to send pages in rp-return thread, there's little help to
keep lots of the old code on maintaining the preempt state in migration
thread, because the new way should always be faster..

Then if we'll always send pages in the rp-return thread anyway, we don't
need those logic to maintain preempt state anymore because now we serialize
things using the mutex directly instead of using those fields.

It's very unfortunate to have those code for a short period, but that's
still one intermediate step that we noticed the next bottleneck on the
migration thread.  Now what we can do best is to drop unnecessary code as
long as the new code is stable to reduce the burden.  It's actually a good
thing because the new "sending page in rp-return thread" model is (IMHO)
even cleaner and with better performance.

Remove the old code that was responsible for maintaining preempt states, at
the meantime also remove x-postcopy-preempt-break-huge parameter because
with concurrent sender threads we don't really need to break-huge anymore.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Send requested page directly in rp-return thread
Peter Xu [Tue, 11 Oct 2022 21:55:57 +0000 (17:55 -0400)]
migration: Send requested page directly in rp-return thread

With all the facilities ready, send the requested page directly in the
rp-return thread rather than queuing it in the request queue, if and only
if postcopy preempt is enabled.  It can achieve so because it uses separate
channel for sending urgent pages.  The only shared data is bitmap and it's
protected by the bitmap_mutex.

Note that since we're moving the ownership of the urgent channel from the
migration thread to rp thread it also means the rp thread is responsible
for managing the qemufile, e.g. properly close it when pausing migration
happens.  For this, let migration_release_from_dst_file to cover shutdown
of the urgent channel too, renaming it as migration_release_dst_files() to
better show what it does.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Move last_sent_block into PageSearchStatus
Peter Xu [Tue, 11 Oct 2022 21:55:56 +0000 (17:55 -0400)]
migration: Move last_sent_block into PageSearchStatus

Since we use PageSearchStatus to represent a channel, it makes perfect
sense to keep last_sent_block (aka, leverage RAM_SAVE_FLAG_CONTINUE) to be
per-channel rather than global because each channel can be sending
different pages on ramblocks.

Hence move it from RAMState into PageSearchStatus.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Make PageSearchStatus part of RAMState
Peter Xu [Tue, 11 Oct 2022 21:55:55 +0000 (17:55 -0400)]
migration: Make PageSearchStatus part of RAMState

We used to allocate PSS structure on the stack for precopy when sending
pages.  Make it static, so as to describe per-channel ram migration status.

Here we declared RAM_CHANNEL_MAX instances, preparing for postcopy to use
it, even though this patch has not yet to start using the 2nd instance.

This should not have any functional change per se, but it already starts to
export PSS information via the RAMState, so that e.g. one PSS channel can
start to reference the other PSS channel.

Always protect PSS access using the same RAMState.bitmap_mutex.  We already
do so, so no code change needed, just some comment update.  Maybe we should
consider renaming bitmap_mutex some day as it's going to be a more commonly
and big mutex we use for ram states, but just leave it for later.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Add pss_init()
Peter Xu [Tue, 11 Oct 2022 21:55:54 +0000 (17:55 -0400)]
migration: Add pss_init()

Helper to init PSS structures.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Introduce pss_channel
Peter Xu [Tue, 11 Oct 2022 21:55:53 +0000 (17:55 -0400)]
migration: Introduce pss_channel

Introduce pss_channel for PageSearchStatus, define it as "the migration
channel to be used to transfer this host page".

We used to have rs->f, which is a mirror to MigrationState.to_dst_file.

After postcopy preempt initial version, rs->f can be dynamically changed
depending on which channel we want to use.

But that later work still doesn't grant full concurrency of sending pages
in e.g. different threads, because rs->f can either be the PRECOPY channel
or POSTCOPY channel.  This needs to be per-thread too.

PageSearchStatus is actually a good piece of struct which we can leverage
if we want to have multiple threads sending pages.  Sending a single guest
page may not make sense, so we make the granule to be "host page", and in
the PSS structure we allow specify a QEMUFile* to migrate a specific host
page.  Then we open the possibility to specify different channels in
different threads with different PSS structures.

The PSS prefix can be slightly misleading here because e.g. for the
upcoming usage of postcopy channel/thread it's not "searching" (or,
scanning) at all but sending the explicit page that was requested.  However
since PSS existed for some years keep it as-is until someone complains.

This patch mostly (simply) replace rs->f with pss->pss_channel only. No
functional change intended for this patch yet.  But it does prepare to
finally drop rs->f, and make ram_save_guest_page() thread safe.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Teach PSS about host page
Peter Xu [Tue, 11 Oct 2022 21:55:52 +0000 (17:55 -0400)]
migration: Teach PSS about host page

Migration code has a lot to do with host pages.  Teaching PSS core about
the idea of host page helps a lot and makes the code clean.  Meanwhile,
this prepares for the future changes that can leverage the new PSS helpers
that this patch introduces to send host page in another thread.

Three more fields are introduced for this:

  (1) host_page_sending: this is set to true when QEMU is sending a host
      page, false otherwise.

  (2) host_page_{start|end}: these point to the start/end of host page
      we're sending, and it's only valid when host_page_sending==true.

For example, when we look up the next dirty page on the ramblock, with
host_page_sending==true, we'll not try to look for anything beyond the
current host page boundary.  This can be slightly efficient than current
code because currently we'll set pss->page to next dirty bit (which can be
over current host page boundary) and reset it to host page boundary if we
found it goes beyond that.

With above, we can easily make migration_bitmap_find_dirty() self contained
by updating pss->page properly.  rs* parameter is removed because it's not
even used in old code.

When sending a host page, we should use the pss helpers like this:

  - pss_host_page_prepare(pss): called before sending host page
  - pss_within_range(pss): whether we're still working on the cur host page?
  - pss_host_page_finish(pss): called after sending a host page

Then we can use ram_save_target_page() to save one small page.

Currently ram_save_host_page() is still the only user. If there'll be
another function to send host page (e.g. in return path thread) in the
future, it should follow the same style.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Use atomic ops properly for page accountings
Peter Xu [Tue, 11 Oct 2022 21:55:51 +0000 (17:55 -0400)]
migration: Use atomic ops properly for page accountings

To prepare for thread-safety on page accountings, at least below counters
need to be accessed only atomically, they are:

        ram_counters.transferred
        ram_counters.duplicate
        ram_counters.normal
        ram_counters.postcopy_bytes

There are a lot of other counters but they won't be accessed outside
migration thread, then they're still safe to be accessed without atomic
ops.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Yield bitmap_mutex properly when sending/sleeping
Peter Xu [Tue, 11 Oct 2022 21:55:50 +0000 (17:55 -0400)]
migration: Yield bitmap_mutex properly when sending/sleeping

Don't take the bitmap mutex when sending pages, or when being throttled by
migration_rate_limit() (which is a bit tricky to call it here in ram code,
but seems still helpful).

It prepares for the possibility of concurrently sending pages in >1 threads
using the function ram_save_host_page() because all threads may need the
bitmap_mutex to operate on bitmaps, so that either sendmsg() or any kind of
qemu_sem_wait() blocking for one thread will not block the other from
progressing.

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Remove RAMState.f references in compression code
Peter Xu [Tue, 11 Oct 2022 21:55:49 +0000 (17:55 -0400)]
migration: Remove RAMState.f references in compression code

Removing referencing to RAMState.f in compress_page_with_multi_thread() and
flush_compressed_data().

Compression code by default isn't compatible with having >1 channels (or it
won't currently know which channel to flush the compressed data), so to
make it simple we always flush on the default to_dst_file port until
someone wants to add >1 ports support, as rs->f right now can really
change (after postcopy preempt is introduced).

There should be no functional change at all after patch applied, since as
long as rs->f referenced in compression code, it must be to_dst_file.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Trivial cleanup save_page_header() on same block check
Peter Xu [Tue, 11 Oct 2022 21:55:48 +0000 (17:55 -0400)]
migration: Trivial cleanup save_page_header() on same block check

The 2nd check on RAM_SAVE_FLAG_CONTINUE is a bit redundant.  Use a boolean
to be clearer.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Cleanup xbzrle zero page cache update logic
Peter Xu [Tue, 11 Oct 2022 21:55:47 +0000 (17:55 -0400)]
migration: Cleanup xbzrle zero page cache update logic

The major change is to replace "!save_page_use_compression()" with
"xbzrle_enabled" to make it clear.

Reasonings:

(1) When compression enabled, "!save_page_use_compression()" is exactly the
    same as checking "xbzrle_enabled".

(2) When compression disabled, "!save_page_use_compression()" always return
    true.  We used to try calling the xbzrle code, but after this change we
    won't, and we shouldn't need to.

Since at it, drop the xbzrle_enabled check in xbzrle_cache_zero_page()
because with this change it's not needed anymore.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Add postcopy_preempt_active()
Peter Xu [Tue, 11 Oct 2022 21:55:46 +0000 (17:55 -0400)]
migration: Add postcopy_preempt_active()

Add the helper to show that postcopy preempt enabled, meanwhile active.

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Take bitmap mutex when completing ram migration
Peter Xu [Tue, 11 Oct 2022 21:55:45 +0000 (17:55 -0400)]
migration: Take bitmap mutex when completing ram migration

Any call to ram_find_and_save_block() needs to take the bitmap mutex.  We
used to not take it for most of ram_save_complete() because we thought
we're the only one left using the bitmap, but it's not true after the
preempt full patchset applied, since the return path can be taking it too.

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
19 months agomigration: Export ram_release_page()
Juan Quintela [Thu, 16 Dec 2021 09:19:38 +0000 (10:19 +0100)]
migration: Export ram_release_page()

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Leonardo Bras <leobras@redhat.com>
19 months agomigration: Export ram_transferred_ram()
Juan Quintela [Tue, 22 Feb 2022 20:02:03 +0000 (21:02 +0100)]
migration: Export ram_transferred_ram()

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: Leonardo Bras <leobras@redhat.com>
19 months agomultifd: Create page_count fields into both MultiFD{Recv,Send}Params
Juan Quintela [Mon, 2 May 2022 14:53:12 +0000 (16:53 +0200)]
multifd: Create page_count fields into both MultiFD{Recv,Send}Params

We were recalculating it left and right.  We plan to change that
values on next patches.

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Leonardo Bras <leobras@redhat.com>
19 months agomultifd: Create page_size fields into both MultiFD{Recv,Send}Params
Juan Quintela [Mon, 2 May 2022 14:45:35 +0000 (16:45 +0200)]
multifd: Create page_size fields into both MultiFD{Recv,Send}Params

We were calling qemu_target_page_size() left and right.

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Leonardo Bras <leobras@redhat.com>
19 months agoMerge tag 'pull-qapi-2022-12-14-v2' of https://repo.or.cz/qemu/armbru into staging
Peter Maydell [Wed, 14 Dec 2022 22:42:13 +0000 (22:42 +0000)]
Merge tag 'pull-qapi-2022-12-14-v2' of https://repo.or.cz/qemu/armbru into staging

QAPI patches patches for 2022-12-14

# gpg: Signature made Wed 14 Dec 2022 19:14:34 GMT
# gpg:                using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653
# gpg:                issuer "armbru@redhat.com"
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* tag 'pull-qapi-2022-12-14-v2' of https://repo.or.cz/qemu/armbru: (30 commits)
  qapi: Drop temporary logic to support conversion step by step
  qapi qga: Elide redundant has_FOO in generated C
  qapi virtio: Elide redundant has_FOO in generated C
  qapi ui: Elide redundant has_FOO in generated C
  qapi transaction: Elide redundant has_FOO in generated C
  qapi tpm: Elide redundant has_FOO in generated C
  qapi stats: Elide redundant has_FOO in generated C
  qapi run-state: Elide redundant has_FOO in generated C
  qapi rocker: Elide redundant has_FOO in generated C
  qapi replay: Elide redundant has_FOO in generated C
  qapi qdev qom: Elide redundant has_FOO in generated C
  qapi pci: Elide redundant has_FOO in generated C
  qapi net: Elide redundant has_FOO in generated C
  qapi misc: Elide redundant has_FOO in generated C
  qapi migration: Elide redundant has_FOO in generated C
  qapi machine: Elide redundant has_FOO in generated C
  qapi job: Elide redundant has_FOO in generated C
  qapi dump: Elide redundant has_FOO in generated C
  qapi crypto: Elide redundant has_FOO in generated C
  qapi chardev: Elide redundant has_FOO in generated C
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
19 months agoqapi: Drop temporary logic to support conversion step by step
Markus Armbruster [Fri, 4 Nov 2022 16:07:12 +0000 (17:07 +0100)]
qapi: Drop temporary logic to support conversion step by step

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221104160712.3005652-31-armbru@redhat.com>

19 months agoqapi qga: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:11 +0000 (17:07 +0100)]
qapi qga: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qga/qapi-schema.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Michael Roth <michael.roth@amd.com>
Cc: Konstantin Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221104160712.3005652-30-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
19 months agoqapi virtio: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:10 +0000 (17:07 +0100)]
qapi virtio: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/virtio.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Laurent Vivier <lvivier@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221104160712.3005652-29-armbru@redhat.com>

19 months agoqapi ui: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:09 +0000 (17:07 +0100)]
qapi ui: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/ui.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20221104160712.3005652-28-armbru@redhat.com>

19 months agoqapi transaction: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:08 +0000 (17:07 +0100)]
qapi transaction: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/transaction.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

In qmp_transaction(), we can't just drop parameter @has_props, since
it's used to track whether @props needs to be freed.  Replace it by a
local variable.

Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Hanna Reitz <hreitz@redhat.com>
Cc: qemu-block@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221104160712.3005652-27-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
19 months agoqapi tpm: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:07 +0000 (17:07 +0100)]
qapi tpm: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/tpm.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Message-Id: <20221104160712.3005652-26-armbru@redhat.com>

19 months agoqapi stats: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:06 +0000 (17:07 +0100)]
qapi stats: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/stats.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Mark Kanda <mark.kanda@oracle.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Mark Kanda <mark.kanda@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221104160712.3005652-25-armbru@redhat.com>

19 months agoqapi run-state: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:05 +0000 (17:07 +0100)]
qapi run-state: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/run-state.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Drop a superfluous conditional around
qapi_free_GuestPanicInformation() while there.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221104160712.3005652-24-armbru@redhat.com>

19 months agoqapi rocker: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:04 +0000 (17:07 +0100)]
qapi rocker: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/rocker.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221104160712.3005652-23-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
19 months agoqapi replay: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:03 +0000 (17:07 +0100)]
qapi replay: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/replay.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221104160712.3005652-22-armbru@redhat.com>

19 months agoqapi qdev qom: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:02 +0000 (17:07 +0100)]
qapi qdev qom: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/qdev.json and
qapi/qom.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Eduardo Habkost <eduardo@habkost.net>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221104160712.3005652-21-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
19 months agoqapi pci: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:01 +0000 (17:07 +0100)]
qapi pci: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/pci.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221104160712.3005652-20-armbru@redhat.com>

19 months agoqapi net: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:07:00 +0000 (17:07 +0100)]
qapi net: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/net.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221104160712.3005652-19-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
[Fixes for MacOS squashed in]

19 months agoqapi misc: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:06:59 +0000 (17:06 +0100)]
qapi misc: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/misc.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20221104160712.3005652-18-armbru@redhat.com>

19 months agoqapi migration: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:06:58 +0000 (17:06 +0100)]
qapi migration: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/migration.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Juan Quintela <quintela@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20221104160712.3005652-17-armbru@redhat.com>

19 months agoqapi machine: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:06:57 +0000 (17:06 +0100)]
qapi machine: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/machine*.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: Eduardo Habkost <eduardo@habkost.net>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Cc: Yanan Wang <wangyanan55@huawei.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221104160712.3005652-16-armbru@redhat.com>

19 months agoqapi job: Elide redundant has_FOO in generated C
Markus Armbruster [Fri, 4 Nov 2022 16:06:56 +0000 (17:06 +0100)]
qapi job: Elide redundant has_FOO in generated C

The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with.  Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step.  This is the step for qapi/job.json.

Said commit explains the transformation in more detail.  The invariant
violations mentioned there do not occur here.

Cc: John Snow <jsnow@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-block@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20221104160712.3005652-15-armbru@redhat.com>