Peter Maydell [Fri, 14 Jun 2019 10:44:57 +0000 (11:44 +0100)]
target/arm: Only implement doubles if the FPU supports them
The architecture permits FPUs which have only single-precision
support, not double-precision; Cortex-M4 and Cortex-M33 are
both like that. Add the necessary checks on the MVFR0 FPDP
field so that we UNDEF any double-precision instructions on
CPUs like this.
Note that even if FPDP==0 the insns like VMOV-to/from-gpreg,
VLDM/VSTM, VLDR/VSTR which take double precision registers
still exist.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190614104457.24703-3-peter.maydell@linaro.org
Peter Maydell [Fri, 14 Jun 2019 10:44:56 +0000 (11:44 +0100)]
target/arm: Fix typos in trans function prototypes
In several places cut and paste errors meant we were using the wrong
type for the 'arg' struct in trans_ functions called by the
decodetree decoder, because we were using the _sp version of the
struct in the _dp function. These were harmless, because the two
structs were identical and so decodetree made them typedefs of the
same underlying structure (and we'd have had a compile error if they
were not harmless), but we should clean them up anyway.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190614104457.24703-2-peter.maydell@linaro.org
Remove the now unused TCG globals cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d.
cpu_M0 is still used by the iwmmxt code, and cpu_V0 and
cpu_V1 are used by both iwmmxt and Neon.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-13-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:16 +0000 (17:39 +0100)]
target/arm: Stop using deprecated functions in NEON_2RM_VCVT_F32_F16
Remove some old constructns from NEON_2RM_VCVT_F16_F32 code:
* don't use CPU_F0s
* don't use tcg_gen_st_f32
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-12-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:15 +0000 (17:39 +0100)]
target/arm: stop using deprecated functions in NEON_2RM_VCVT_F16_F32
Remove some old constructs from NEON_2RM_VCVT_F16_F32 code:
* don't use cpu_F0s
* don't use tcg_gen_ld_f32
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-11-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:14 +0000 (17:39 +0100)]
target/arm: Stop using cpu_F0s in Neon VCVT fixed-point ops
Stop using cpu_F0s in the Neon VCVT fixed-point operations.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-10-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:13 +0000 (17:39 +0100)]
target/arm: Stop using cpu_F0s for Neon f32/s32 VCVT
Stop using cpu_F0s for the Neon f32/s32 VCVT operations.
Since this is the last user of cpu_F0s in the Neon 2rm-op
loop, we can remove the handling code for it too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-9-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:12 +0000 (17:39 +0100)]
target/arm: Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F
Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-8-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:11 +0000 (17:39 +0100)]
target/arm: Stop using cpu_F0s for NEON_2RM_VCVT[ANPM][US]
Stop using cpu_F0s for the NEON_2RM_VCVT[ANPM][US] ops.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-7-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:10 +0000 (17:39 +0100)]
target/arm: Stop using cpu_F0s for NEON_2RM_VRINT*
Switch NEON_2RM_VRINT* away from using cpu_F0s.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-6-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:09 +0000 (17:39 +0100)]
target/arm: Stop using cpu_F0s for NEON_2RM_VNEG_F
Switch NEON_2RM_VABS_F away from using cpu_F0s.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-5-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:08 +0000 (17:39 +0100)]
target/arm: Stop using cpu_F0s for NEON_2RM_VABS_F
Where Neon instructions are floating point operations, we
mostly use the old VFP utility functions like gen_vfp_abs()
which work on the TCG globals cpu_F0s and cpu_F1s. The
Neon for-each-element loop conditionally loads the inputs
into either a plain old TCG temporary for most operations
or into cpu_F0s for float operations, and similarly stores
back either cpu_F0s or the temporary.
Switch NEON_2RM_VABS_F away from using cpu_F0s, and
update neon_2rm_is_float_op() accordingly.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-4-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:07 +0000 (17:39 +0100)]
target/arm: Use vfp_expand_imm() for AArch32 VFP VMOV_imm
The AArch32 VMOV (immediate) instruction uses the same VFP encoded
immediate format we already handle in vfp_expand_imm(). Use that
function rather than hand-decoding it.
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-3-peter.maydell@linaro.org
Peter Maydell [Thu, 13 Jun 2019 16:39:06 +0000 (17:39 +0100)]
target/arm: Move vfp_expand_imm() to translate.[ch]
We want to use vfp_expand_imm() in the AArch32 VFP decode;
move it from the a64-only header/source file to the
AArch32 one (which is always compiled even for AArch64).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190613163917.28589-2-peter.maydell@linaro.org
Peter Maydell [Fri, 24 May 2019 12:42:48 +0000 (13:42 +0100)]
hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1
The GICv3 specification says that the GICD_TYPER.SecurityExtn bit
is RAZ if GICD_CTLR.DS is 1. We were incorrectly making it RAZ
if the security extension is unsupported. "Security extension
unsupported" always implies GICD_CTLR.DS == 1, but the guest can
also set DS on a GIC which does support the security extension.
Fix the condition to correctly check the GICD_CTLR.DS bit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20190524124248.28394-3-peter.maydell@linaro.org
Peter Maydell [Fri, 24 May 2019 12:42:47 +0000 (13:42 +0100)]
hw/intc/arm_gicv3: Fix decoding of ID register range
The GIC ID registers cover an area 0x30 bytes in size
(12 registers, 4 bytes each). We were incorrectly decoding
only the first 0x20 bytes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190524124248.28394-2-peter.maydell@linaro.org
Peter Maydell [Fri, 17 May 2019 17:40:46 +0000 (18:40 +0100)]
hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boards
The SSE-200 hardware has configurable integration settings which
determine whether its two CPUs have the FPU and DSP:
* CPU0_FPU (default 0)
* CPU0_DSP (default 0)
* CPU1_FPU (default 1)
* CPU1_DSP (default 1)
Similarly, the IoTKit has settings for its single CPU:
* CPU0_FPU (default 1)
* CPU0_DSP (default 1)
Of our four boards that use either the IoTKit or the SSE-200:
* mps2-an505, mps2-an521 and musca-a use the default settings
* musca-b1 enables FPU and DSP on both CPUs
Currently QEMU models all these boards using CPUs with
both FPU and DSP enabled. This means that we are incorrect
for mps2-an521 and musca-a, which should not have FPU or DSP
on CPU0.
Create QOM properties on the ARMSSE devices corresponding to the
default h/w integration settings, and make the Musca-B1 board
enable FPU and DSP on both CPUs. This fixes the mps2-an521
and musca-a behaviour, and leaves the musca-b1 and mps2-an505
behaviour unchanged.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-5-peter.maydell@linaro.org
Peter Maydell [Fri, 17 May 2019 17:40:45 +0000 (18:40 +0100)]
hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPU
Create "vfp" and "dsp" properties on the armv7m container object
which will be forwarded to its CPU object, so that SoCs can
configure whether the CPU has these features.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-4-peter.maydell@linaro.org
Peter Maydell [Fri, 17 May 2019 17:40:44 +0000 (18:40 +0100)]
target/arm: Allow M-profile CPUs to disable the DSP extension via CPU property
Allow the DSP extension to be disabled via a CPU property for
M-profile CPUs. (A and R-profile CPUs don't have this extension
as a defined separate optional architecture extension, so
they don't need the property.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-3-peter.maydell@linaro.org
Peter Maydell [Fri, 17 May 2019 17:40:43 +0000 (18:40 +0100)]
target/arm: Allow VFP and Neon to be disabled via a CPU property
Allow VFP and neon to be disabled via a CPU property. As with
the "pmu" property, we only allow these features to be removed
from CPUs which have it by default, not added to CPUs which
don't have it.
The primary motivation here is to be able to optionally
create Cortex-M33 CPUs with no FPU, but we provide switches
for both VFP and Neon because the two interact:
* AArch64 can't have one without the other
* Some ID register fields only change if both are disabled
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20190517174046.11146-2-peter.maydell@linaro.org
Peter Maydell [Thu, 16 May 2019 14:47:33 +0000 (15:47 +0100)]
hw/arm/boot: Honour image size field in AArch64 Image format kernels
Since Linux v3.17, the kernel's Image header includes a field image_size,
which gives the total size of the kernel including unpopulated data
sections such as the BSS). If this is present, then return it from
load_aarch64_image() as the true size of the kernel rather than
just using the size of the Image file itself. This allows the code
which calculates where to put the initrd to avoid putting it in
the kernel's BSS area.
This means that we should be able to reliably load kernel images
which are larger than 128MB without accidentally putting the
initrd or dtb in locations that clash with the kernel itself.
Fixes: https://bugs.launchpad.net/qemu/+bug/1823998 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-5-peter.maydell@linaro.org
Peter Maydell [Thu, 16 May 2019 14:47:32 +0000 (15:47 +0100)]
hw/arm/boot: Avoid placing the initrd on top of the kernel
We currently put the initrd at the smaller of:
* 128MB into RAM
* halfway into the RAM
(with the dtb following it).
However for large kernels this might mean that the kernel
overlaps the initrd. For some kinds of kernel (self-decompressing
32-bit kernels, and ELF images with a BSS section at the end)
we don't know the exact size, but even there we have a
minimum size. Put the initrd at least further into RAM than
that. For image formats that can give us an exact kernel size, this
will mean that we definitely avoid overlaying kernel and initrd.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-4-peter.maydell@linaro.org
Peter Maydell [Thu, 16 May 2019 14:47:31 +0000 (15:47 +0100)]
hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAM
We calculate the locations in memory where we want to put the
initrd and the DTB based on the size of the kernel, since they
come after it. Add some explicit checks that these aren't off the
end of RAM entirely.
(At the moment the way we calculate the initrd_start means that
it can't ever be off the end of RAM, but that will change with
the next commit.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-3-peter.maydell@linaro.org
Peter Maydell [Thu, 16 May 2019 14:47:30 +0000 (15:47 +0100)]
hw/arm/boot: Don't assume RAM starts at address zero
In the Arm kernel/initrd loading code, in some places we make the
incorrect assumption that info->ram_size can be treated as the
address of the end of RAM, as for instance when we calculate the
available space for the initrd using "info->ram_size - info->initrd_start".
This is wrong, because many Arm boards (including "virt") specify
a non-zero info->loader_start to indicate that their RAM area
starts at a non-zero physical address.
Correct the places which make this incorrect assumption.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-2-peter.maydell@linaro.org
# gpg: Signature made Fri 14 Jun 2019 21:09:29 BST
# gpg: using RSA key D39DA71E0D496CFA
# gpg: Good signature from "Laszlo Ersek <lersek@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: F5D9 660F 1BA5 F310 A95A C5E0 466A EAE0 6125 3988
# Subkey fingerprint: B3A5 5D3F 88A8 90ED 2E63 3E8D D39D A71E 0D49 6CFA
* remotes/lersek/tags/edk2-pull-2019-06-14:
pc-bios: update the README file with edk2-stable201905 information
pc-bios: refresh edk2 build artifacts for edk2-stable201905
roms/Makefile.edk2: update input file list for "pc-bios/edk2-licenses.txt"
roms/Makefile.edk2: remove edk2-stable201903 network feature test macros
roms/edk2: update submodule from edk2-stable201903 to edk2-stable201905
roms/Makefile.edk2: define edk2-stable201905 network feature test macros
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Gerd Hoffmann [Fri, 7 Jun 2019 07:34:29 +0000 (09:34 +0200)]
q35: fix mmconfig and PCI0._CRS
This patch changes the handling of the mmconfig area. Thanks to the
pci(e) expander devices we already have the logic to exclude address
ranges from PCI0._CRS. We can simply add the mmconfig address range
to the list get it excluded as well.
With that in place we can go with a fixed pci hole which covers the
whole area from the end of (low) ram to the ioapic.
This will make the whole logic alot less fragile. No matter where the
firmware places the mmconfig xbar, things should work correctly. The
guest also gets a bit more PCI address space (seabios boot):
Cc: László Érsek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20190607073429.3436-1-kraxel@redhat.com>
Wei Yang [Mon, 10 Jun 2019 01:18:30 +0000 (09:18 +0800)]
hw/acpi: extract acpi_add_rom_blob()
arm and i386 has almost the same function acpi_add_rom_blob(), except
giving different FWCfgCallback function.
This patch moves acpi_add_rom_blob() to utils.c by passing
FWCfgCallback to it.
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
v7:
* rebase on top of current master because of conflict
v6:
* change author from Igor to Michael
v5:
* remove unnecessary header glib/gprintf.h
* rearrange include header to make it more suitable
v4:
* extract -> moves
* adjust comment in source to make checkpatch happy
v3:
* put acpi_add_rom_blob() to hw/acpi/utils.c
v2:
* remove unused header in original source file
Message-Id: <20190610011830.28398-1-richardw.yang@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Li Hangjing [Mon, 3 Jun 2019 06:15:24 +0000 (14:15 +0800)]
vhost: fix vhost_log size overflow during migration
When a guest which doesn't support multiqueue is migrated with a multi queues
vhost-user-blk deivce, a crash will occur like:
0 qemu_memfd_alloc (name=<value optimized out>, size=562949953421312, seals=<value optimized out>, fd=0x7f87171fe8b4, errp=0x7f87171fe8a8) at util/memfd.c:153
1 0x00007f883559d7cf in vhost_log_alloc (size=70368744177664, share=true) at hw/virtio/vhost.c:186
2 0x00007f88355a0758 in vhost_log_get (listener=0x7f8838bd7940, enable=1) at qemu-2-12/hw/virtio/vhost.c:211
3 vhost_dev_log_resize (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:263
4 vhost_migration_log (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:787
5 0x00007f88355463d6 in memory_global_dirty_log_start () at memory.c:2503
6 0x00007f8835550577 in ram_init_bitmaps (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2173
7 ram_init_all (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2192
8 ram_save_setup (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2219
9 0x00007f88357a419d in qemu_savevm_state_setup (f=0x7f88384ce600) at migration/savevm.c:1002
10 0x00007f883579fc3e in migration_thread (opaque=0x7f8837530400) at migration/migration.c:2382
11 0x00007f8832447893 in start_thread () from /lib64/libpthread.so.0
12 0x00007f8832178bfd in clone () from /lib64/libc.so.6
This is because vhost_get_log_size() returns a overflowed vhost-log size.
In this function, it uses the uninitialized variable vqs->used_phys and
vqs->used_size to get the vhost-log size.
Signed-off-by: Li Hangjing <lihangjing@baidu.com> Reviewed-by: Xie Yongji <xieyongji@baidu.com> Reviewed-by: Chai Wen <chaiwen@baidu.com>
Message-Id: <20190603061524.24076-1-lihangjing@baidu.com> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
docs/vhost-user.json: some firmware.json copy leftovers
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605131221.29432-1-marcandre.lureau@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>
vhost-user-gpu: initialize msghdr & iov at declaration
This should fix uninitialized fields found by coverity CID 1401762.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-6-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-5-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-4-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This check shouldn't be necessary, since &error_fatal is given as
argument and will exit() on failure. However, this change should
silence coverity CID 1401761 & 1401705.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-3-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-2-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Laszlo Ersek [Thu, 6 Jun 2019 10:49:02 +0000 (12:49 +0200)]
pc-bios: update the README file with edk2-stable201905 information
Refresh the "pc-bios/README" file with edk2, OpenSSL, and Berkeley
SoftFloat release info, matching the edk2-stable201905 firmware images
added in the previous patch.
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Edk2 commit f53de8aecb12 ("edk2: Add License-History.txt", 2019-04-09)
added a new file called "License-History.txt", describing license and
contributor agreement changes over time.
(2) For advacing edk2's OpenSSL git submodule to the 1.1.1b release, a
more up-to-date ArmSoftFloatLib instance became necessary, on 32-bit
ARM. Therefore, the embedded (and by now, obsolete) Berkeley SoftFloat
library was replaced with a git submodule of the same, checked out at
the latest release ("3e", plus a typo fix on top -- commit b64af41c3276). This was implemented for TianoCore Bugzilla
Include the edk2 project's "License-History.txt" file, and the Berkeley
SoftFloat library's "COPYING.txt", in our generated
"pc-bios/edk2-licenses.txt" text file.
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Thu, 6 Jun 2019 11:50:56 +0000 (13:50 +0200)]
roms/Makefile.edk2: remove edk2-stable201903 network feature test macros
At tag "edk2-stable201905", the build flags HTTP_BOOT_ENABLE and
TLS_ENABLE have become useless. Their roles have been taken by
NETWORK_HTTP_BOOT_ENABLE and NETWORK_TLS_ENABLE, respectively. Remove the
old build flags.
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Thu, 6 Jun 2019 09:59:09 +0000 (11:59 +0200)]
roms/Makefile.edk2: define edk2-stable201905 network feature test macros
Due to edk2 commits 631195044ff0 ("OvmfPkg: Update DSC/FDF to use
NetworkPkg's include fragment file.", 2019-05-16) and 157a3b1aa50f
("ArmVirtPkg: Update DSC/FDF to use NetworkPkg's include fragment file.",
2019-05-16), we'll have to pefix the HTTP_BOOT_ENABLE and TLS_ENABLE build
flags with "NETWORK_", for building edk2 at tag "edk2-stable201905".
Right now the new flags are no-ops, so we can insert them separately,
before advancing our edk2 submodule reference. We will remove the old
flags afterwards.
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Peter Maydell [Fri, 14 Jun 2019 13:46:13 +0000 (14:46 +0100)]
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-06-14' into staging
Block patches:
- Allow blockdev-backup from nodes that are not in qemu's main AIO
context to newly added nodes
- Add salvaging mode to qemu-img convert
- Minor fixes to tests, documentation, and for less Valgrind annoyance
# gpg: Signature made Fri 14 Jun 2019 14:38:11 BST
# gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40
# gpg: issuer "mreitz@redhat.com"
# gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full]
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/maxreitz/tags/pull-block-2019-06-14:
iotests: Test qemu-img convert -C --salvage
iotests: Test qemu-img convert --salvage
blkdebug: Inject errors on .bdrv_co_block_status()
blkdebug: Add "none" event
blkdebug: Add @iotype error option
qemu-img: Add salvaging mode to convert
qemu-img: Move quiet into ImgConvertState
blockdev: Overlays are not snapshots
qapi/block-core: Overlays are not snapshots
qemu-img: Fix options leakage in img_rebase()
iotests: restrict 254 to support only qcow2
hw/block/fdc: floppy command FIFO memory initialization
iotests: Fix intermittent failure in 219
iotests: Filter 175's allocation information
event_match: always match on None value
iotests: add iotest 256 for testing blockdev-backup across iothread contexts
iotests.py: rewrite run_job to be pickier
QEMUMachine: add events_wait method
iotests.py: do not use infinite waits
blockdev-backup: don't check aio_context too early
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Max Reitz [Tue, 7 May 2019 20:35:08 +0000 (22:35 +0200)]
iotests: Test qemu-img convert -C --salvage
We do not support this combination (yet), so this should yield an error
message.
Signed-off-by: Max Reitz <mreitz@redhat.com> Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-8-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 7 May 2019 20:35:07 +0000 (22:35 +0200)]
iotests: Test qemu-img convert --salvage
This test converts a simple image to another, but blkdebug injects
block_status and read faults at some offsets. The resulting image
should be the same as the input image, except that sectors that could
not be read have to be 0.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190507203508.18026-7-mreitz@redhat.com Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
[mreitz: Dropped superfluous printf from _filter_offsets, as suggested
by Vladimir; disable test for VDI and IMGOPTSSYNTAX] Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 7 May 2019 20:35:06 +0000 (22:35 +0200)]
blkdebug: Inject errors on .bdrv_co_block_status()
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-6-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 7 May 2019 20:35:05 +0000 (22:35 +0200)]
blkdebug: Add "none" event
Together with @iotypes and @sector, this can be used to trap e.g. the
first read or write access to a certain sector without having to know
what happens internally in the block layer, i.e. which "real" events
happen right before such an access.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 7 May 2019 20:35:04 +0000 (22:35 +0200)]
blkdebug: Add @iotype error option
This new error option allows users of blkdebug to inject errors only on
certain kinds of I/O operations. Users usually want to make a very
specific operation fail, not just any; but right now they simply hope
that the event that triggers the error injection is followed up with
that very operation. That may not be true, however, because the block
layer is changing (including blkdebug, which may increase the number of
types of I/O operations on which to inject errors).
The new option's default has been chosen to keep backwards
compatibility.
Note that similar to the internal representation, we could choose to
expose this option as a list of I/O types. But there is no practical
use for this, because as described above, users usually know exactly
which kind of operation they want to make fail, so there is no need to
specify multiple I/O types at once. In addition, exposing this option
as a list would require non-trivial changes to qemu_opts_absorb_qdict().
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 7 May 2019 20:35:03 +0000 (22:35 +0200)]
qemu-img: Add salvaging mode to convert
This adds a salvaging mode (--salvage) to qemu-img convert which ignores
read errors and treats the respective areas as containing only zeroes.
This can be used for instance to at least partially recover the data
from terminally corrupted qcow2 images.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-3-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Tue, 7 May 2019 20:35:02 +0000 (22:35 +0200)]
qemu-img: Move quiet into ImgConvertState
Move img_convert()'s quiet flag into the ImgConvertState so it is
accessible by nested functions. -q dictates that it suppresses anything
but errors, so if those functions want to emit warnings, they need to
query this flag first. (There currently are no such warnings, but there
will be as of the next patch.)
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-2-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Mon, 3 Jun 2019 20:22:36 +0000 (22:22 +0200)]
blockdev: Overlays are not snapshots
There are error messages which refer to an overlay node as the snapshot.
That is wrong, those are two different things.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20190603202236.1342-3-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Mon, 3 Jun 2019 20:22:35 +0000 (22:22 +0200)]
qapi/block-core: Overlays are not snapshots
A snapshot is something that reflects the state of something at a
certain point in time. It does not change.
The file our snapshot commands create (or the node they install) is not
a snapshot, as it does change over time. It is an overlay. We cannot
do anything about the parameter names, but we can at least adjust the
descriptions to reflect that fact.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20190603202236.1342-2-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Test fails at least for qcow, because of different cluster sizes in
base and top (and therefore different granularities of bitmaps we are
trying to merge).
The test aim is to check block-dirty-bitmap-merge between different
nodes functionality, no needs to check all formats. So, let's just drop
support for anything except qcow2.
Reported-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190605155405.104384-1-vsementsov@virtuozzo.com Signed-off-by: Max Reitz <mreitz@redhat.com>
The uninitialized memory allocated for the command FIFO of the
floppy controller during the VM hardware initialization incurs
many unwanted reports by Valgrind when VM state is being saved.
That verbosity hardens a search for the real memory issues when
the iotests run. Particularly, the patch eliminates 20 unnecessary
reports of the Valgrind tool in the iotest #169.
Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Message-id: 1559154027-282547-1-git-send-email-andrey.shinkevich@virtuozzo.com Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Max Reitz [Thu, 16 May 2019 16:11:14 +0000 (18:11 +0200)]
iotests: Fix intermittent failure in 219
In 219, we wait for the job to make progress before we emit its status.
This makes the output reliable. We do not wait for any more progress if
the job's current-progress already matches its total-progress.
Unfortunately, there is a bug: Right after the job has been started,
it's possible that total-progress is still 0. In that case, we may skip
the first progress-making step and keep ending up 64 kB short.
To fix that bug, we can simply wait for total-progress to reach 4 MB
(the image size) after starting the job.
Reported-by: Karen Mezick <kmezick@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686651 Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190516161114.27596-1-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com>
[mreitz: Adjusted commit message as per John's proposal] Signed-off-by: Max Reitz <mreitz@redhat.com>
John Snow [Tue, 28 May 2019 18:38:57 +0000 (14:38 -0400)]
event_match: always match on None value
Before, event_match didn't always recurse if the event value was not a
dictionary, and would instead check for equality immediately.
By delaying equality checking to post-recursion, we can allow leaf
values like "5" to match "None" and take advantage of the generic
None-returns-True clause.
This makes the matching a little more obviously consistent at the
expense of being able to check for explicit None values, which is
probably not that important given what this function is used for.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190528183857.26167-1-jsnow@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
John Snow [Thu, 23 May 2019 17:06:43 +0000 (13:06 -0400)]
iotests: add iotest 256 for testing blockdev-backup across iothread contexts
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-6-jsnow@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com>
[mreitz: Moved from 250 to 256] Signed-off-by: Max Reitz <mreitz@redhat.com>
John Snow [Thu, 23 May 2019 17:06:42 +0000 (13:06 -0400)]
iotests.py: rewrite run_job to be pickier
Don't pull events out of the queue that don't belong to us;
be choosier so that we can use this method to drive jobs that
were launched by transactions that may have more jobs.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-5-jsnow@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
John Snow [Thu, 23 May 2019 17:06:41 +0000 (13:06 -0400)]
QEMUMachine: add events_wait method
Instead of event_wait which looks for a single event, add an events_wait
which can look for any number of events simultaneously. However, it
will still only return one at a time, whichever happens first.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-4-jsnow@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
John Snow [Thu, 23 May 2019 17:06:40 +0000 (13:06 -0400)]
iotests.py: do not use infinite waits
Cap waits to 60 seconds so that iotests can fail gracefully if something
goes wrong.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-3-jsnow@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
John Snow [Thu, 23 May 2019 17:06:39 +0000 (13:06 -0400)]
blockdev-backup: don't check aio_context too early
in blockdev_backup_prepare, we check to make sure that the target is
associated with a compatible aio context. However, do_blockdev_backup is
called later and has some logic to move the target to a compatible
aio_context. The transaction version will fail certain commands
needlessly early as a result.
Allow blockdev_backup_prepare to simply call do_blockdev_backup, which
will ultimately decide if the contexts are compatible or not.
Note: the transaction version has always disallowed this operation since
its initial commit bd8baecd (2014), whereas the version of
qmp_blockdev_backup at the time, from commit c29c1dd312f, tried to
enforce the aio_context switch instead. It's not clear, and I can't see
from the mailing list archives at the time, why the two functions take a
different approach. It wasn't until later in efd7556708b (2016) that the
standalone version tried to determine if it could set the context or
not.
Reported-by: aihua liang <aliang@redhat.com> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1683498 Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-2-jsnow@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Peter Maydell [Thu, 13 Jun 2019 17:17:32 +0000 (18:17 +0100)]
Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-06-13' into staging
nbd patches for 2019-06-13
- add 'qemu-nbd --pid-file'
- NBD-related iotest improvements
- NBD code refactoring in preparation for reconnect
# gpg: Signature made Thu 13 Jun 2019 16:37:58 BST
# gpg: using RSA key A7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full]
# gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full]
# gpg: aka "[jpeg image of size 6874]" [full]
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* remotes/ericb/tags/pull-nbd-2019-06-13:
block/nbd: merge NBDClientSession struct back to BDRVNBDState
block/nbd: merge nbd-client.* to nbd.c
block/nbd-client: drop stale logout
nbd/server: Nicer spelling of max BLOCK_STATUS reply length
iotests: Let 233 run concurrently
iotests: Use qemu-nbd's --pid-file
qemu-nbd: Do not close stderr
iotests.py: Add qemu_nbd_early_pipe()
qemu-nbd: Add --pid-file option
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The code used to assign an interrupt index/subindex to an
eventfd is duplicated many times. Let's introduce an helper that
allows to set/unset the signaling for an ACTION_TRIGGER,
ACTION_MASK or ACTION_UNMASK action.
In the error message, we now use errno in case of any
VFIO_DEVICE_SET_IRQS ioctl failure.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Alex Williamson [Thu, 13 Jun 2019 15:57:36 +0000 (09:57 -0600)]
vfio/pci: Allow MSI-X relocation to fixup bogus PBA
The MSI-X relocation code can sometimes be used to work around bogus
MSI-X capabilities, but this test for whether the PBA is outside of
the specified BAR causes the device to error before we can apply a
relocation. Let it proceed if we intend to relocate MSI-X anyway.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Alex Williamson [Thu, 13 Jun 2019 15:57:36 +0000 (09:57 -0600)]
vfio/pci: Hide Resizable BAR capability
The resizable BAR capability is currently exposed read-only from the
kernel and we don't yet implement a protocol for virtualizing it to
the VM. Exposing it to the guest read-only introduces poor behavior
as the guest has no reason to test that a control register write is
accepted by the hardware. This can lead to cases where the guest OS
assumes the BAR has been resized, but it hasn't. This has been
observed when assigning AMD Vega GPUs.
Note, this does not preclude future enablement of resizable BARs, but
it's currently incorrect to expose this capability as read-only, so
better to not expose it at all.
Reported-by: James Courtier-Dutton <james.dutton@gmail.com> Tested-by: James Courtier-Dutton <james.dutton@gmail.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
block/nbd: merge NBDClientSession struct back to BDRVNBDState
No reason to keep it separate, it differs from others block driver
behavior and therefore confuses. Instead of generic
'state = (State*)bs->opaque' we have to use special helper.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190611102720.86114-4-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
No reason for keeping driver handlers realization separate from driver
structure. We can get rid of extra header file.
While being here, fix comments style, restore forgotten comments for
NBD_FOREACH_REPLY_CHUNK and nbd_reply_chunk_iter_receive, remove extra
includes.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190611102720.86114-3-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
Drop one on failure path (we have errp) and turn two others into trace
points.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190611102720.86114-2-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
Peter Maydell [Thu, 13 Jun 2019 14:16:39 +0000 (15:16 +0100)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190613-1' into staging
target-arm queue:
* convert aarch32 VFP decoder to decodetree
(includes tightening up decode in a few places)
* fix minor bugs in VFP short-vector handling
* hw/core/bus.c: Only the main system bus can have no parent
* smmuv3: Fix decoding of ID register range
* Implement NSACR gating of floating point
* Use tcg_gen_gvec_bitsel
Peter Maydell [Tue, 11 Jun 2019 15:39:53 +0000 (16:39 +0100)]
target/arm: Fix short-vector increment behaviour
For VFP short vectors, the VFP registers are divided into a
series of banks: for single-precision these are s0-s7, s8-s15,
s16-s23 and s24-s31; for double-precision they are d0-d3,
d4-d7, ... d28-d31. Some banks are "scalar" meaning that
use of a register within them triggers a pure-scalar or
mixed vector-scalar operation rather than a full vector
operation. The scalar banks are s0-s7, d0-d3 and d16-d19.
When using a bank as part of a vector operation, we
iterate through it, increasing the register number by
the specified stride each time, and wrapping around to
the beginning of the bank.
Unfortunately our calculation of the "increment" part of this
was incorrect:
vd = ((vd + delta_d) & (bank_mask - 1)) | (vd & bank_mask)
will only do the intended thing if bank_mask has exactly
one set high bit. For instance for doubles (bank_mask = 0xc),
if we start with vd = 6 and delta_d = 2 then vd is updated
to 12 rather than the intended 4.
This only causes problems in the unlikely case that the
starting register is not the first in its bank: if the
register number doesn't have to wrap around then the
expression happens to give the right answer.
Fix this bug by abstracting out the "check whether register
is in a scalar bank" and "advance register within bank"
operations to utility functions which use the right
bit masking operations.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:53 +0000 (16:39 +0100)]
target/arm: Convert float-to-integer VCVT insns to decodetree
Convert the float-to-integer VCVT instructions to decodetree.
Since these are the last unconverted instructions, we can
delete the old decoder structure entirely now.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:51 +0000 (16:39 +0100)]
target/arm: Convert VFP round insns to decodetree
Convert the VFP round-to-integer instructions VRINTR, VRINTZ and
VRINTX to decodetree.
These instructions were only introduced as part of the "VFP misc"
additions in v8A, so we check this. The old decoder's implementation
was incorrectly providing them even for v7A CPUs.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:51 +0000 (16:39 +0100)]
target/arm: Convert the VCVT-to-f16 insns to decodetree
Convert the VCVTT and VCVTB instructions which convert from
f32 and f64 to f16 to decodetree.
Since we're no longer constrained to the old decoder's style
using cpu_F0s and cpu_F0d we can perform a direct 16 bit
store of the right half of the input single-precision register
rather than doing a load/modify/store sequence on the full
32 bits.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:51 +0000 (16:39 +0100)]
target/arm: Convert the VCVT-from-f16 insns to decodetree
Convert the VCVTT, VCVTB instructions that deal with conversion
from half-precision floats to f32 or 64 to decodetree.
Since we're no longer constrained to the old decoder's style
using cpu_F0s and cpu_F0d we can perform a direct 16 bit
load of the right half of the input single-precision register
rather than loading the full 32 bits and then doing a
separate shift or sign-extension.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:51 +0000 (16:39 +0100)]
target/arm: Convert VFP comparison insns to decodetree
Convert the VFP comparison instructions to decodetree.
Note that comparison instructions should not honour the VFP
short-vector length and stride information: they are scalar-only
operations. This applies to all the 2-operand instructions except
for VMOV, VABS, VNEG and VSQRT. (In the old decoder this is
implemented via the "if (op == 15 && rn > 3) { veclen = 0; }" check.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:49 +0000 (16:39 +0100)]
target/arm: Convert VABS to decodetree
Convert the VFP VABS instruction to decodetree.
Unlike the 3-op versions, we don't pass fpst to the VFPGen2OpSPFn or
VFPGen2OpDPFn because none of the operations which use this format
and support short vectors will need it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:49 +0000 (16:39 +0100)]
target/arm: Convert VFP fused multiply-add insns to decodetree
Convert the VFP fused multiply-add instructions (VFNMA, VFNMS,
VFMA, VFMS) to decodetree.
Note that in the old decode structure we were implementing
these to honour the VFP vector stride/length. These instructions
were introduced in VFPv4, and in the v7A architecture they
are UNPREDICTABLE if the vector stride or length are non-zero.
In v8A they must UNDEF if stride or length are non-zero, like
all VFP instructions; we choose to UNDEF always.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:46 +0000 (16:39 +0100)]
target/arm: Convert VFP VMLA to decodetree
Convert the VFP VMLA instruction to decodetree.
This is the first of the VFP 3-operand data processing instructions,
so we include in this patch the code which loops over the elements
for an old-style VFP vector operation. The existing code to do this
looping uses the deprecated cpu_F0s/F0d/F1s/F1d TCG globals; since
we are going to be converting instructions one at a time anyway
we can take the opportunity to make the new loop use TCG temporaries,
which means we can do that conversion one operation at a time
rather than needing to do it all in one go.
We include an UNDEF check which was missing in the old code:
short-vector operations (with stride or length non-zero) were
deprecated in v7A and must UNDEF in v8A, so if the MVFR0 FPShVec
field does not indicate that support for short vectors is present
we UNDEF the operations that would use them. (This is a change
of behaviour for Cortex-A7, Cortex-A15 and the v8 CPUs, which
previously were all incorrectly allowing short-vector operations.)
Note that the conversion fixes a bug in the old code for the
case of VFP short-vector "mixed scalar/vector operations". These
happen where the destination register is in a vector bank but
but the second operand is in a scalar bank. For example
vmla.f64 d10, d1, d16 with length 2 stride 2
is equivalent to the pair of scalar operations
vmla.f64 d10, d1, d16
vmla.f64 d8, d3, d16
where the destination and first input register cycle through
their vector but the second input is scalar (d16). In the
old decoder the gen_vfp_F1_mul() operation uses cpu_F1{s,d}
as a temporary output for the multiply, which trashes the
second input operand. For the fully-scalar case (where we
never do a second iteration) and the fully-vector case
(where the loop loads the new second input operand) this
doesn't matter, but for the mixed scalar/vector case we
will end up using the wrong value for later loop iterations.
In the new code we use TCG temporaries and so avoid the bug.
This bug is present for all the multiply-accumulate insns
that operate on short vectors: VMLA, VMLS, VNMLA, VNMLS.
Note 2: the expression used to calculate the next register
number in the vector bank is not in fact correct; we leave
this behaviour unchanged from the old decoder and will
fix this bug later in the series.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:46 +0000 (16:39 +0100)]
target/arm: Remove VLDR/VSTR/VLDM/VSTM use of cpu_F0s and cpu_F0d
Expand out the sequences in the new decoder VLDR/VSTR/VLDM/VSTM trans
functions which perform the memory accesses by going via the TCG
globals cpu_F0s and cpu_F0d, to use local TCG temps instead.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Peter Maydell [Tue, 11 Jun 2019 15:39:45 +0000 (16:39 +0100)]
target/arm: Convert the VFP load/store multiple insns to decodetree
Convert the VFP load/store multiple insns to decodetree.
This includes tightening up the UNDEF checking for pre-VFPv3
CPUs which only have D0-D15 : they now UNDEF for any access
to D16-D31, not merely when the smallest register in the
transfer list is in D16-D31.
This conversion does not try to share code between the single
precision and the double precision versions; this looks a bit
duplicative of code, but it leaves the door open for a future
refactoring which gets rid of the use of the "F0" registers
by inlining the various functions like gen_vfp_ld() and
gen_mov_F0_reg() which are hiding "if (dp) { ... } else { ... }"
conditionalisation.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
projects / qemu-xen.git / log