]> git.proxmox.com Git - mirror_qemu.git/log
mirror_qemu.git
4 years agovhost: Only align sections for vhost-user
Dr. David Alan Gilbert [Thu, 16 Jan 2020 20:24:14 +0000 (20:24 +0000)]
vhost: Only align sections for vhost-user

I added hugepage alignment code in c1ece84e7c9 to deal with
vhost-user + postcopy which needs aligned pages when using userfault.
However, on x86 the lower 2MB of address space tends to be shotgun'd
with small fragments around the 512-640k range - e.g. video RAM, and
with HyperV synic pages tend to sit around there - again splitting
it up.  The alignment code complains with a 'Section rounded to ...'
error and gives up.

Since vhost-user already filters out devices without an fd
(see vhost-user.c vhost_user_mem_section_filter) it shouldn't be
affected by those overlaps.

Turn the alignment off on vhost-kernel so that it doesn't try
and align, and thus won't hit the rounding issues.

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20200116202414.157959-3-dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
4 years agovhost: Add names to section rounded warning
Dr. David Alan Gilbert [Thu, 16 Jan 2020 20:24:13 +0000 (20:24 +0000)]
vhost: Add names to section rounded warning

Add the memory region names to section rounding/alignment
warnings.

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20200116202414.157959-2-dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 years agovhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks
Pan Nengyuan [Wed, 15 Jan 2020 06:25:35 +0000 (14:25 +0800)]
vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
patch save receive/transmit vq pointer in realize() and cleanup vqs
through those vq pointers in unrealize(). The leak stack is as follow:

Direct leak of 21504 byte(s) in 3 object(s) allocated from:
  #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970)  ??:?
  #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
  #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca)  /mnt/sdb/qemu/hw/virtio/virtio.c:2333
  #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208)  /mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339
  #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17)  /mnt/sdb/qemu/hw/virtio/virtio.c:3531
  #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65)  /mnt/sdb/qemu/hw/core/qdev.c:865
  #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41)  /mnt/sdb/qemu/qom/object.c:2102

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200115062535.50644-1-pannengyuan@huawei.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 years agovirtio-scsi: convert to new virtio_delete_queue
Pan Nengyuan [Fri, 17 Jan 2020 07:55:47 +0000 (15:55 +0800)]
virtio-scsi: convert to new virtio_delete_queue

Use virtio_delete_queue to make it more clear.

Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200117075547.60864-3-pannengyuan@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
4 years agovirtio-scsi: delete vqs in unrealize to avoid memleaks
Pan Nengyuan [Fri, 17 Jan 2020 07:55:46 +0000 (15:55 +0800)]
virtio-scsi: delete vqs in unrealize to avoid memleaks

This patch fix memleaks when attaching/detaching virtio-scsi device, the
memory leak stack is as follow:

Direct leak of 21504 byte(s) in 3 object(s) allocated from:
  #0 0x7f491f2f2970 (/lib64/libasan.so.5+0xef970)  ??:?
  #1 0x7f491e94649d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
  #2 0x564d0f3919fa (./x86_64-softmmu/qemu-system-x86_64+0x2c3e9fa)  /mnt/sdb/qemu/hw/virtio/virtio.c:2333
  #3 0x564d0f2eca55 (./x86_64-softmmu/qemu-system-x86_64+0x2b99a55)  /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:912
  #4 0x564d0f2ece7b (./x86_64-softmmu/qemu-system-x86_64+0x2b99e7b)  /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:924
  #5 0x564d0f39ee47 (./x86_64-softmmu/qemu-system-x86_64+0x2c4be47)  /mnt/sdb/qemu/hw/virtio/virtio.c:3531
  #6 0x564d0f980224 (./x86_64-softmmu/qemu-system-x86_64+0x322d224)  /mnt/sdb/qemu/hw/core/qdev.c:865

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200117075547.60864-2-pannengyuan@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
4 years agovirtio-9p-device: convert to new virtio_delete_queue
Pan Nengyuan [Fri, 17 Jan 2020 06:09:27 +0000 (14:09 +0800)]
virtio-9p-device: convert to new virtio_delete_queue

Use virtio_delete_queue to make it more clear.

Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200117060927.51996-3-pannengyuan@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
4 years agovirtio-9p-device: fix memleak in virtio_9p_device_unrealize
Pan Nengyuan [Fri, 17 Jan 2020 06:09:26 +0000 (14:09 +0800)]
virtio-9p-device: fix memleak in virtio_9p_device_unrealize

v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak
stack is as follow:

Direct leak of 14336 byte(s) in 2 object(s) allocated from:
  #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970)  ??:?
  #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
  #2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624)  /mnt/sdb/qemu/hw/virtio/virtio.c:2327
  #3 0x55a3a571bac7 (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7)  /mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209
  #4 0x55a3a58e7bc6 (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6)  /mnt/sdb/qemu/hw/virtio/virtio.c:3504
  #5 0x55a3a5ebfb37 (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37)  /mnt/sdb/qemu/hw/core/qdev.c:876

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200117060927.51996-2-pannengyuan@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Acked-by: Greg Kurz <groug@kaod.org>
4 years agobios-tables-test: document expected file update
Michael S. Tsirkin [Fri, 17 Jan 2020 12:18:18 +0000 (07:18 -0500)]
bios-tables-test: document expected file update

Document the flow for the case where contributor
updates the expected files.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 years agoacpi: cpuhp: add CPHP_GET_CPU_ID_CMD command
Igor Mammedov [Mon, 9 Dec 2019 13:09:02 +0000 (14:09 +0100)]
acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command

Firmware can enumerate present at boot APs by broadcasting wakeup IPI,
so that woken up secondary CPUs could register them-selves.
However in CPU hotplug case, it would need to know architecture
specific CPU IDs for possible and hotplugged CPUs so it could
prepare environment for and wake hotplugged AP.

Reuse and extend existing CPU hotplug interface to return architecture
specific ID for currently selected CPU in 2 registers:
 - lower 32 bits in ACPI_CPU_CMD_DATA_OFFSET_RW
 - upper 32 bits in ACPI_CPU_CMD_DATA2_OFFSET_R

On x86, firmware will use CPHP_GET_CPU_ID_CMD for fetching the APIC ID
when handling hotplug SMI.

Later, CPHP_GET_CPU_ID_CMD will be used on ARM to retrieve MPIDR,
which serves the similar to APIC ID purpose.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1575896942-331151-10-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
4 years agoacpi: cpuhp: spec: add typical usecases
Igor Mammedov [Mon, 9 Dec 2019 13:09:01 +0000 (14:09 +0100)]
acpi: cpuhp: spec: add typical usecases

Document work-flows for
  * enabling/detecting modern CPU hotplug interface
  * finding a CPU with pending 'insert/remove' event
  * enumerating present and possible CPUs

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1575896942-331151-9-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
4 years agoacpi: cpuhp: introduce 'Command data 2' field
Igor Mammedov [Mon, 9 Dec 2019 13:09:00 +0000 (14:09 +0100)]
acpi: cpuhp: introduce 'Command data 2' field

No functional change in practice, patch only aims to properly
document (in spec and code) intended usage of the reserved space.

The new field is to be used for 2 purposes:
  - detection of modern CPU hotplug interface using
    CPHP_GET_NEXT_CPU_WITH_EVENT_CMD command.
    procedure will be described in follow up patch:
      "acpi: cpuhp: spec: add typical usecases"
  - for returning upper 32 bits of architecture specific CPU ID,
    for new CPHP_GET_CPU_ID_CMD command added by follow up patch:
      "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command"

Change is backward compatible with 4.2 and older machines, as field was
unconditionally reserved and always returned 0x0 if modern CPU hotplug
interface was enabled.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1575896942-331151-8-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
4 years agoacpi: cpuhp: spec: clarify store into 'Command data' when 'Command field' == 0
Igor Mammedov [Mon, 9 Dec 2019 13:08:59 +0000 (14:08 +0100)]
acpi: cpuhp: spec: clarify store into 'Command data' when 'Command field' == 0

Write section of 'Command data' register should describe what happens
when it's written into. Correct description in case the last stored
'Command field' value is equal to 0, to reflect that currently it's not
supported.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <1575896942-331151-7-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 years agoacpi: cpuhp: spec: fix 'Command data' description
Igor Mammedov [Mon, 9 Dec 2019 13:08:58 +0000 (14:08 +0100)]
acpi: cpuhp: spec: fix 'Command data' description

Correct returned value description in case 'Command field' == 0x0,
it's not PXM but CPU selector value with pending event

