Vhost shadow virtqueue (SVQ) is an intermediate jump for virtqueue
notifications and buffers, allowing qemu to track them. While qemu is
forwarding the buffers and virtqueue changes, it is able to commit the
memory it's being dirtied, the same way regular qemu's VirtIO devices
do.
This commit only exposes basic SVQ allocation and free. Next patches of
the series add functionality like notifications and buffers forwarding.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Commit bedd7e93d0 ("virtio-net: fix use after unmap/free for sg")
tries to fix the use after free of the sg by caching the virtqueue
elements in an array and unmap them at once after receiving the
packets, But it forgot to unmap the cached elements on error which
will lead to leaking of mapping and other unexpected results.
Fixing this by detaching the cached elements on error. This addresses
CVE-2022-26353.
Reported-by: Victor Tom <vv474172261@gmail.com>
Cc: qemu-stable@nongnu.org
Fixes: CVE-2022-26353
Fixes: bedd7e93d0 ("virtio-net: fix use after unmap/free for sg")
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Fix for arm ldrd unpredictable case
-----BEGIN PGP SIGNATURE-----
iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmIvfDwdHHJpY2hhcmQu
aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV98eQf/QnWavoj3OOhkVhh6
R0Egrfp+Se/s31D4eAJMerEcFpoOVe39Y85aCinBM7IOfjOc0MClG7r7C8B/JvbF
U/iQANBxVyAwTgNjGK9rqAL88pb8As9x7Ph7C6IfXdOuodQNENAlXrc2VowiMdA5
09lwlIkb65zAsTh7XqSP9DxupQcnjJAfTk9YWiFeq+aaz4od/8qadeUgcb3BB3nD
aoK82BJPkac3f+cM9neNHV0mEoV1Oi03KnH2WjfjJLJJTYDJx7T/3eo4oMUS+Mrl
pe4gob3aFInbqTQRNSaq3y86ASA0xRMq2h7W+pDzIBdTzUzIPZDMf2Tsuk61K/X+
KwSKfw==
=iJSt
-----END PGP SIGNATURE-----
Merge tag 'pull-tcg-20220314' of https://gitlab.com/rth7680/qemu into staging
Fixes for s390x host vectors
Fix for arm ldrd unpredictable case
# gpg: Signature made Mon 14 Mar 2022 17:32:44 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
* tag 'pull-tcg-20220314' of https://gitlab.com/rth7680/qemu:
tcg/arm: Don't emit UNPREDICTABLE LDRD with Rm == Rt or Rt+1
tcg/s390x: Fix tcg_out_dup_vec vs general registers
tcg/s390x: Fix INDEX_op_bitsel_vec vs VSEL
tcg/s390x: Fix tcg_out_dupi_vec vs VGM
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The LDRD (register) instruction is UNPREDICTABLE if the Rm register
is the same as either Rt or Rt+1 (the two registers being loaded to).
We weren't making sure we avoided this, with the result that on some
host CPUs like the Cortex-A7 we would get a SIGILL because the CPU
chooses to UNDEF for this particular UNPREDICTABLE case.
Since we've already checked that datalo is aligned, we can simplify
the test vs the Rm operand by aligning it before comparison. Check
for the two orderings before falling back to two ldr instructions.
We don't bother to do anything similar for tcg_out_ldrd_rwb(),
because it is only used in tcg_out_tlb_read() with a fixed set of
registers which don't overlap.
There is no equivalent UNPREDICTABLE case for STRD.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/896
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We copied the data from the general register input to the
vector register output, but have not yet replicated it.
We intended to fall through into the vector-vector case,
but failed to redirect the input register.
This is caught by an assertion failure in tcg_out_insn_VRIc,
which diagnosed the incorrect register class.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The operands are output in the wrong order: the tcg selector
argument is first, whereas the s390x selector argument is last.
Tested-by: Thomas Huth <thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/898
Fixes: 9bca986df8 ("tcg/s390x: Implement TCG_TARGET_HAS_bitsel_vec")
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
On a real system with POWER{8,9,10} processors, PHBs are sub-units of
the processor, they can be deactivated by firmware but not plugged in
or out like a PCI adapter on a slot. Nevertheless, having user-created
PHBs in QEMU seemed to be a good idea for testing purposes :
1. having a limited set of PHBs speedups boot time.
2. it is useful to be able to mimic a partially broken topology you
some time have to deal with during bring-up.
PowerNV is also used for distro install tests and having libvirt
support eases these tasks. libvirt prefers to run the machine with
-nodefaults to be sure not to drag unexpected devices which would need
to be defined in the domain file without being specified on the QEMU
command line. For this reason :
3. -nodefaults should not include default PHBs
User-created PHB{3,4,5} devices satisfied all these needs but reality
proves to be a bit more complex, internally when modeling such
devices, and externally when dealing with the user interface.
Req 1. and 2. can be simply addressed differently with a machine option:
"phb-mask=<uint>", which QEMU would use to enable/disable PHB device
nodes when creating the device tree.
For Req 3., we need to make sure we are taking the right approach. It
seems that we should expose a new type of user-created PHB device, a
generic virtualized one, that libvirt would use and not one depending
on the processor revision. This needs more thinking.
For now, remove user-created PHB{3,4,5} devices. All the cleanups we
did are not lost and they will be useful for the next steps.
Fixes: 5bc67b052b ("ppc/pnv: Introduce user creatable pnv-phb4 devices")
Fixes: 1f6a88fffc ("ppc/pnv: Introduce support for user created PHB3 devices")
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220314130514.529931-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Always create the PECs (PCI Express Controller) for the system. The
PECs host the PHBs and we try to find the matching PEC when creating a
PHB, so it must exist. It also matches what we do on POWER9
Fixes: 623575e16c ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
[ clg: - Rewored commit log
- Removed dynamic PHB5 ]
Message-Id: <20220310155101.294568-3-fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
We already have the pnv-phb3 and pnv-phb4 devices for POWER8 and
POWER9 respectively. POWER10 uses version 5 of the PHB. It is very
close to the PHB4 from POWER9, at least in our model and we could
almost keep using the PHB4 model. However the matching root port
pnv-phb5-root-port is specific to POWER10 so to avoid confusion as
well as making it easy to introduce differences later, we create a
pnv-phb5 class, which is mostly an alias for pnv-phb4 for now.
With this patch, the command line for a user-created PHB on powernv10
becomes:
-machine powernv10 -nodefaults -device pnv-phb5 -device pnv-phb5-root-port
Fixes: 623575e16c ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220310155101.294568-2-fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Xive2EndSource objects can only be instantiated through a Xive2Router
(PnvXive2).
Reported-by: Thomas Huth <thuth@redhat.com>
Fixes: f8a233dedf ("ppc/xive2: Introduce a XIVE2 core framework")
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Fix a typo in the host endianness macro and add a simple test to detect
regressions.
Fixes: 9bb0048ec6 ("target/ppc: convert xxspltw to vector operations")
Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220310172047.61094-1-matheus.ferst@eldorado.org.br>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Fix Instruction Storage Interrupt (ISI) fault cause for Radix MMU,
when caused by missing PAGE_EXEC permission, to be
SRR1_NOEXEC_GUARD instead of DSISR_PROTFAULT.
This matches POWER9 hardware behavior.
Fixes: d5fee0bbe6 ("target/ppc: Implement ISA V3.00 radix page fault handler")
Signed-off-by: Leandro Lupori <leandro.lupori@eldorado.org.br>
Message-Id: <20220309192756.145283-1-leandro.lupori@eldorado.org.br>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
This test times out when running in an IBM POWER host and --disable-tcg.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-10-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
All tests in the file times out when running in an IBM POWER host and
--disable-tcg with an error like the following:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine 40p (...)
Output: qemu-system-ppc: Register sync failed... If you're using
kvm-hv.ko, only "-cpu host" is possible
qemu-system-ppc: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
Since we don't have a way to detect whether the host is running kvm_hv
or kvm_pr, skip all tests if TCG is not available.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220310183011.110391-9-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
This tests times out in an IBM POWER host when compiled with
--disable-tcg.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-8-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
This tests times out in an IBM POWER host when compiled with
--disable-tcg.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-7-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
All tests of this file, when running in an IBM POWER host and with
--disable-tcg, fail in a similar manner:
Command: ./qemu-system-ppc -display none -vga none (...)
-cpu 7400 (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument
We don't have a way of telling which KVM module is loaded in a Power
host (kvm_hv or kvm_pr). For now let's make all the tests of this
file depend on TCG support.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-6-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Running this test without TCG support in an IBM POWER server results
in the following error:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine ref405ep (...)
Output: qemu-system-ppc: Register sync failed... If you're using
kvm-hv.ko, only "-cpu host" is possible
qemu-system-ppc: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
Although the host is running kvm_hv we don't have a way of differentiate
between kvm_hv and kvm_pr, meaning that this test would've failed in the
same way if kvm_pr was the KVM module loaded in the host.
Since we don't have a way of checking which KVM module is being loaded
when using avocado, make a TCG accel check in test_ppc_ref405ep().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-5-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Running this test gives us a deprecation warning telling that this
machine type is no longer supported:
Output: qemu-system-ppc: Machine type 'taihu' is deprecated:
incomplete, use 'ref405ep' instead
Moreover, this test fails to pass running in an IBM POWER host when
building QEMU with --disable-tcg.
Since the machine type is already being considered deprecated let's not
bother fixing the test with --disable-tcg. Remove test_ppc_taihu().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-4-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target in a similar manner as
test_ppc_g3beige did.
There's also an observation made about kvm_pr in the error message:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine mac99 (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument
This means that, when/if we're able to detect kvm_pr support in these
avocado tests, we can revisit this test to not rely solely on TCG
availability.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-3-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target.
One thing to note is that the error message explictly mentions kvm_pr
support:
Command: ./qemu-system-ppc -display none -vga none (...)
-machine g3beige (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument
The host was running kvm_hv, not kvm_pr, and the machine failed to load.
Unfortunately we don't have a way to detect whether the KVM module loaded
is kvm_hv or kvm_pr - we do a check for /dev/kvm to detect KVM support but
both modules create this file so that's not helpful.
Let's skip this test for now until we have a way of detecting kvm_pr support in the host.
Reported-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220310183011.110391-2-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The icount framework relies on TCG availability. If QEMU is built with
--disable-tcg we won't have icount either, and then this test will fail
with the following message in an IBM POWER9 host:
tests/avocado/replay_kernel.py:ReplayKernelNormal.test_ppc64_pseries:
ERROR: ConnectError: Failed to establish session:
(...)
/11-tests_avocado_replay_kernel.py_ReplayKernelNormal.test_ppc64_pseries/replay.bin:
cannot configure icount, TCG support not available
Although this was revealed in a specific ppc64 scenario, the TCG check
is being done in the common code inside run_vm() because all archs need
TCG to have access to icount.
Cc: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220303153517.168943-6-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Some ppc64 hosts (e.g. IBM POWER hosts) aren't able to run the e500
machine using KVM accel. Skip this test if TCG accel isn't available.
Cc: Cleber Rosa <crosa@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220303153517.168943-5-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The PowerNV8/9 machines does not work with KVM acceleration, meaning
that boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8/9 tests
will always fail when QEMU is compiled with --disable-tcg:
ERROR 1-tests/avocado/boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8
-> VMLaunchFailure: ConnectError: Failed to establish session:
[Errno 104] Connection reset by peer
Exit code: 1
Command: ./qemu-system-ppc64 -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_no19zg0m/qemu-1936936-7fffa77cff98-monitor.sock -mon chardev=mon,mode=control -machine powernv8 -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_no19zg0m/qemu-1936936-7fffa77cff98-console.sock,server=on,wait=off -serial chardev:console -kernel /home/danielhb/avocado/data/cache/by_location/4514304e2c4ee84c5f0b5c8bacedda783891df68/zImage.epapr -append console=tty0 console=hvc0 -device pcie-pci-bridge,id=bridge1,bus=pcie.1,addr=0x0 -device nvme,bus=pcie.2,addr=0x0,serial=1234 -device e1000e,bus=bridge1,addr=0x3 -device nec-usb-xhci,bus=bridge1,addr=0x2
Output: qemu-system-ppc64: The powernv machine does not work with KVM acceleration
Let's add the TCG accel requirement in both tests to skip them if we
don't have TCG support available.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220303153517.168943-4-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
'boot-serial-test' does not work with a QEMU built with --disable-tcg in
a IBM POWER9 host. The reason is that without TCG QEMU will default to
KVM acceleration, but then the KVM module in IBM POWER hosts aren't able
to handle other CPUs.
The result is that the test will break with a KVM error when trying to
ruin the ppce500 test:
$ QTEST_QEMU_BINARY=./qemu-system-ppc64 ./tests/qtest/boot-serial-test
/ppc64/boot-serial/ppce500: qemu-system-ppc64: -accel tcg: invalid accelerator tcg
error: kvm run failed Invalid argument
NIP 0000000000f00000 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0
MSR 0000000000000000 HID0 0000000000000000 HF 24020002 iidx 1 didx 1
TB 00000000 00000000 DECR 0
(...)
** (./tests/qtest/boot-serial-test:1935760): ERROR **: 07:44:03.010: Failed to find expected string. Please check '/tmp/qtest-boot-serial-sJ78sqg'
Fix it by checking CONFIG_TCG before compiling boot-serial-test.
Cc: Thomas Huth <thuth@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220303153517.168943-3-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
'prom-env-test' is a TCG test that will fail if QEMU is compiled with
--disable-tcg:
$ QTEST_QEMU_BINARY=./qemu-system-ppc64 ./tests/qtest/prom-env-test
/ppc64/prom-env/mac99: qemu-system-ppc64: -accel tcg: invalid accelerator tcg
(... hangs indefinitely ...)
Fix it by checking CONFIG_TCG before compiling prom-env-test.
Cc: Thomas Huth <thuth@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220303153517.168943-2-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The at24 eeproms are 2 byte devices that return 0xff when they are read
from with a partial (1-byte) address written. This distinction was
found comparing model behavior to real hardware testing.
Tested: `i2ctransfer -f -y 45 w1@85 0 r1` returns 0xff instead of next
byte
Signed-off-by: Patrick Venture <venture@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211220212137.1244511-1-venture@google.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
When switching to the dummy surface, we should also call gfx_update.
But when using GL, we shouldn't call it.
By making it an argument to displaychangelistener_gfx_switch(), it will
be explicit, and cannot be forgotten that easily.
Fixes: commit ebced091 ("console: save current scanout details")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Value of 0 for program and shaders are silently ignored and indicate error.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The current checks are done at registration time only. However, if a DCL
has no specific console specified, it may be switched dynamically with
console_select() later on.
Let's move the checks when displaychangelistener_display_console() is
called, which includes registration time and remains fatal if the
specified console is incompatible.
Note: we may want to display the compatibility error to the DCL, this is
left for a future improvement.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
DBusDisplayConsole is specific to a given QemuConsole.
Fixes: commit 142ca628 ("ui: add a D-Bus display backend")
Reported-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Fix a regression introduced by commit 5e79d516e ("ui: split the GL
context in a different object").
Reported-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
As expected from the "compatible_dcl" comment, a simple comparison of
ops isn't enough. The following patch will fix a regression introduced
by this limited check by extending the compatibility callback for
egl-headless.
For now, this patch simply replaces the the "compatible_dcl" ops pointer
with a "dpy_gl_ctx_is_compatible_ctx" callback.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Also includes a patch from Zongyuan Li <zongyuan.li@smartx.com> to remove an unused variable
******** Changes in v2 ********
Fix problems with build-user-hexagon CI job
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEENjXHiM5iuR/UxZq0ewJE+xLeRCIFAmIs/fkACgkQewJE+xLe
RCJNTQf/ZfvVqC6QKYw4OLEl0OCo56EAAl85GYQd7yKD+CU2RbsQBKpEoU9psuJX
zjCd2QW/ZkoB5kDMpSxyJTkdmcnWBfgHr6j5QKEI5QeuWxdlPzJ/UB0ZVWcnhJhV
ubyCfwceUyK69YZFvd7ZnbUj00ZLjpJXrLf5biHHJNZ2Q590kpwcxSyMJn8IaUJI
HSqjNt8xdxrNMLRJE048hNQoMp4GIoXYnQbLaDc4inZJRYStphV/Z+QmNtN2tqNs
VyP+U0udOzc552DJ0XMBV0vFZJ36L+C1HtalaI+ctQnksc7ht+W1t9D45BjT++Nx
AQgNkOVLHbDqKcVioLxgLyY4651ghg==
=bndB
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/quic/tags/pull-hex-20220312-1' into staging
Hexagon bug fixes and additional tests
Also includes a patch from Zongyuan Li <zongyuan.li@smartx.com> to remove an unused variable
******** Changes in v2 ********
Fix problems with build-user-hexagon CI job
# gpg: Signature made Sat 12 Mar 2022 20:09:29 GMT
# gpg: using RSA key 3635C788CE62B91FD4C59AB47B0244FB12DE4422
# gpg: Good signature from "Taylor Simpson (Rock on) <tsimpson@quicinc.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 3635 C788 CE62 B91F D4C5 9AB4 7B02 44FB 12DE 4422
* remotes/quic/tags/pull-hex-20220312-1:
target/hexagon: remove unused variable
Hexagon (target/hexagon) assignment to c4 should wait until packet commit
Hexagon (target/hexagon) fix bug in conv_df2uw_chop
Hexagon (tests/tcg/hexagon) fix inline asm in preg_alias.c
Hexagon (tests/tcg/hexagon) update overflow test
Hexagon (tests/tcg/hexagon) add floating point instructions to usr.c
Hexagon (tests/tcg/hexagon) test instructions that might set bits in USR
Hexagon (target/hexagon) properly handle NaN in dfmin/dfmax/sfmin/sfmax
Hexagon (target/hexagon) properly handle denorm in arch_sf_recip_common
Hexagon (target/hexagon) properly set FPINVF bit in sfcmp.uo and dfcmp.uo
Hexagon HVX (target/hexagon) fix bug in HVX saturate instructions
Hexagon (target/hexagon) fix bug in circular addressing
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When building with clang version 13.0.0 (eg. Fedora 13.0.0-3.fc35),
two unused variables introduced by macro GATHER_FUNCTION and
SCATTER_FUNCTION will cause building process failure due to
[-Werror -Wunused-variable].
Signed-off-by: Zongyuan Li <zongyuan.li@smartx.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/831
Message-Id: <20220124064339.56027-1-zongyuan.li@smartx.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Taylor Simpson <tsimpson@quicinc.com>
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
On Hexagon, c4 is an alias for predicate registers P3:0. If we assign to
c4 inside a packet with reads from predicate registers, the predicate
reads should get the old values.
Test case added to tests/tcg/hexagon/preg_alias.c
Co-authored-by: Michael Lambert <mlambert@cuicinc.com>
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-13-tsimpson@quicinc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Fix typo that checked for 32 bit nan instead of 64 bit
Test case added in tests/tcg/hexagon/usr.c
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-11-tsimpson@quicinc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Replace consecutive inline asm blocks with a single one with proper
outputs/inputs/clobbers rather than making assumptions about register
values being carried between separate blocks.
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-10-tsimpson@quicinc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Add a test that sets USR multiple times in a packet
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-9-tsimpson@quicinc.com>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
Tests to confirm floating point instructions are properly
setting exception bits in USR
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-8-tsimpson@quicinc.com>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
Hexagon has ~200 instructions that set the saturate bit in USR, these
were broken into groups of similar instructions and one instruction
from each group is tested with at least one input that does not
saturate and at least one input that does saturate.
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-7-tsimpson@quicinc.com>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
The float??_minnum implementation differs from Hexagon for SNaN,
it returns NaN, but Hexagon returns the other input. So, we use
float??_minimum_number.
Test cases added to tests/tcg/hexagon/fpstuff.c
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220308190410.22355-1-tsimpson@quicinc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
The arch_sf_recip_common function was calling float32_getexp which
adjusts for denorm, but the we actually need the raw exponent bits.
This function is called from 3 instructions
sfrecipa
sffixupn
sffixupd
Test cases added to tests/tcg/hexagon/fpstuff.c
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-6-tsimpson@quicinc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Instead of checking for nan arguments, use float??_unordered_quiet
test cases added in a subsequent patch to more extensively test USR bits
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20220210021556.9217-4-tsimpson@quicinc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