In addition describe 0 blanket value in case of not supported
'Command field' value.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <1575896942-331151-6-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 years agoacpi: cpuhp: spec: clarify 'CPU selector' register usage and endianness
Igor Mammedov [Mon, 9 Dec 2019 13:08:57 +0000 (14:08 +0100)]
acpi: cpuhp: spec: clarify 'CPU selector' register usage and endianness

* Move reserved registers to the top of the section, so reader would be
  aware of effects when reading registers description.
* State registers endianness explicitly at the beginning of the section
* Describe registers behavior in case of 'CPU selector' register contains
  value that doesn't point to a possible CPU.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <1575896942-331151-5-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 years agotests: q35: MCH: add default SMBASE SMRAM lock test
Igor Mammedov [Mon, 9 Dec 2019 13:46:57 +0000 (14:46 +0100)]
tests: q35: MCH: add default SMBASE SMRAM lock test

test lockable SMRAM at default SMBASE feature, introduced by
patch "q35: implement 128K SMRAM at default SMBASE address"

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1575899217-333105-1-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
4 years agoq35: implement 128K SMRAM at default SMBASE address
Igor Mammedov [Mon, 9 Dec 2019 13:08:55 +0000 (14:08 +0100)]
q35: implement 128K SMRAM at default SMBASE address

It's not what real HW does, implementing which would be overkill [**]
and would require complex cross stack changes (QEMU+firmware) to make
it work.
So considering that SMRAM is owned by MCH, for simplicity (ab)use
reserved Q35 register, which allows QEMU and firmware easily init
and make RAM at SMBASE available only from SMM context.

Patch uses commit (2f295167e0 q35/mch: implement extended TSEG sizes)
for inspiration and uses reserved register in config space at 0x9c
offset [*] to extend q35 pci-host with ability to use 128K at
0x30000 as SMRAM and hide it (like TSEG) from non-SMM context.

Usage:
  1: write 0xff in the register
  2: if the feature is supported, follow up read from the register
     should return 0x01. At this point RAM at 0x30000 is still
     available for SMI handler configuration from non-SMM context
  3: writing 0x02 in the register, locks SMBASE area, making its contents
     available only from SMM context. In non-SMM context, reads return
     0xff and writes are ignored. Further writes into the register are
     ignored until the system reset.

*) https://www.mail-archive.com/qemu-devel@nongnu.org/msg455991.html
**) https://www.mail-archive.com/qemu-devel@nongnu.org/msg646965.html

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1575896942-331151-3-git-send-email-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
4 years agoMerge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20200121' into...
Peter Maydell [Tue, 21 Jan 2020 15:29:25 +0000 (15:29 +0000)]
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20200121' into staging

EDK2 firmware patches

Another set of build-sys patches, to help building the firmware
binaries we use for testing. We almost have reproducible builds.

# gpg: Signature made Tue 21 Jan 2020 15:14:09 GMT
# gpg:                using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD  6BB2 E3E3 2C2C DEAD C0DE

* remotes/philmd-gitlab/tags/edk2-next-20200121:
  gitlab-ci.yml: Add jobs to build EDK2 firmware binaries
  roms/edk2-funcs: Force softfloat ARM toolchain prefix on Debian

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agogitlab-ci.yml: Add jobs to build EDK2 firmware binaries
Philippe Mathieu-Daudé [Fri, 3 Jan 2020 11:26:25 +0000 (12:26 +0100)]
gitlab-ci.yml: Add jobs to build EDK2 firmware binaries

Add two GitLab job to build the EDK2 firmware binaries.

The first job build a Docker image with the packages requisite
to build EDK2, and store this image in the GitLab registry.
The second job pull the image from the registry and build the
EDK2 firmware binaries.

The docker image is only rebuilt if the GitLab YAML or the
Dockerfile is updated.
The second job is only built when the roms/edk2/ submodule is
updated, when a git-ref starts with 'edk2' or when the last
commit contains 'EDK2'. The files generated are archived in
the artifacts.zip file.

With edk2-stable201905, it took 2 minutes 52 seconds to build
the docker image, and 36 minutes 28 seconds to generate the
artifacts.zip with the firmware binaries (filesize: 10MiB).

See: https://gitlab.com/philmd/qemu/pipelines/107553178

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
4 years agoroms/edk2-funcs: Force softfloat ARM toolchain prefix on Debian
Philippe Mathieu-Daudé [Thu, 5 Dec 2019 17:55:41 +0000 (18:55 +0100)]
roms/edk2-funcs: Force softfloat ARM toolchain prefix on Debian

The Debian (based) distributions currently provides 2 ARM
toolchains, documented as [1]:

* The ARM EABI (armel) port targets a range of older 32-bit ARM
  devices, particularly those used in NAS hardware and a variety
  of *plug computers.
* The newer ARM hard-float (armhf) port supports newer, more
  powerful 32-bit devices using version 7 of the ARM architecture
  specification.

For various reasons documented in [2], the EDK2 project suggests
to use the softfloat toolchain (named 'armel' by Debian).

Force the softfloat cross toolchain prefix on Debian distributions.

[1] https://www.debian.org/ports/arm/#status
[2] https://github.com/tianocore/edk2/commit/41203b9a

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
4 years agoMerge remote-tracking branch 'remotes/vivier/tags/m68k-for-5.0-pull-request' into...
Peter Maydell [Tue, 21 Jan 2020 12:23:58 +0000 (12:23 +0000)]
Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-5.0-pull-request' into staging

Fix m68k single-stepping with remote gdb

# gpg: Signature made Tue 21 Jan 2020 12:21:12 GMT
# gpg:                using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C
# gpg:                issuer "laurent@vivier.eu"
# gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full]
# gpg:                 aka "Laurent Vivier <laurent@vivier.eu>" [full]
# gpg:                 aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full]
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F  5173 F30C 38BD 3F2F BE3C

* remotes/vivier/tags/m68k-for-5.0-pull-request:
  m68k: Fix regression causing Single-Step via GDB/RSP to not single step

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agom68k: Fix regression causing Single-Step via GDB/RSP to not single step
Laurent Vivier [Thu, 16 Jan 2020 16:54:54 +0000 (17:54 +0100)]
m68k: Fix regression causing Single-Step via GDB/RSP to not single step

A regression that was introduced, with the refactor to TranslatorOps,
drops two lines that update the PC when single-stepping is being performed.

Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps")
Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com>
Suggested-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20200116165454.2076265-1-laurent@vivier.eu>

4 years agoMakefile: add missing mkdir MANUAL_BUILDDIR
Stefan Hajnoczi [Mon, 20 Jan 2020 16:34:00 +0000 (16:34 +0000)]
Makefile: add missing mkdir MANUAL_BUILDDIR

The MANUAL_BUILDDIR directory is automatically created by sphinx-build
for the other targets.  The index.html target does not use sphinx-build
so we must manually create the directory to avoid the following error:

  GEN     docs/built/index.html
  /bin/sh: docs/built/index.html: No such file or directory

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20200120163400.603449-1-stefanha@redhat.com
Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoMerge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-01-20' into staging
Peter Maydell [Mon, 20 Jan 2020 18:49:04 +0000 (18:49 +0000)]
Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-01-20' into staging

Assorted fixes and cleanups.
v2: - fix 32-bit build

# gpg: Signature made Mon 20 Jan 2020 14:14:11 GMT
# gpg:                using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6
# gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full]
# gpg:                 aka "Gregory Kurz <gregory.kurz@free.fr>" [full]
# gpg:                 aka "[jpeg image of size 3330]" [full]
# Primary key fingerprint: B482 8BAF 9431 40CE F2A3  4910 71D4 D5E5 822F 73D6

* remotes/gkurz/tags/9p-next-2020-01-20:
  9pfs/9p.c: remove unneeded labels
  virtfs-proxy-helper.c: remove 'err_out' label in setugid()
  9p: init_in_iov_from_pdu can truncate the size
  9p: local: always return -1 on error in local_unlinkat_common
  9pfs: local: Fix possible memory leak in local_link()

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years ago9pfs/9p.c: remove unneeded labels
Daniel Henrique Barboza [Mon, 20 Jan 2020 14:11:39 +0000 (15:11 +0100)]
9pfs/9p.c: remove unneeded labels

'out' label in v9fs_xattr_write() and 'out_nofid' label in
v9fs_complete_rename() can be replaced by appropriate return
calls.

CC: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
4 years agovirtfs-proxy-helper.c: remove 'err_out' label in setugid()
Daniel Henrique Barboza [Mon, 20 Jan 2020 14:11:39 +0000 (15:11 +0100)]
virtfs-proxy-helper.c: remove 'err_out' label in setugid()

'err_out' can be removed and be replaced by 'return -errno'
in its only instance in the function.

CC: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
4 years ago9p: init_in_iov_from_pdu can truncate the size
Greg Kurz [Mon, 20 Jan 2020 14:11:39 +0000 (15:11 +0100)]
9p: init_in_iov_from_pdu can truncate the size

init_in_iov_from_pdu might not be able to allocate the full buffer size
requested, which comes from the client and could be larger than the
transport has available at the time of the request. Specifically, this
can happen with read operations, with the client requesting a read up to
the max allowed, which might be more than the transport has available at
the time.

Today the implementation of init_in_iov_from_pdu throws an error, both
Xen and Virtio.

Instead, change the V9fsTransport interface so that the size becomes a
pointer and can be limited by the implementation of
init_in_iov_from_pdu.

Change both the Xen and Virtio implementations to set the size to the
size of the buffer they managed to allocate, instead of throwing an
error. However, if the allocated buffer size is less than P9_IOHDRSZ
(the size of the header) still throw an error as the case is unhandable.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
CC: groug@kaod.org
CC: anthony.perard@citrix.com
CC: roman@zededa.com
CC: qemu_oss@crudebyte.com
[groug: fix 32-bit build]
Signed-off-by: Greg Kurz <groug@kaod.org>
4 years ago9p: local: always return -1 on error in local_unlinkat_common
Daniel Henrique Barboza [Mon, 20 Jan 2020 14:11:39 +0000 (15:11 +0100)]
9p: local: always return -1 on error in local_unlinkat_common

local_unlinkat_common() is supposed to always return -1 on error.
This is being done by jumps to the 'err_out' label, which is
a 'return ret' call, and 'ret' is initialized with -1.

Unfortunately there is a condition in which the function will
return 0 on error: in a case where flags == AT_REMOVEDIR, 'ret'
will be 0 when reaching

map_dirfd = openat_dir(...)

And, if map_dirfd == -1 and errno != ENOENT, the existing 'err_out'
jump will execute 'return ret', when ret is still set to zero
at that point.

This patch fixes it by changing all 'err_out' labels by
'return -1' calls, ensuring that the function will always
return -1 on error conditions. 'ret' can be left unintialized
since it's now being used just to store the result of 'unlinkat'
calls.

CC: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
[groug: changed prefix in title to be "9p: local:"]
Signed-off-by: Greg Kurz <groug@kaod.org>
4 years ago9pfs: local: Fix possible memory leak in local_link()
Jiajun Chen [Mon, 20 Jan 2020 14:11:39 +0000 (15:11 +0100)]
9pfs: local: Fix possible memory leak in local_link()

There is a possible memory leak while local_link return -1 without free
odirpath and oname.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Jaijun Chen <chenjiajun8@huawei.com>
Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
4 years agoqapi: Fix code generation with Python 3.5
Markus Armbruster [Thu, 16 Jan 2020 20:25:58 +0000 (21:25 +0100)]
qapi: Fix code generation with Python 3.5

Recent commit 3e7fb5811b "qapi: Fix code generation for empty modules"
modules" switched QAPISchema.visit() from

    for entity in self._entity_list:

effectively to

    for mod in self._module_dict.values():
        for entity in mod._entity_list:

Visits in the same order as long as .values() is in insertion order.
That's the case only for Python 3.6 and later.  Before, it's in some
arbitrary order, which results in broken generated code.

Fix by making self._module_dict an OrderedDict rather than a dict.

Fixes: 3e7fb5811baab213dcc7149c3aa69442d683c26c
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Thomas Huth <thuth@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20200116202558.31473-1-armbru@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoMerge remote-tracking branch 'remotes/juanquintela/tags/migration-pull-pull-request...
Peter Maydell [Mon, 20 Jan 2020 10:41:27 +0000 (10:41 +0000)]
Merge remote-tracking branch 'remotes/juanquintela/tags/migration-pull-pull-request' into staging

Migration pull request

# gpg: Signature made Mon 20 Jan 2020 10:29:53 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

* remotes/juanquintela/tags/migration-pull-pull-request: (29 commits)
  multifd: Be consistent about using uint64_t
  migration: Support QLIST migration
  apic: Use 32bit APIC ID for migration instance ID
  migration: Change SaveStateEntry.instance_id into uint32_t
  migration: Define VMSTATE_INSTANCE_ID_ANY
  Bug #1829242 correction.
  migration/multifd: fix destroyed mutex access in terminating multifd threads
  migration/multifd: fix nullptr access in terminating multifd threads
  migration/multifd: not use multifd during postcopy
  migration/multifd: clean pages after filling packet
  migration/postcopy: enable compress during postcopy
  migration/postcopy: enable random order target page arrival
  migration/postcopy: set all_zero to true on the first target page
  migration/postcopy: count target page number to decide the place_needed
  migration/postcopy: wait for decompress thread in precopy
  migration/postcopy: reduce memset when it is zero page and matches_target_page_size
  migration/ram: Yield periodically to the main loop
  migration: savevm_state_handler_insert: constant-time element insertion
  migration: add savevm_state_handler_remove()
  misc: use QEMU_IS_ALIGNED
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agomultifd: Be consistent about using uint64_t
Juan Quintela [Tue, 14 Jan 2020 11:24:09 +0000 (12:24 +0100)]
multifd: Be consistent about using uint64_t

We transmit ram_addr_t always as uint64_t.  Be consistent in its
use (on 64bit system, it is always uint64_t problem is 32bits).

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
4 years agomigration: Support QLIST migration
Eric Auger [Mon, 13 Jan 2020 13:48:23 +0000 (14:48 +0100)]
migration: Support QLIST migration

Support QLIST migration using the same principle as QTAILQ:
94869d5c52 ("migration: migrate QTAILQ").

The VMSTATE_QLIST_V macro has the same proto as VMSTATE_QTAILQ_V.
The change mainly resides in QLIST RAW macros: QLIST_RAW_INSERT_HEAD
and QLIST_RAW_REVERSE.

Tests also are provided.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agoapic: Use 32bit APIC ID for migration instance ID
Peter Xu [Wed, 16 Oct 2019 02:29:32 +0000 (10:29 +0800)]
apic: Use 32bit APIC ID for migration instance ID

Migration is silently broken now with x2apic config like this:

     -smp 200,maxcpus=288,sockets=2,cores=72,threads=2 \
     -device intel-iommu,intremap=on,eim=on

After migration, the guest kernel could hang at anything, due to
x2apic bit not migrated correctly in IA32_APIC_BASE on some vcpus, so
any operations related to x2apic could be broken then (e.g., RDMSR on
x2apic MSRs could fail because KVM would think that the vcpu hasn't
enabled x2apic at all).

The issue is that the x2apic bit was never applied correctly for vcpus
whose ID > 255 when migrate completes, and that's because when we
migrate APIC we use the APICCommonState.id as instance ID of the
migration stream, while that's too short for x2apic.

Let's use the newly introduced initial_apic_id for that.

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration: Change SaveStateEntry.instance_id into uint32_t
Peter Xu [Wed, 16 Oct 2019 02:29:31 +0000 (10:29 +0800)]
migration: Change SaveStateEntry.instance_id into uint32_t

It was always used as 32bit, so define it as used to be clear.
Instead of using -1 as the auto-gen magic value, we switch to
UINT32_MAX.  We also make sure that we don't auto-gen this value to
avoid overflowed instance IDs without being noticed.

Suggested-by: Juan Quintela <quintela@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>
4 years agomigration: Define VMSTATE_INSTANCE_ID_ANY
Peter Xu [Wed, 16 Oct 2019 02:29:30 +0000 (10:29 +0800)]
migration: Define VMSTATE_INSTANCE_ID_ANY

Define the new macro VMSTATE_INSTANCE_ID_ANY for callers who wants to
auto-generate the vmstate instance ID.  Previously it was hard coded
as -1 instead of this macro.  It helps to change this default value in
the follow up patches.  No functional change.

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agoBug #1829242 correction.
Alexey Romko [Fri, 10 Jan 2020 13:51:34 +0000 (14:51 +0100)]
Bug #1829242 correction.

Added type conversions to ram_addr_t before all left shifts of page
indexes to TARGET_PAGE_BITS, to correct overflows when the page
address was 4Gb and more.

Signed-off-by: Alexey Romko <nevilad@yahoo.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>
4 years agomigration/multifd: fix destroyed mutex access in terminating multifd threads
Jiahui Cen [Wed, 23 Oct 2019 03:47:37 +0000 (11:47 +0800)]
migration/multifd: fix destroyed mutex access in terminating multifd threads

One multifd will lock all the other multifds' IOChannel mutex to inform them
to quit by setting p->quit or shutting down p->c. In this senario, if some
multifds had already been terminated and multifd_load_cleanup/multifd_save_cleanup
had destroyed their mutex, it could cause destroyed mutex access when trying
lock their mutex.

Here is the coredump stack:
    #0  0x00007f81a2794437 in raise () from /usr/lib64/libc.so.6
    #1  0x00007f81a2795b28 in abort () from /usr/lib64/libc.so.6
    #2  0x00007f81a278d1b6 in __assert_fail_base () from /usr/lib64/libc.so.6
    #3  0x00007f81a278d262 in __assert_fail () from /usr/lib64/libc.so.6
    #4  0x000055eb1bfadbd3 in qemu_mutex_lock_impl (mutex=0x55eb1e2d1988, file=<optimized out>, line=<optimized out>) at util/qemu-thread-posix.c:64
    #5  0x000055eb1bb4564a in multifd_send_terminate_threads (err=<optimized out>) at migration/ram.c:1015
    #6  0x000055eb1bb4bb7f in multifd_send_thread (opaque=0x55eb1e2d19f8) at migration/ram.c:1171
    #7  0x000055eb1bfad628 in qemu_thread_start (args=0x55eb1e170450) at util/qemu-thread-posix.c:502
    #8  0x00007f81a2b36df5 in start_thread () from /usr/lib64/libpthread.so.0
    #9  0x00007f81a286048d in clone () from /usr/lib64/libc.so.6

To fix it up, let's destroy the mutex after all the other multifd threads had
been terminated.

Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Signed-off-by: Ying Fang <fangying1@huawei.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/multifd: fix nullptr access in terminating multifd threads
Jiahui Cen [Wed, 23 Oct 2019 04:30:02 +0000 (12:30 +0800)]
migration/multifd: fix nullptr access in terminating multifd threads

One multifd channel will shutdown all the other multifd's IOChannel when it
fails to receive an IOChannel. In this senario, if some multifds had not
received its IOChannel yet, it would try to shutdown its IOChannel which could
cause nullptr access at qio_channel_shutdown.

Here is the coredump stack:
    #0  object_get_class (obj=obj@entry=0x0) at qom/object.c:908
    #1  0x00005563fdbb8f4a in qio_channel_shutdown (ioc=0x0, how=QIO_CHANNEL_SHUTDOWN_BOTH, errp=0x0) at io/channel.c:355
    #2  0x00005563fd7b4c5f in multifd_recv_terminate_threads (err=<optimized out>) at migration/ram.c:1280
    #3  0x00005563fd7bc019 in multifd_recv_new_channel (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce00) at migration/ram.c:1478
    #4  0x00005563fda82177 in migration_ioc_process_incoming (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce30) at migration/migration.c:605
    #5  0x00005563fda8567d in migration_channel_process_incoming (ioc=0x556400255610) at migration/channel.c:44
    #6  0x00005563fda83ee0 in socket_accept_incoming_migration (listener=0x5563fff6b920, cioc=0x556400255610, opaque=<optimized out>) at migration/socket.c:166
    #7  0x00005563fdbc25cd in qio_net_listener_channel_func (ioc=<optimized out>, condition=<optimized out>, opaque=<optimized out>) at io/net-listener.c:54
    #8  0x00007f895b6fe9a9 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
    #9  0x00005563fdc18136 in glib_pollfds_poll () at util/main-loop.c:218
    #10 0x00005563fdc181b5 in os_host_main_loop_wait (timeout=1000000000) at util/main-loop.c:241
    #11 0x00005563fdc183a2 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:517
    #12 0x00005563fd8edb37 in main_loop () at vl.c:1791
    #13 0x00005563fd74fd45 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4473

To fix it up, let's check p->c before calling qio_channel_shutdown.

Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Signed-off-by: Ying Fang <fangying1@huawei.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/multifd: not use multifd during postcopy
Wei Yang [Fri, 25 Oct 2019 23:20:00 +0000 (07:20 +0800)]
migration/multifd: not use multifd during postcopy

We don't support multifd during postcopy, but user still could enable
both multifd and postcopy. This leads to migration failure.

Skip multifd during postcopy.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/multifd: clean pages after filling packet
Wei Yang [Fri, 25 Oct 2019 23:19:59 +0000 (07:19 +0800)]
migration/multifd: clean pages after filling packet

This is a preparation for the next patch:

    not use multifd during postcopy.

Without enabling postcopy, everything looks good. While after enabling
postcopy, migration may fail even not use multifd during postcopy. The
reason is the pages is not properly cleared and *old* target page will
continue to be transferred.

After clean pages, migration succeeds.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/postcopy: enable compress during postcopy
Wei Yang [Thu, 7 Nov 2019 12:39:07 +0000 (20:39 +0800)]
migration/postcopy: enable compress during postcopy

postcopy requires to place a whole host page, while migration thread
migrate memory in target page size. This makes postcopy need to collect
all target pages in one host page before placing via userfaultfd.

To enable compress during postcopy, there are two problems to solve:

    1. Random order for target page arrival
    2. Target pages in one host page arrives without interrupt by target
       page from other host page

The first one is handled by previous cleanup patch.

This patch handles the second one by:

    1. Flush compress thread for each host page
    2. Wait for decompress thread for before placing host page

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/postcopy: enable random order target page arrival
Wei Yang [Thu, 7 Nov 2019 12:39:06 +0000 (20:39 +0800)]
migration/postcopy: enable random order target page arrival

After using number of target page received to track one host page, we
could have the capability to handle random order target page arrival in
one host page.

This is a preparation for enabling compress during postcopy.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/postcopy: set all_zero to true on the first target page
Wei Yang [Thu, 7 Nov 2019 12:39:05 +0000 (20:39 +0800)]
migration/postcopy: set all_zero to true on the first target page

For the first target page, all_zero is set to true for this round check.

After target_pages introduced, we could leverage this variable instead
of checking the address offset.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/postcopy: count target page number to decide the place_needed
Wei Yang [Thu, 7 Nov 2019 12:39:04 +0000 (20:39 +0800)]
migration/postcopy: count target page number to decide the place_needed

In postcopy, it requires to place whole host page instead of target
page.

Currently, it relies on the page offset to decide whether this is the
last target page. We also can count the target page number during the
iteration. When the number of target page equals
(host page size / target page size), this means it is the last target
page in the host page.

This is a preparation for non-ordered target page transmission.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/postcopy: wait for decompress thread in precopy
Wei Yang [Thu, 7 Nov 2019 12:39:03 +0000 (20:39 +0800)]
migration/postcopy: wait for decompress thread in precopy

Compress is not supported with postcopy, it is safe to wait for
decompress thread just in precopy.

This is a preparation for later patch.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/postcopy: reduce memset when it is zero page and matches_target_page_size
Wei Yang [Thu, 7 Nov 2019 12:39:02 +0000 (20:39 +0800)]
migration/postcopy: reduce memset when it is zero page and matches_target_page_size

In this case, page_buffer content would not be used.

Skip this to save some time.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration/ram: Yield periodically to the main loop
Yury Kotov [Mon, 25 Nov 2019 13:36:32 +0000 (16:36 +0300)]
migration/ram: Yield periodically to the main loop

Usually, incoming migration coroutine yields to the main loop
while its IO-channel is waiting for data to receive. But there is a case
when RAM migration and data receive have the same speed: VM with huge
zeroed RAM. In this case, IO-channel won't read and thus the main loop
is stuck and for instance, it doesn't respond to QMP commands.

For this case, yield periodically, but not too often, so as not to
affect the speed of migration.

Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration: savevm_state_handler_insert: constant-time element insertion
Scott Cheloha [Thu, 17 Oct 2019 20:59:53 +0000 (15:59 -0500)]
migration: savevm_state_handler_insert: constant-time element insertion

savevm_state's SaveStateEntry TAILQ is a priority queue.  Priority
sorting is maintained by searching from head to tail for a suitable
insertion spot.  Insertion is thus an O(n) operation.

If we instead keep track of the head of each priority's subqueue
within that larger queue we can reduce this operation to O(1) time.

savevm_state_handler_remove() becomes slightly more complex to
accomodate these gains: we need to replace the head of a priority's
subqueue when removing it.

With O(1) insertion, booting VMs with many SaveStateEntry objects is
more plausible.  For example, a ppc64 VM with maxmem=8T has 40000 such
objects to insert.

Signed-off-by: Scott Cheloha <cheloha@linux.vnet.ibm.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration: add savevm_state_handler_remove()
Scott Cheloha [Thu, 17 Oct 2019 20:59:52 +0000 (15:59 -0500)]
migration: add savevm_state_handler_remove()

Create a function to abstract common logic needed when removing a
SaveStateEntry element from the savevm_state.handlers queue.

For now we just remove the element.  Soon it will involve additional
cleanup.

Signed-off-by: Scott Cheloha <cheloha@linux.vnet.ibm.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomisc: use QEMU_IS_ALIGNED
Marc-André Lureau [Fri, 3 Jan 2020 07:39:58 +0000 (11:39 +0400)]
misc: use QEMU_IS_ALIGNED

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration: Fix the re-run check of the migrate-incoming command
Yury Kotov [Wed, 13 Nov 2019 17:53:25 +0000 (20:53 +0300)]
migration: Fix the re-run check of the migrate-incoming command

The current check sets an error but doesn't fail the command.
This may cause a problem if new connection attempt by the same URI
affects the first connection.

Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration: Fix incorrect integer->float conversion caught by clang
Fangrui Song [Fri, 22 Nov 2019 08:00:38 +0000 (09:00 +0100)]
migration: Fix incorrect integer->float conversion caught by clang

Clang does not like qmp_migrate_set_downtime()'s code to clamp double
@value to 0..INT64_MAX:

    qemu/migration/migration.c:2038:24: error: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion]

The warning will be enabled by default in clang 10. It is not
available for clang <= 9.

The clamp is actually useless; @value is checked to be within
0..MAX_MIGRATE_DOWNTIME_SECONDS immediately before.  Delete it.

While there, make the conversion from double to int64_t explicit.

Signed-off-by: Fangrui Song <i@maskray.me>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[Patch split, commit message improved]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration: Rate limit inside host pages
Dr. David Alan Gilbert [Thu, 5 Dec 2019 10:29:18 +0000 (10:29 +0000)]
migration: Rate limit inside host pages

When using hugepages, rate limiting is necessary within each huge
page, since a 1G huge page can take a significant time to send, so
you end up with bursty behaviour.

Fixes: 4c011c37ecb3 ("postcopy: Send whole huge pages")
Reported-by: Lin Ma <LMa@suse.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agoram.c: remove unneeded labels
Daniel Henrique Barboza [Mon, 6 Jan 2020 18:23:31 +0000 (15:23 -0300)]
ram.c: remove unneeded labels

ram_save_queue_pages() has an 'err' label that can be replaced by
'return -1' instead.

Same thing with ram_discard_range(), and in this case we can also
get rid of the 'ret' variable and return either '-1' on error
or the result of ram_block_discard_range().

CC: Juan Quintela <quintela@redhat.com>
CC: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agorunstate: ignore finishmigrate -> prelaunch transition
Laurent Vivier [Fri, 29 Nov 2019 11:51:32 +0000 (12:51 +0100)]
runstate: ignore finishmigrate -> prelaunch transition

Commit 1bd71dce4bf2 tries to prevent a finishmigrate -> prelaunch
transition by exiting at the beginning of the main_loop_should_exit()
function if the state is already finishmigrate.

As the finishmigrate state is set in the migration thread it can
happen concurrently to the function. The migration thread and the
function are normally protected by the iothread mutex and thus the
state should no evolve between the start of the function and its end.

Unfortunately during the function life the lock is released by
pause_all_vcpus() just before the point we need to be sure we are
not in finishmigrate state and if the migration thread is waiting
for the lock it will take the opportunity to change the state
to finishmigrate.

The only way to be sure we are not in the finishmigrate state when
we need is to check the state after the pause_all_vcpus() function.

Fixes: 1bd71dce4bf2 ("runstate: ignore exit request in finish migrate state")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration-test: introduce functions to handle string parameters
Juan Quintela [Wed, 3 Apr 2019 09:00:04 +0000 (11:00 +0200)]
migration-test: introduce functions to handle string parameters

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration: Make sure that we don't call write() in case of error
Juan Quintela [Wed, 18 Dec 2019 04:36:22 +0000 (05:36 +0100)]
migration: Make sure that we don't call write() in case of error

If we are exiting due to an error/finish/.... Just don't try to even
touch the channel with one IO operation.

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomigration-test: Add migration multifd test
Juan Quintela [Mon, 23 Oct 2017 12:50:16 +0000 (14:50 +0200)]
migration-test: Add migration multifd test

We set multifd-channels.

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Wei Yang <richardw.yang@linux.intel.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
4 years agomultifd: Initialize local variable
Juan Quintela [Mon, 13 Jan 2020 17:41:02 +0000 (18:41 +0100)]
multifd: Initialize local variable

Fill everything with zero, so the padding fields are also initialized.

Signed-off-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
4 years agoMerge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200117-1' into...
Peter Maydell [Fri, 17 Jan 2020 17:27:20 +0000 (17:27 +0000)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200117-1' into staging

Add model of the Netduino Plus 2 board
Some allwinner-a10 code cleanup
New test cases for cubieboard
target/arm/arm-semi: fix SYS_OPEN to return nonzero filehandle
i.MX: add an emulation for RNGC device
target/arm: adjust program counter for wfi exception in AArch32
arm/gicv3: update virtual irq state after IAR register read
Set IL bit correctly for syndrome information for data aborts

# gpg: Signature made Fri 17 Jan 2020 14:27:40 GMT
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20200117-1:
  target/arm: Set ISSIs16Bit in make_issinfo
  target/arm: Return correct IL bit in merge_syn_data_abort
  arm/gicv3: update virtual irq state after IAR register read
  target/arm: adjust program counter for wfi exception in AArch32
  i.MX: add an emulation for RNGC
  target/arm/arm-semi: fix SYS_OPEN to return nonzero filehandle
  hw/arm/allwinner-a10: Remove local qemu_irq variables
  hw/arm/allwinner-a10: Simplify by passing IRQs with qdev_pass_gpios()
  hw/arm/allwinner-a10: Move SoC definitions out of header
  tests/boot_linux_console: Add a SD card test for the CubieBoard
  tests/boot_linux_console: Add initrd test for the CubieBoard
  hw/arm: Add the Netduino Plus 2
  hw/arm: Add the STM32F4xx SoC
  hw/misc: Add the STM32F4xx EXTI device
  hw/misc: Add the STM32F4xx Sysconfig device

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoMerge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-01-17' into...
Peter Maydell [Fri, 17 Jan 2020 14:56:53 +0000 (14:56 +0000)]
Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2020-01-17' into staging

* Various fixes for qtests
* Enable TCG tests with TCI in the gitlab CI

# gpg: Signature made Fri 17 Jan 2020 10:35:17 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

* remotes/huth-gitlab/tags/pull-request-2020-01-17:
  gitlab-ci.yml: Run tcg test with tci
  tests/qtest/vhost-user-test: Fix memory leaks
  migration-test: ppc64: fix FORTH test program
  tests: acpi: update path in rebuild-expected-aml

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agotarget/arm: Set ISSIs16Bit in make_issinfo
Richard Henderson [Fri, 17 Jan 2020 14:09:31 +0000 (14:09 +0000)]
target/arm: Set ISSIs16Bit in make_issinfo

During the conversion to decodetree, the setting of
ISSIs16Bit got lost.  This causes the guest os to
incorrectly adjust trapping memory operations.

Cc: qemu-stable@nongnu.org
Fixes: 46beb58efbb8a2a32 ("target/arm: Convert T16, load (literal)")
Reported-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200117004618.2742-3-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agotarget/arm: Return correct IL bit in merge_syn_data_abort
Jeff Kubascik [Fri, 17 Jan 2020 14:09:31 +0000 (14:09 +0000)]
target/arm: Return correct IL bit in merge_syn_data_abort

The IL bit is set for 32-bit instructions, thus passing false
with the is_16bit parameter to syn_data_abort_with_iss() makes
a syn mask that always has the IL bit set.

Pass is_16bit as true to make the initial syn mask have IL=0,
so that the final IL value comes from or'ing template_syn.

Cc: qemu-stable@nongnu.org
Fixes: aaa1f954d4ca ("target-arm: A64: Create Instruction Syndromes for Data Aborts")
Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200117004618.2742-2-richard.henderson@linaro.org
[rth: Extracted this as a self-contained bug fix from a larger patch]
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoarm/gicv3: update virtual irq state after IAR register read
Jeff Kubascik [Fri, 17 Jan 2020 14:09:31 +0000 (14:09 +0000)]
arm/gicv3: update virtual irq state after IAR register read

The IAR0/IAR1 register is used to acknowledge an interrupt - a read of the
register activates the highest priority pending interrupt and provides its
interrupt ID. Activating an interrupt can change the CPU's virtual interrupt
state - this change makes sure the virtual irq state is updated.

Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200113154607.97032-1-jeff.kubascik@dornerworks.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agotarget/arm: adjust program counter for wfi exception in AArch32
Jeff Kubascik [Fri, 17 Jan 2020 14:09:31 +0000 (14:09 +0000)]
target/arm: adjust program counter for wfi exception in AArch32

The wfi instruction can be configured to be trapped by a higher exception
level, such as the EL2 hypervisor. When the instruction is trapped, the
program counter should contain the address of the wfi instruction that
caused the exception. The program counter is adjusted for this in the wfi op
helper function.

However, this correction is done to env->pc, which only applies to AArch64
mode. For AArch32, the program counter is stored in env->regs[15]. This
adds an if-else statement to modify the correct program counter location
based on the the current CPU mode.

Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoi.MX: add an emulation for RNGC
Martin Kaiser [Fri, 17 Jan 2020 14:09:31 +0000 (14:09 +0000)]
i.MX: add an emulation for RNGC

Add an emulation for the RNGC random number generator and the compatible
RNGB variant. These peripherals are included (at least) in imx25 and
imx35 chipsets.

The emulation supports the initial self test, reseeding the prng and
reading random numbers.

Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agotarget/arm/arm-semi: fix SYS_OPEN to return nonzero filehandle
Masahiro Yamada [Fri, 17 Jan 2020 14:09:30 +0000 (14:09 +0000)]
target/arm/arm-semi: fix SYS_OPEN to return nonzero filehandle

According to the specification "Semihosting for AArch32 and Aarch64",
the SYS_OPEN operation should return:

 - A nonzero handle if the call is successful
 - -1 if the call is not successful

So, it should never return 0.

Prior to commit 35e9a0a8ce4b ("target/arm/arm-semi: Make semihosting
code hand out its own file descriptors"), the guest fd matched to the
host fd. It returned a nonzero handle on success since the fd 0 is
already used for stdin.

Now that the guest fd is the index of guestfd_array, it starts from 0.

I noticed this issue particularly because Trusted Firmware-A built with
PLAT=qemu is no longer working. Its io_semihosting driver only handles
a positive return value as a valid filehandle.

Basically, there are two ways to fix this:

  - Use (guestfd - 1) as the index of guestfs_arrary. We need to insert
    increment/decrement to convert the guestfd and the array index back
    and forth.

  - Keep using guestfd as the index of guestfs_array. The first entry
    of guestfs_array is left unused.

I thought the latter is simpler. We end up with wasting a small piece
of memory for the unused first entry of guestfd_array, but this is
probably not a big deal.

Fixes: 35e9a0a8ce4b ("target/arm/arm-semi: Make semihosting code hand out its own file descriptors")
Cc: qemu-stable@nongnu.org
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200109041228.10131-1-masahiroy@kernel.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agohw/arm/allwinner-a10: Remove local qemu_irq variables
Philippe Mathieu-Daudé [Fri, 17 Jan 2020 14:09:30 +0000 (14:09 +0000)]
hw/arm/allwinner-a10: Remove local qemu_irq variables

We won't reuse the CPU IRQ/FIQ variables. Simplify by calling
qdev_get_gpio_in() in place.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20191230110953.25496-6-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
4 years agohw/arm/allwinner-a10: Simplify by passing IRQs with qdev_pass_gpios()
Philippe Mathieu-Daudé [Fri, 17 Jan 2020 14:09:30 +0000 (14:09 +0000)]
hw/arm/allwinner-a10: Simplify by passing IRQs with qdev_pass_gpios()

By calling qdev_pass_gpios() we don't need to hold a copy of the
IRQs from the INTC into the SoC state.
Instead of filling an array of qemu_irq and passing it around, we
can now directly call qdev_get_gpio_in() on the SoC.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20191230110953.25496-5-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
4 years agohw/arm/allwinner-a10: Move SoC definitions out of header
Philippe Mathieu-Daudé [Fri, 17 Jan 2020 14:09:30 +0000 (14:09 +0000)]
hw/arm/allwinner-a10: Move SoC definitions out of header

These definitions are specific to the A10 SoC and don't need
to be exported to the different Allwinner peripherals.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20191230110953.25496-4-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
4 years agotests/boot_linux_console: Add a SD card test for the CubieBoard
Philippe Mathieu-Daudé [Fri, 17 Jan 2020 14:09:30 +0000 (14:09 +0000)]
tests/boot_linux_console: Add a SD card test for the CubieBoard

The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://docs.armbian.com/Developer-Guide_Build-Preparation/

The cpio image used comes from the linux-build-test project:
https://github.com/groeck/linux-build-test

If ARM is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:arm" tags.

Alternatively, this test can be run using:

  $ avocado --show=console run -t machine:cubieboard tests/acceptance/boot_linux_console.py
  console: Uncompressing Linux... done, booting the kernel.
  console: Booting Linux on physical CPU 0x0
  console: Linux version 4.20.7-sunxi (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 09:02:10 CET 2019
  [...]
  console: ahci-sunxi 1c18000.sata: Linked as a consumer to regulator.4
  console: ahci-sunxi 1c18000.sata: controller can't do 64bit DMA, forcing 32bit
  console: ahci-sunxi 1c18000.sata: AHCI 0001.0000 32 slots 1 ports 1.5 Gbps 0x1 impl platform mode
  console: ahci-sunxi 1c18000.sata: flags: ncq only
  console: scsi host0: ahci-sunxi
  console: ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 27
  console: of_cfs_init
  console: of_cfs_init: OK
  console: vcc3v0: disabling
  console: vcc5v0: disabling
  console: usb1-vbus: disabling
  console: usb2-vbus: disabling
  console: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  console: ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
  console: ata1.00: 40960 sectors, multi 16: LBA48 NCQ (depth 32)
  console: ata1.00: applying bridge limits
  console: ata1.00: configured for UDMA/100
  console: scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK    2.5+ PQ: 0 ANSI: 5
  console: sd 0:0:0:0: Attached scsi generic sg0 type 0
  console: sd 0:0:0:0: [sda] 40960 512-byte logical blocks: (21.0 MB/20.0 MiB)
  console: sd 0:0:0:0: [sda] Write Protect is off
  console: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
  console: sd 0:0:0:0: [sda] Attached SCSI disk
  console: EXT4-fs (sda): mounting ext2 file system using the ext4 subsystem
  console: EXT4-fs (sda): mounted filesystem without journal. Opts: (null)
  console: VFS: Mounted root (ext2 filesystem) readonly on device 8:0.
  [...]
  console: cat /proc/partitions
  console: / # cat /proc/partitions
  console: major minor  #blocks  name
  console: 1        0       4096 ram0
  console: 1        1       4096 ram1
  console: 1        2       4096 ram2
  console: 1        3       4096 ram3
  console: 8        0      20480 sda
  console: reboot
  console: / # reboot
  [...]
  console: sd 0:0:0:0: [sda] Synchronizing SCSI cache
  console: reboot: Restarting system
  PASS (48.39 s)

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20191230110953.25496-3-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agotests/boot_linux_console: Add initrd test for the CubieBoard
Philippe Mathieu-Daudé [Fri, 17 Jan 2020 14:09:29 +0000 (14:09 +0000)]
tests/boot_linux_console: Add initrd test for the CubieBoard

This test boots a Linux kernel on a CubieBoard and verify
the serial output is working.

The kernel image and DeviceTree blob are built by the Armbian
project (based on Debian):
https://docs.armbian.com/Developer-Guide_Build-Preparation/

The cpio image used comes from the linux-build-test project:
https://github.com/groeck/linux-build-test

If ARM is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:arm" tags.

Alternatively, this test can be run using:

  $ avocado --show=console run -t machine:cubieboard tests/acceptance/boot_linux_console.py
  console: Uncompressing Linux... done, booting the kernel.
  console: Booting Linux on physical CPU 0x0
  console: Linux version 4.20.7-sunxi (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 09:02:10 CET 2019
  console: CPU: ARMv7 Processor [410fc080] revision 0 (ARMv7), cr=50c5387d
  console: CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
  console: OF: fdt: Machine model: Cubietech Cubieboard
  [...]
  console: Boot successful.
  console: cat /proc/cpuinfo
  console: / # cat /proc/cpuinfo
  console: processor      : 0
  console: model name     : ARMv7 Processor rev 0 (v7l)
  console: BogoMIPS       : 832.51
  [...]
  console: Hardware       : Allwinner sun4i/sun5i Families
  console: Revision       : 0000
  console: Serial         : 0000000000000000
  console: cat /proc/iomem
  console: / # cat /proc/iomem
  console: 01c00000-01c0002f : system-control@1c00000
  console: 01c02000-01c02fff : dma-controller@1c02000
  console: 01c05000-01c05fff : spi@1c05000
  console: 01c0b080-01c0b093 : mdio@1c0b080
  console: 01c0c000-01c0cfff : lcd-controller@1c0c000
  console: 01c0d000-01c0dfff : lcd-controller@1c0d000
  console: 01c0f000-01c0ffff : mmc@1c0f000
  [...]
  PASS (54.35 s)

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Tested-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-id: 20191230110953.25496-2-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agohw/arm: Add the Netduino Plus 2
Alistair Francis [Fri, 17 Jan 2020 14:09:29 +0000 (14:09 +0000)]
hw/arm: Add the Netduino Plus 2

Signed-off-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: dad8d8d47f7625913e35e27a1c00f603a6b08f9a.1576658572.git.alistair@alistair23.me
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agohw/arm: Add the STM32F4xx SoC
Alistair Francis [Fri, 17 Jan 2020 14:09:29 +0000 (14:09 +0000)]
hw/arm: Add the STM32F4xx SoC

Signed-off-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1d145c4c13e5fa140caf131232a6f524c88fcd72.1576658572.git.alistair@alistair23.me
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agohw/misc: Add the STM32F4xx EXTI device
Alistair Francis [Fri, 17 Jan 2020 14:09:29 +0000 (14:09 +0000)]
hw/misc: Add the STM32F4xx EXTI device

Signed-off-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: ef941d59fd8658589d34ed432e1d6dfdcf7fb1d0.1576658572.git.alistair@alistair23.me
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agohw/misc: Add the STM32F4xx Sysconfig device
Alistair Francis [Fri, 17 Jan 2020 14:09:29 +0000 (14:09 +0000)]
hw/misc: Add the STM32F4xx Sysconfig device

Signed-off-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 49b01423a09cef2ca832ff73a84a996568f1a8fc.1576658572.git.alistair@alistair23.me
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoMerge remote-tracking branch 'remotes/rth/tags/pull-or1k-20200116' into staging
Peter Maydell [Fri, 17 Jan 2020 13:09:00 +0000 (13:09 +0000)]
Merge remote-tracking branch 'remotes/rth/tags/pull-or1k-20200116' into staging

Fix FPSCR masking

# gpg: Signature made Fri 17 Jan 2020 00:51:41 GMT
# gpg:                using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg:                issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A  05C0 64DF 38E8 AF7E 215F

* remotes/rth/tags/pull-or1k-20200116:
  target/openrisc: Fix FPCSR mask to allow setting DZF

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoMerge remote-tracking branch 'remotes/rth/tags/pull-tcg-20200115' into staging
Peter Maydell [Fri, 17 Jan 2020 12:13:17 +0000 (12:13 +0000)]
Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20200115' into staging

Add cpu_{ld,st}*_mmuidx_ra
Remove MMU_MODE*_SUFFIX
Move tcg headers under include/

# gpg: Signature made Thu 16 Jan 2020 01:36:41 GMT
# gpg:                using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg:                issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A  05C0 64DF 38E8 AF7E 215F

* remotes/rth/tags/pull-tcg-20200115: (34 commits)
  MAINTAINERS: Replace Claudio Fontana for tcg/aarch64
  configure: Remove tcg/ from the preprocessor include search list
  tcg: Move TCG headers to include/tcg/
  tcg: Search includes in the parent source directory
  tcg: Search includes from the project root source directory
  cputlb: Expand cpu_ldst_template.h in cputlb.c
  cputlb: Remove support for MMU_MODE*_SUFFIX
  target/ppc: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
  target/s390x: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
  target/mips: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
  target/m68k: Use cpu_*_mmuidx_ra instead of MMU_MODE{0,1}_SUFFIX
  target/xtensa: Remove MMU_MODE{0,1,2,3}_SUFFIX
  target/unicore32: Remove MMU_MODE{0,1}_SUFFIX
  target/sh4: Remove MMU_MODE{0,1}_SUFFIX
  target/microblaze: Remove MMU_MODE{0,1,2}_SUFFIX
  target/i386: Remove MMU_MODE{0,1,2}_SUFFIX
  target/cris: Remove MMU_MODE{0,1}_SUFFIX
  target/alpha: Remove MMU_MODE{0,1}_SUFFIX
  target/nios2: Remove MMU_MODE{0,1}_SUFFIX
  cputlb: Expand cpu_ldst_useronly_template.h in user-exec.c
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agotarget/openrisc: Fix FPCSR mask to allow setting DZF
Stafford Horne [Fri, 10 Jan 2020 21:28:43 +0000 (06:28 +0900)]
target/openrisc: Fix FPCSR mask to allow setting DZF

The mask used when setting FPCSR allows setting bits 10 to 1.  However,
OpenRISC has flags and config bits in 11 to 1, 11 being Divide by Zero
Flag (DZF).  This seems like an off-by-one bug.

This was found when testing the GLIBC test suite which has test cases to
set and clear all bits.

Signed-off-by: Stafford Horne <shorne@gmail.com>
Message-Id: <20200110212843.27335-1-shorne@gmail.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agogitlab-ci.yml: Run tcg test with tci
Thomas Huth [Thu, 26 Sep 2019 15:51:57 +0000 (17:51 +0200)]
gitlab-ci.yml: Run tcg test with tci

Since commit 2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add
implementation for INDEX_op_ld16u_i64") has been included now, we
can also run the TCG tests with tci, so let's enable them in our
Gitlab CI now.

Message-Id: <20191127155105.3784-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
4 years agotests/qtest/vhost-user-test: Fix memory leaks
Thomas Huth [Thu, 16 Jan 2020 14:07:36 +0000 (15:07 +0100)]
tests/qtest/vhost-user-test: Fix memory leaks

Do not allocate resources in case we return early, and make sure
to free dest_cmdline at the end.

Reported-by: Euler Robot <euler.robot@huawei.com>
Reported-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200116140736.9498-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
4 years agomigration-test: ppc64: fix FORTH test program
Laurent Vivier [Tue, 7 Jan 2020 16:34:37 +0000 (17:34 +0100)]
migration-test: ppc64: fix FORTH test program

Commit e51e711b1bef has moved the initialization of start_address and
end_address after the definition of the command line argument,
where the nvramrc is initialized, and thus the loop is between 0 and 0
rather than 1 MiB and 100 MiB.

It doesn't affect the result of the test if all the tests are run in
sequence because the two first tests don't run the loop, so the
values are correctly initialized when we actually need them.

But it hangs when we ask to run only one test, for instance:

    QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 \
    tests/migration-test -m=quick -p /ppc64/migration/validate_uuid_error

Fixes: e51e711b1bef ("tests/migration: Add migration-test header file")
Cc: wei@redhat.com
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20200107163437.52139-1-lvivier@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Thomas Huth <thuth@redhat.com>
4 years agotests: acpi: update path in rebuild-expected-aml
Shameer Kolothum [Tue, 14 Jan 2020 16:51:38 +0000 (16:51 +0000)]
tests: acpi: update path in rebuild-expected-aml

Since commit 1e8a1fae7464("test: Move qtests to a separate
directory") qtests are now placed in a separate folder and
this breaks the script used to rebuild the expected ACPI
tables for bios-tables-test. Update the script with correct
path.

Fixes: 1e8a1fae7464("test: Move qtests to a separate directory")
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20200114165138.15716-1-shameerali.kolothum.thodi@huawei.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
4 years agoui/gtk: Get display refresh rate with GDK version 3.22 or later
Philippe Mathieu-Daudé [Thu, 16 Jan 2020 11:54:13 +0000 (12:54 +0100)]
ui/gtk: Get display refresh rate with GDK version 3.22 or later

Commit c4c00922cc introduced the use of the GdkMonitor API, which
was introduced in GTK+ 3.22:
https://developer.gnome.org/gdk3/stable/api-index-3-22.html#api-index-3.22

Unfortunately this break building with older versions, as on Ubuntu
Xenial which provides GTK+ 3.18:

  $ lsb_release -cd
  Description:    Ubuntu 16.04.5 LTS
  Codename:       xenial

  $ ./configure && make
  GTK support       yes (3.18.9)
  GTK GL support    no
  [...]
    CC      ui/gtk.o
  qemu/ui/gtk.c: In function ‘gd_vc_gfx_init’:
  qemu/ui/gtk.c:1973:5: error: unknown type name ‘GdkMonitor’
       GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
       ^
  qemu/ui/gtk.c:1973:27: error: implicit declaration of function ‘gdk_display_get_monitor_at_window’ [-Werror=implicit-function-declaration]
       GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
                             ^
  qemu/ui/gtk.c:1973:5: error: nested extern declaration of ‘gdk_display_get_monitor_at_window’ [-Werror=nested-externs]
       GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
       ^
  qemu/ui/gtk.c:1973:27: error: initialization makes pointer from integer without a cast [-Werror=int-conversion]
       GdkMonitor *monitor = gdk_display_get_monitor_at_window(dpy, win);
                             ^
  qemu/ui/gtk.c:2035:28: error: implicit declaration of function ‘gdk_monitor_get_refresh_rate’ [-Werror=implicit-function-declaration]
       refresh_rate_millihz = gdk_monitor_get_refresh_rate(monitor);
                              ^
  qemu/ui/gtk.c:2035:5: error: nested extern declaration of ‘gdk_monitor_get_refresh_rate’ [-Werror=nested-externs]
       refresh_rate_millihz = gdk_monitor_get_refresh_rate(monitor);
       ^
  cc1: all warnings being treated as errors
  qemu/rules.mak:69: recipe for target 'ui/gtk.o' failed
  make: *** [ui/gtk.o] Error 1

GTK+ provides convenient definition in <gdk/gdkversionmacros.h>
(already include by <gdk/gdk.h>) to check which API are available.

We only use the GdkMonitor API to get the monitor refresh rate.

Extract this code as a new gd_refresh_rate_millihz() function,
and check GDK_VERSION_3_22 is defined before calling its API.
If it is not defined, return 0. This is safe and fixes our build
failure (see https://travis-ci.org/qemu/qemu/builds/636992508).

Reported-by: Travis-CI
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200116115413.31650-1-philmd@redhat.com
Fixes: c4c00922cc (display/gtk: get proper refreshrate)
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
4 years agoMAINTAINERS: Replace Claudio Fontana for tcg/aarch64
Richard Henderson [Mon, 6 Jan 2020 06:30:37 +0000 (16:30 +1000)]
MAINTAINERS: Replace Claudio Fontana for tcg/aarch64

Claudio's Huawei address has been defunct for quite a while.  In

  https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg06872.html

he asked for his personal address to be removed as well.

I will take over officially.

Cc: Claudio Fontana <claudio.fontana@gmail.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agoconfigure: Remove tcg/ from the preprocessor include search list
Philippe Mathieu-Daudé [Wed, 1 Jan 2020 11:23:03 +0000 (12:23 +0100)]
configure: Remove tcg/ from the preprocessor include search list

All tcg includes are relative to the repository root directory,
we can safely remove the tcg/ directory from the include search
path list.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200101112303.20724-5-philmd@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotcg: Move TCG headers to include/tcg/
Philippe Mathieu-Daudé [Wed, 1 Jan 2020 11:23:02 +0000 (12:23 +0100)]
tcg: Move TCG headers to include/tcg/

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200101112303.20724-4-philmd@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotcg: Search includes in the parent source directory
Philippe Mathieu-Daudé [Wed, 1 Jan 2020 11:23:01 +0000 (12:23 +0100)]
tcg: Search includes in the parent source directory

All the *.inc.c files included by tcg/$TARGET/tcg-target.inc.c
are in tcg/, their parent directory. To simplify the preprocessor
search path, include the relative parent path: '..'.

Patch created mechanically by running:

  $ for x in tcg-pool.inc.c tcg-ldst.inc.c; do \
    sed -i "s,#include \"$x\",#include \"../$x\"," \
      $(git grep -l "#include \"$x\""); \
    done

Acked-by: David Gibson <david@gibson.dropbear.id.au> (ppc parts)
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200101112303.20724-3-philmd@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotcg: Search includes from the project root source directory
Philippe Mathieu-Daudé [Wed, 1 Jan 2020 11:23:00 +0000 (12:23 +0100)]
tcg: Search includes from the project root source directory

We currently search both the root and the tcg/ directories for tcg
files:

  $ git grep '#include "tcg/' | wc -l
  28

  $ git grep '#include "tcg[^/]' | wc -l
  94

To simplify the preprocessor search path, unify by expliciting the
tcg/ directory.

Patch created mechanically by running:

  $ for x in \
      tcg.h tcg-mo.h tcg-op.h tcg-opc.h \
      tcg-op-gvec.h tcg-gvec-desc.h; do \
    sed -i "s,#include \"$x\",#include \"tcg/$x\"," \
      $(git grep -l "#include \"$x\""); \
    done

Acked-by: David Gibson <david@gibson.dropbear.id.au> (ppc parts)
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200101112303.20724-2-philmd@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agocputlb: Expand cpu_ldst_template.h in cputlb.c
Richard Henderson [Wed, 11 Dec 2019 18:33:26 +0000 (10:33 -0800)]
cputlb: Expand cpu_ldst_template.h in cputlb.c

Reduce the amount of preprocessor obfuscation by expanding
the text of each of the functions generated.  The result is
only slightly smaller than the original.

Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agocputlb: Remove support for MMU_MODE*_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 20:30:46 +0000 (12:30 -0800)]
cputlb: Remove support for MMU_MODE*_SUFFIX

All users have now been converted to cpu_*_mmuidx_ra.

Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotarget/ppc: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 20:27:21 +0000 (12:27 -0800)]
target/ppc: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX

There are only two uses.  Within dcbz_common, the local variable
mmu_idx already contains the epid computation, and we can avoid
repeating it for the store.  Within helper_icbiep, the usage is
trivially expanded using PPC_TLB_EPID_LOAD.

Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotarget/s390x: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 19:43:42 +0000 (11:43 -0800)]
target/s390x: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX

The generated functions aside from *_real are unused.
The *_real functions have a couple of users in mem_helper.c;
use *_mmuidx_ra instead, with MMU_REAL_IDX.

Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
v2: Use *_mmuidx_ra directly, without intermediate macros.

4 years agotarget/mips: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 19:16:29 +0000 (11:16 -0800)]
target/mips: Use cpu_*_mmuidx_ra instead of MMU_MODE*_SUFFIX

The separate suffixed functions were used to construct
some do_##insn function switched on mmu_idx.  The interface
is exactly identical to the *_mmuidx_ra functions.  Replace
them directly and remove the constructions.

Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Aleksandar Rikalo <aleksandar.rikalo@rt-rk.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotarget/m68k: Use cpu_*_mmuidx_ra instead of MMU_MODE{0,1}_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 18:49:16 +0000 (10:49 -0800)]
target/m68k: Use cpu_*_mmuidx_ra instead of MMU_MODE{0,1}_SUFFIX

The generated *_user functions are unused.  The *_kernel functions
have a couple of users in op_helper.c; use *_mmuidx_ra instead,
with MMU_KERNEL_IDX.

Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
v2: Use *_mmuidx_ra directly, without intermediate macros.

4 years agotarget/xtensa: Remove MMU_MODE{0,1,2,3}_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 18:24:06 +0000 (10:24 -0800)]
target/xtensa: Remove MMU_MODE{0,1,2,3}_SUFFIX

The functions generated by these macros are unused.

Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotarget/unicore32: Remove MMU_MODE{0,1}_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 18:22:22 +0000 (10:22 -0800)]
target/unicore32: Remove MMU_MODE{0,1}_SUFFIX

The functions generated by these macros are unused.

Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotarget/sh4: Remove MMU_MODE{0,1}_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 18:21:26 +0000 (10:21 -0800)]
target/sh4: Remove MMU_MODE{0,1}_SUFFIX

The functions generated by these macros are unused.

Cc: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotarget/microblaze: Remove MMU_MODE{0,1,2}_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 18:18:19 +0000 (10:18 -0800)]
target/microblaze: Remove MMU_MODE{0,1,2}_SUFFIX

The functions generated by these macros are unused.

Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
4 years agotarget/i386: Remove MMU_MODE{0,1,2}_SUFFIX
Richard Henderson [Tue, 10 Dec 2019 18:15:57 +0000 (10:15 -0800)]
target/i386: Remove MMU_MODE{0,1,2}_SUFFIX

The functions generated by these macros are unused.

Cc: Eduardo Habkost <ehabkost@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>