aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-09-21Update version for 8.0.5 releasev8.0.5staging-8.0stable-8.0Michael Tokarev1-1/+1
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20tpm: fix crash when FD >= 1024 and unnecessary errors due to EINTRMarc-André Lureau1-9/+2
Replace select() with poll() to fix a crash when QEMU has a large number of FDs. Also use RETRY_ON_EINTR to avoid unnecessary errors due to EINTR. Cc: qemu-stable@nongnu.org Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2020133 Fixes: 56a3c24ffc ("tpm: Probe for connected TPM 1.2 or TPM 2") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> (cherry picked from commit 8e32ddff69b6b4547cc00592ad816484e160817a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20s390x/ap: fix missing subsystem reset registrationJanosch Frank1-0/+1
A subsystem reset contains a reset of AP resources which has been missing. Adding the AP bridge to the list of device types that need reset fixes this issue. Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Fixes: a51b3153 ("s390x/ap: base Adjunct Processor (AP) object model") Message-ID: <20230823142219.1046522-2-seiden@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 297ec01f0b9864ea8209ca0ddc6643b4c0574bdb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20ui: fix crash when there are no active_consoleMarc-André Lureau1-0/+3
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 812 return con->hw_ops->ui_info != NULL; (gdb) bt #0 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 #1 0x00005555558a44b1 in protocol_client_msg (vs=0x5555578c76c0, data=0x5555581e93f0 <incomplete sequence \373>, len=24) at ../ui/vnc.c:2585 #2 0x00005555558a19ac in vnc_client_read (vs=0x5555578c76c0) at ../ui/vnc.c:1607 #3 0x00005555558a1ac2 in vnc_client_io (ioc=0x5555581eb0e0, condition=G_IO_IN, opaque=0x5555578c76c0) at ../ui/vnc.c:1635 Fixes: https://issues.redhat.com/browse/RHEL-2600 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Albert Esteve <aesteve@redhat.com> (cherry picked from commit 48a35e12faf90a896c5aa4755812201e00d60316) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20hw/tpm: TIS on sysbus: Remove unsupport ppi command line optionStefan Berger1-1/+0
The ppi command line option for the TIS device on sysbus never worked and caused an immediate segfault. Remove support for it since it also needs support in the firmware and needs testing inside the VM. Reproducer with the ppi=on option passed: qemu-system-aarch64 \ -machine virt,gic-version=3 \ -m 4G \ -nographic -no-acpi \ -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ -device tpm-tis-device,tpmdev=tpm0,ppi=on [...] Segmentation fault (core dumped) Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20230713171955.149236-1-stefanb@linux.ibm.com (cherry picked from commit 4c46fe2ed492f35f411632c8b5a8442f322bc3f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20target/riscv/pmp.c: respect mseccfg.RLB for pmpaddrX changesLeon Schuermann1-0/+4
When the rule-lock bypass (RLB) bit is set in the mseccfg CSR, the PMP configuration lock bits must not apply. While this behavior is implemented for the pmpcfgX CSRs, this bit is not respected for changes to the pmpaddrX CSRs. This patch ensures that pmpaddrX CSR writes work even on locked regions when the global rule-lock bypass is enabled. Signed-off-by: Leon Schuermann <leons@opentitan.org> Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230829215046.1430463-1-leon@is.currently.online> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 4e3adce1244e1ca30ec05874c3eca14911dc0825) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20target/riscv: fix satp_mode_finalize() when satp_mode.supported = 0Daniel Henrique Barboza1-3/+20
In the same emulated RISC-V host, the 'host' KVM CPU takes 4 times longer to boot than the 'rv64' KVM CPU. The reason is an unintended behavior of riscv_cpu_satp_mode_finalize() when satp_mode.supported = 0, i.e. when cpu_init() does not set satp_mode_max_supported(). satp_mode_max_from_map(map) does: 31 - __builtin_clz(map) This means that, if satp_mode.supported = 0, satp_mode_supported_max wil be '31 - 32'. But this is C, so satp_mode_supported_max will gladly set it to UINT_MAX (4294967295). After that, if the user didn't set a satp_mode, set_satp_mode_default_map(cpu) will make cfg.satp_mode.map = cfg.satp_mode.supported So satp_mode.map = 0. And then satp_mode_map_max will be set to satp_mode_max_from_map(cpu->cfg.satp_mode.map), i.e. also UINT_MAX. The guard "satp_mode_map_max > satp_mode_supported_max" doesn't protect us here since both are UINT_MAX. And finally we have 2 loops: for (int i = satp_mode_map_max - 1; i >= 0; --i) { Which are, in fact, 2 loops from UINT_MAX -1 to -1. This is where the extra delay when booting the 'host' CPU is coming from. Commit 43d1de32f8 already set a precedence for satp_mode.supported = 0 in a different manner. We're doing the same here. If supported == 0, interpret as 'the CPU wants the OS to handle satp mode alone' and skip satp_mode_finalize(). We'll also put a guard in satp_mode_max_from_map() to assert out if map is 0 since the function is not ready to deal with it. Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Fixes: 6f23aaeb9b ("riscv: Allow user to set the satp mode") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230817152903.694926-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 3a2fc23563885c219c73c8f24318921daf02f3f2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20hw/riscv: virt: Fix riscv,pmu DT node pathConor Dooley1-1/+1
On a dtb dumped from the virt machine, dt-validate complains: soc: pmu: {'riscv,event-to-mhpmcounters': [[1, 1, 524281], [2, 2, 524284], [65561, 65561, 524280], [65563, 65563, 524280], [65569, 65569, 524280]], 'compatible': ['riscv,pmu']} should not be valid under {'type': 'object'} from schema $id: http://devicetree.org/schemas/simple-bus.yaml# That's pretty cryptic, but running the dtb back through dtc produces something a lot more reasonable: Warning (simple_bus_reg): /soc/pmu: missing or empty reg/ranges property Moving the riscv,pmu node out of the soc bus solves the problem. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230727-groom-decline-2c57ce42841c@spud> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 9ff31406312500053ecb5f92df01dd9ce52e635d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20linux-user/riscv: Use abi type for target_ucontextLIU Zhiwei1-2/+2
We should not use types dependend on host arch for target_ucontext. This bug is found when run rv32 applications. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230811055438.1945-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit ae7d4d625cab49657b9fc2be09d895afb9bcdaf0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20hw/intc: Make rtc variable names consistentJason Chien1-3/+3
The variables whose values are given by cpu_riscv_read_rtc() should be named "rtc". The variables whose value are given by cpu_riscv_read_rtc_raw() should be named "rtc_r". Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230728082502.26439-2-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 9382a9eafccad8dc6a487ea3a8d2bed03dc35db9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20hw/intc: Fix upper/lower mtime write calculationJason Chien1-2/+3
When writing the upper mtime, we should keep the original lower mtime whose value is given by cpu_riscv_read_rtc() instead of cpu_riscv_read_rtc_raw(). The same logic applies to writes to lower mtime. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230728082502.26439-1-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit e0922b73baf00c4c19d4ad30d09bb94f7ffea0f4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-20hw/char/riscv_htif: Fix the console syscall on big endian hostsThomas Huth1-4/+5
Values that have been read via cpu_physical_memory_read() from the guest's memory have to be swapped in case the host endianess differs from the guest. Fixes: a6e13e31d5 ("riscv_htif: Support console output via proxy syscall") Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230721094720.902454-3-thuth@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 058096f1c55ab688db7e1d6814aaefc1bcd87f7a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix in hw/char/riscv_htif.c for #include)
2023-09-20include/exec: Provide the tswap() functions for target independent code, tooThomas Huth2-63/+73
In some cases of target independent code, it would be useful to have access to the functions that swap endianess in case it differs between guest and host. Thus re-implement the tswapXX() functions in a new header that can be included separately. The check whether the swapping is needed continues to be done at compile-time for target specific code, while it is done at run-time in target-independent code. Message-Id: <20230411183418.1640500-3-thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 24be3369ad63c3882be42dd510a45bad52816fd1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (trivial change needed for the next commit 058096f1c5 "hw/char/riscv_htif: Fix the console syscall on big endian hosts")
2023-09-12hw/char/riscv_htif: Fix printing of console characters on big endian hostsThomas Huth1-1/+2
The character that should be printed is stored in the 64 bit "payload" variable. The code currently tries to print it by taking the address of the variable and passing this pointer to qemu_chr_fe_write(). However, this only works on little endian hosts where the least significant bits are stored on the lowest address. To do this in a portable way, we have to store the value in an uint8_t variable instead. Fixes: 5033606780 ("RISC-V HTIF Console") Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230721094720.902454-2-thuth@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit c255946e3df4d9660e4f468a456633c24393d468) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11arm64: Restore trapless ptimer accessColton Lewis1-0/+1
Due to recent KVM changes, QEMU is setting a ptimer offset resulting in unintended trap and emulate access and a consequent performance hit. Filter out the PTIMER_CNT register to restore trapless ptimer access. Quoting Andrew Jones: Simply reading the CNT register and writing back the same value is enough to set an offset, since the timer will have certainly moved past whatever value was read by the time it's written. QEMU frequently saves and restores all registers in the get-reg-list array, unless they've been explicitly filtered out (with Linux commit 680232a94c12, KVM_REG_ARM_PTIMER_CNT is now in the array). So, to restore trapless ptimer accesses, we need a QEMU patch to filter out the register. See https://lore.kernel.org/kvmarm/gsntttsonus5.fsf@coltonlewis-kvm.c.googlers.com/T/#m0770023762a821db2a3f0dd0a7dc6aa54e0d0da9 for additional context. Cc: qemu-stable@nongnu.org Signed-off-by: Andrew Jones <andrew.jones@linux.dev> Signed-off-by: Colton Lewis <coltonlewis@google.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Colton Lewis <coltonlewis@google.com> Message-id: 20230831190052.129045-1-coltonlewis@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 682814e2a3c883b27f24b9e7cab47313c49acbd4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11virtio: Drop out of coroutine context in virtio_load()Kevin Wolf1-5/+40
virtio_load() as a whole should run in coroutine context because it reads from the migration stream and we don't want this to block. However, it calls virtio_set_features_nocheck() and devices don't expect their .set_features callback to run in a coroutine and therefore call functions that may not be called in coroutine context. To fix this, drop out of coroutine context for calling virtio_set_features_nocheck(). Without this fix, the following crash was reported: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007efc738c05d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007efc73873d26 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007efc738477f3 in __GI_abort () at abort.c:79 #4 0x00007efc7384771b in __assert_fail_base (fmt=0x7efc739dbcb8 "", assertion=assertion@entry=0x560aebfbf5cf "!qemu_in_coroutine()", file=file@entry=0x560aebfcd2d4 "../block/graph-lock.c", line=line@entry=275, function=function@entry=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:92 #5 0x00007efc7386ccc6 in __assert_fail (assertion=0x560aebfbf5cf "!qemu_in_coroutine()", file=0x560aebfcd2d4 "../block/graph-lock.c", line=275, function=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:101 #6 0x0000560aebcd8dd6 in bdrv_register_buf () #7 0x0000560aeb97ed97 in ram_block_added.llvm () #8 0x0000560aebb8303f in ram_block_add.llvm () #9 0x0000560aebb834fa in qemu_ram_alloc_internal.llvm () #10 0x0000560aebb2ac98 in vfio_region_mmap () #11 0x0000560aebb3ea0f in vfio_bars_register () #12 0x0000560aebb3c628 in vfio_realize () #13 0x0000560aeb90f0c2 in pci_qdev_realize () #14 0x0000560aebc40305 in device_set_realized () #15 0x0000560aebc48e07 in property_set_bool.llvm () #16 0x0000560aebc46582 in object_property_set () #17 0x0000560aebc4cd58 in object_property_set_qobject () #18 0x0000560aebc46ba7 in object_property_set_bool () #19 0x0000560aeb98b3ca in qdev_device_add_from_qdict () #20 0x0000560aebb1fbaf in virtio_net_set_features () #21 0x0000560aebb46b51 in virtio_set_features_nocheck () #22 0x0000560aebb47107 in virtio_load () #23 0x0000560aeb9ae7ce in vmstate_load_state () #24 0x0000560aeb9d2ee9 in qemu_loadvm_state_main () #25 0x0000560aeb9d45e1 in qemu_loadvm_state () #26 0x0000560aeb9bc32c in process_incoming_migration_co.llvm () #27 0x0000560aebeace56 in coroutine_trampoline.llvm () Cc: qemu-stable@nongnu.org Buglink: https://issues.redhat.com/browse/RHEL-832 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20230905145002.46391-3-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 92e2e6a867334a990f8d29f07ca34e3162fdd6ec) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10qxl: don't assert() if device isn't yet initializedMarc-André Lureau1-1/+4
If the PCI BAR isn't yet mapped or was unmapped, QXL_IO_SET_MODE will assert(). Instead, report a guest bug and keep going. This can be reproduced with: cat << EOF | ./qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio outl 0xcf8 0x8000101c outl 0xcfc 0xc000 outl 0xcf8 0x80001001 outl 0xcfc 0x01000000 outl 0xc006 0x00 EOF Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1829 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 95bef686e490bc3afc3f51f5fc6e20bf260b938c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/net/vmxnet3: Fix guest-triggerable assert()Thomas Huth1-1/+4
The assert() that checks for valid MTU sizes can be triggered by the guest (e.g. with the reproducer code from the bug ticket https://gitlab.com/qemu-project/qemu/-/issues/517 ). Let's avoid this problem by simply logging the error and refusing to activate the device instead. Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate") Signed-off-by: Thomas Huth <thuth@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> [Mjt: change format specifier from %d to %u for uint32_t argument] (cherry picked from commit 90a0778421acdf4ca903be64c8ed19378183c944) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10docs tests: Fix use of migrate_set_parameterMarkus Armbruster4-11/+11
docs/multi-thread-compression.txt uses parameter names with underscores instead of dashes. Wrong since day one. docs/rdma.txt, tests/qemu-iotests/181, and tests/qtest/test-hmp.c are wrong the same way since commit cbde7be900d2 (v6.0.0). Hard to see, as test-hmp doesn't check whether the commands work, and iotest 181 appears to be unaffected. Fixes: 263170e679df (docs: Add a doc about multiple thread compression) Fixes: cbde7be900d2 (migrate: remove QMP/HMP commands for speed, downtime and cache size) Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit b21a6e31a182a5ae7436a444f840d49aac07c94f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10qemu-options.hx: Rephrase the descriptions of the -hd* and -cdrom optionsThomas Huth1-8/+12
The current description says that these options will create a device on the IDE bus, which is only true on x86. So rephrase these sentences a little bit to speak of "default bus" instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit bcd8e243083c878884e52d609deddbe6be17c730) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/i2c/aspeed: Fix TXBUF transmission start position errorHang Yu1-24/+6
According to the ast2600 datasheet and the linux aspeed i2c driver, the TXBUF transmission start position should be TXBUF[0] instead of TXBUF[1],so the arg pool_start is useless,and the address is not included in TXBUF.So even if Tx Count equals zero,there is at least 1 byte data needs to be transmitted,and M_TX_CMD should not be cleared at this condition.The driver url is: https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v5.15/drivers/i2c/busses/i2c-ast2600.c Signed-off-by: Hang Yu <francis_yuu@stu.pku.edu.cn> Fixes: 6054fc73e8f4 ("aspeed/i2c: Add support for pool buffer transfers") Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 961faf3ddbd8ffcdf776bbcf88af0bc97218114a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/i2c/aspeed: Fix Tx count and Rx size error in buffer pool modeHang Yu2-6/+6
Fixed inconsistency between the regisiter bit field definition header file and the ast2600 datasheet. The reg name is I2CD1C:Pool Buffer Control Register in old register mode and I2CC0C: Master/Slave Pool Buffer Control Register in new register mode. They share bit field [12:8]:Transmit Data Byte Count and bit field [29:24]:Actual Received Pool Buffer Size according to the datasheet. According to the ast2600 datasheet,the actual Tx count is Transmit Data Byte Count plus 1, and the max Rx size is Receive Pool Buffer Size plus 1, both in Pool Buffer Control Register. The version before forgot to plus 1, and mistake Rx count for Rx size. Signed-off-by: Hang Yu <francis_yuu@stu.pku.edu.cn> Fixes: 3be3d6ccf2ad ("aspeed: i2c: Migrate to registerfields API") Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 97b8aa5ae9ff197394395eda5062ea3681e09c28) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ide/ahci: fix broken SError handlingNiklas Cassel1-2/+1
When encountering an NCQ error, you should not write the NCQ tag to the SError register. This is completely wrong. The SError register has a clear definition, where each bit represents a different error, see PxSERR definition in AHCI 1.3.1. If we write a random value (like the NCQ tag) in SError, e.g. Linux will read SError, and will trigger arbitrary error handling depending on the NCQ tag that happened to be executing. In case of success, ncq_cb() will call ncq_finish(). In case of error, ncq_cb() will call ncq_err() (which will clear ncq_tfs->used), and then call ncq_finish(), thus using ncq_tfs->used is sufficient to tell if finished should get set or not. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230609140844.202795-9-nks@flawful.org Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit 9f89423537653de07ca40c18b5ff5b70b104cc93) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ide/ahci: fix ahci_write_fis_sdb()Niklas Cassel1-2/+8
When there is an error, we need to raise a TFES error irq, see AHCI 1.3.1, 5.3.13.1 SDB:Entry. If ERR_STAT is set, we jump to state ERR:FatalTaskfile, which will raise a TFES IRQ unconditionally, regardless if the I bit is set in the FIS or not. Thus, we should never raise a normal IRQ after having sent an error IRQ. It is valid to signal successfully completed commands as finished in the same SDB FIS that generates the error IRQ. The important thing is that commands that did not complete successfully (e.g. commands that were aborted, do not get the finished bit set). Before this commit, there was never a TFES IRQ raised on NCQ error. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230609140844.202795-8-nks@flawful.org Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit 7e85cb0db4c693b4e084a00e66fe73a22ed1688a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ide/ahci: PxCI should not get cleared when ERR_STAT is setNiklas Cassel3-33/+88
For NCQ, PxCI is cleared on command queued successfully. For non-NCQ, PxCI is cleared on command completed successfully. Successfully means ERR_STAT, BUSY and DRQ are all cleared. A command that has ERR_STAT set, does not get to clear PxCI. See AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and RegFIS:ClearCI, and 5.3.16.5 ERR:FatalTaskfile. In the case of non-NCQ commands, not clearing PxCI is needed in order for host software to be able to see which command slot that failed. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Message-id: 20230609140844.202795-7-nks@flawful.org Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit 1a16ce64fda11bdf50f0c4ab5d9fdde72c1383a2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ide/ahci: PxSACT and PxCI is cleared when PxCMD.ST is clearedNiklas Cassel1-0/+5
According to AHCI 1.3.1 definition of PxSACT: This field is cleared when PxCMD.ST is written from a '1' to a '0' by software. This field is not cleared by a COMRESET or a software reset. According to AHCI 1.3.1 definition of PxCI: This field is also cleared when PxCMD.ST is written from a '1' to a '0' by software. Clearing PxCMD.ST is part of the error recovery procedure, see AHCI 1.3.1, section "6.2 Error Recovery". If we don't clear PxCI on error recovery, the previous command will incorrectly still be marked as pending after error recovery. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230609140844.202795-6-nks@flawful.org Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit d73b84d0b664e60fffb66f46e84d0db4a8e1c713) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ide/ahci: simplify and document PxCI handlingNiklas Cassel1-20/+50
The AHCI spec states that: For NCQ, PxCI is cleared on command queued successfully. For non-NCQ, PxCI is cleared on command completed successfully. (A non-NCQ command that completes with error does not clear PxCI.) The current QEMU implementation either clears PxCI in check_cmd(), or in ahci_cmd_done(). check_cmd() will clear PxCI for a command if handle_cmd() returns 0. handle_cmd() will return -1 if BUSY or DRQ is set. The QEMU implementation for NCQ commands will currently not set BUSY or DRQ, so they will always have PxCI cleared by handle_cmd(). ahci_cmd_done() will never even get called for NCQ commands. Non-NCQ commands are executed by ide_bus_exec_cmd(). Non-NCQ commands in QEMU are implemented either in a sync or in an async way. For non-NCQ commands implemented in a sync way, the command handler will return true, and when ide_bus_exec_cmd() sees that a command handler returns true, it will call ide_cmd_done() (which will call ahci_cmd_done()). For a command implemented in a sync way, ahci_cmd_done() will do nothing (since busy_slot is not set). Instead, after ide_bus_exec_cmd() has finished, check_cmd() will clear PxCI for these commands. For non-NCQ commands implemented in an async way (using either aiocb or pio_aiocb), the command handler will return false, ide_bus_exec_cmd() will not call ide_cmd_done(), instead it is expected that the async callback function will call ide_cmd_done() once the async command is done. handle_cmd() will set busy_slot, if and only if BUSY or DRQ is set, and this is checked _after_ ide_bus_exec_cmd() has returned. handle_cmd() will return -1, so check_cmd() will not clear PxCI. When the async callback calls ide_cmd_done() (which will call ahci_cmd_done()), it will see that busy_slot is set, and ahci_cmd_done() will clear PxCI. This seems racy, since busy_slot is set _after_ ide_bus_exec_cmd() has returned. The callback might come before busy_slot gets set. And it is quite confusing that ahci_cmd_done() will be called for all non-NCQ commands when the command is done, but will only clear PxCI in certain cases, even though it will always write a D2H FIS and raise an IRQ. Even worse, in the case where ahci_cmd_done() does not clear PxCI, it still raises an IRQ. Host software might thus read an old PxCI value, since PxCI is cleared (by check_cmd()) after the IRQ has been raised. Try to simplify this by always setting busy_slot for non-NCQ commands, such that ahci_cmd_done() will always be responsible for clearing PxCI for non-NCQ commands. For NCQ commands, clear PxCI when we receive the D2H FIS, but before raising the IRQ, see AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and RegFIS:ClearCI. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Message-id: 20230609140844.202795-5-nks@flawful.org Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit e2a5d9b3d9c3d311618160603cc9bc04fbd98796) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ide/ahci: write D2H FIS when processing NCQ commandNiklas Cassel1-6/+11
The way that BUSY + PxCI is cleared for NCQ (FPDMA QUEUED) commands is described in SATA 3.5a Gold: 11.15 FPDMA QUEUED command protocol DFPDMAQ2: ClearInterfaceBsy "Transmit Register Device to Host FIS with the BSY bit cleared to zero and the DRQ bit cleared to zero and Interrupt bit cleared to zero to mark interface ready for the next command." PxCI is currently cleared by handle_cmd(), but we don't write the D2H FIS to the FIS Receive Area that actually caused PxCI to be cleared. Similar to how ahci_pio_transfer() calls ahci_write_fis_pio() with an additional parameter to write a PIO Setup FIS without raising an IRQ, add a parameter to ahci_write_fis_d2h() so that ahci_write_fis_d2h() also can write the FIS to the FIS Receive Area without raising an IRQ. Change process_ncq_command() to call ahci_write_fis_d2h() without raising an IRQ (similar to ahci_pio_transfer()), such that the FIS Receive Area is in sync with the PxTFD shadow register. E.g. Linux reads status and error fields from the FIS Receive Area directly, so it is wise to keep the FIS Receive Area and the PxTFD shadow register in sync. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Message-id: 20230609140844.202795-4-nks@flawful.org Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit 2967dc8209dd27b61a6ab7bad78cf7c6ec58ddb4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ide/core: set ERR_STAT in unsupported command completionNiklas Cassel1-1/+1
Currently, the first time sending an unsupported command (e.g. READ LOG DMA EXT) will not have ERR_STAT set in the completion. Sending the unsupported command again, will correctly have ERR_STAT set. When ide_cmd_permitted() returns false, it calls ide_abort_command(). ide_abort_command() first calls ide_transfer_stop(), which will call ide_transfer_halt() and ide_cmd_done(), after that ide_abort_command() sets ERR_STAT in status. ide_cmd_done() for AHCI will call ahci_write_fis_d2h() which writes the current status in the FIS, and raises an IRQ. (The status here will not have ERR_STAT set!). Thus, we cannot call ide_transfer_stop() before setting ERR_STAT, as ide_transfer_stop() will result in the FIS being written and an IRQ being raised. The reason why it works the second time, is that ERR_STAT will still be set from the previous command, so when writing the FIS, the completion will correctly have ERR_STAT set. Set ERR_STAT before writing the FIS (calling cmd_done), so that we will raise an error IRQ correctly when receiving an unsupported command. Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230609140844.202795-3-nks@flawful.org Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit c3461c6264a7c8ca15b117e91fe5da786924a784) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10target/ppc: Flush inputs to zero with NJ in ppc_store_vscrRichard Henderson1-0/+1
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1779 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit af03aeb631eeb81a44d2c0ff5b429cd4b5dc2799) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10ppc/vof: Fix missed fields in VOF cleanupNicholas Piggin1-0/+2
Failing to reset the of_instance_last makes ihandle allocation continue to increase, which causes record-replay replay fail to match the recorded trace. Not resetting claimed_base makes VOF eventually run out of memory after some resets. Cc: Alexey Kardashevskiy <aik@ozlabs.ru> Fixes: fc8c745d501 ("spapr: Implement Open Firmware client interface") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 7b8589d7ce7e23f26ff53338d575a5cbd7818e28) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/ppc/e500: fix broken snapshot replayMaksim Kostin1-1/+1
ppce500_reset_device_tree is registered for system reset, but after c4b075318eb1 this function rerandomizes rng-seed via qemu_guest_getrandom_nofail. And when loading a snapshot, it tries to read EVENT_RANDOM that doesn't exist, so we have an error: qemu-system-ppc: Missing random event in the replay log To fix this, use qemu_register_reset_nosnapshotload instead of qemu_register_reset. Reported-by: Vitaly Cheptsov <cheptsov@ispras.ru> Fixes: c4b075318eb1 ("hw/ppc: pass random seed to fdt ") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1634 Signed-off-by: Maksim Kostin <maksim.kostin@ispras.ru> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 6ec65b69ba17c954414fa23a397fb8a3fcfb4a43) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10block-migration: Ensure we don't crash during migration cleanupFabiano Rosas1-2/+9
We can fail the blk_insert_bs() at init_blk_migration(), leaving the BlkMigDevState without a dirty_bitmap and BlockDriverState. Account for the possibly missing elements when doing cleanup. Fix the following crashes: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 359 BlockDriverState *bs = bitmap->bs; #0 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 #1 0x0000555555bba331 in unset_dirty_tracking () at ../migration/block.c:371 #2 0x0000555555bbad98 in block_migration_cleanup_bmds () at ../migration/block.c:681 Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 7073 QLIST_FOREACH_SAFE(blocker, &bs->op_blockers[op], list, next) { #0 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 #1 0x0000555555e9734a in bdrv_op_unblock_all (bs=0x0, reason=0x0) at ../block.c:7095 #2 0x0000555555bbae13 in block_migration_cleanup_bmds () at ../migration/block.c:690 Signed-off-by: Fabiano Rosas <farosas@suse.de> Message-id: 20230731203338.27581-1-farosas@suse.de Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit f187609f27b261702a17f79d20bf252ee0d4f9cd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10docs/about/license: Update LICENSE URLPhilippe Mathieu-Daudé1-1/+1
In early 2021 (see commit 2ad784339e "docs: update README to use GitLab repo URLs") almost all of the code base was converted to point to GitLab instead of git.qemu.org. During 2023, git.qemu.org switched from a git mirror to a http redirect to GitLab (see [1]). Update the LICENSE URL to match its previous content, displaying the file raw content similarly to gitweb 'blob_plain' format ([2]). [1] https://lore.kernel.org/qemu-devel/CABgObfZu3mFc8tM20K-yXdt7F-7eV-uKZN4sKDarSeu7DYoRbA@mail.gmail.com/ [2] https://git-scm.com/docs/gitweb#Documentation/gitweb.txt-blobplain Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230822125716.55295-1-philmd@linaro.org> (cherry picked from commit 09a3fffae00b042bed8ad9c351b1a58c505fde37) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10target/arm: Fix 64-bit SSRARichard Henderson1-1/+1
Typo applied byte-wise shift instead of double-word shift. Cc: qemu-stable@nongnu.org Fixes: 631e565450c ("target/arm: Create gen_gvec_[us]sra") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1737 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230821022025.397682-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit cd1e4db73646006039f25879af3bff55b2295ff3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10target/arm: Fix SME ST1QRichard Henderson1-1/+1
A typo, noted in the bug report, resulting in an incorrect write offset. Cc: qemu-stable@nongnu.org Fixes: 7390e0e9ab8 ("target/arm: Implement SME LD1, ST1") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1833 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230818214255.146905-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4b3520fd93cd49cc56dfcab45d90735cc2e35af7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10accel/kvm: Specify default IPA size for arm64Akihiko Odaki1-1/+3
Before this change, the default KVM type, which is used for non-virt machine models, was 0. The kernel documentation says: > On arm64, the physical address size for a VM (IPA Size limit) is > limited to 40bits by default. The limit can be configured if the host > supports the extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use > KVM_VM_TYPE_ARM_IPA_SIZE(IPA_Bits) to set the size in the machine type > identifier, where IPA_Bits is the maximum width of any physical > address used by the VM. The IPA_Bits is encoded in bits[7-0] of the > machine type identifier. > > e.g, to configure a guest to use 48bit physical address size:: > > vm_fd = ioctl(dev_fd, KVM_CREATE_VM, KVM_VM_TYPE_ARM_IPA_SIZE(48)); > > The requested size (IPA_Bits) must be: > > == ========================================================= > 0 Implies default size, 40bits (for backward compatibility) > N Implies N bits, where N is a positive integer such that, > 32 <= N <= Host_IPA_Limit > == ========================================================= > Host_IPA_Limit is the maximum possible value for IPA_Bits on the host > and is dependent on the CPU capability and the kernel configuration. > The limit can be retrieved using KVM_CAP_ARM_VM_IPA_SIZE of the > KVM_CHECK_EXTENSION ioctl() at run-time. > > Creation of the VM will fail if the requested IPA size (whether it is > implicit or explicit) is unsupported on the host. https://docs.kernel.org/virt/kvm/api.html#kvm-create-vm So if Host_IPA_Limit < 40, specifying 0 as the type will fail. This actually confused libvirt, which uses "none" machine model to probe the KVM availability, on M2 MacBook Air. Fix this by using Host_IPA_Limit as the default type when KVM_CAP_ARM_VM_IPA_SIZE is available. Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20230727073134.134102-3-akihiko.odaki@daynix.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1ab445af8cd99343f29032b5944023ad7d8edebf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10kvm: Introduce kvm_arch_get_default_type hookAkihiko Odaki10-13/+31
kvm_arch_get_default_type() returns the default KVM type. This hook is particularly useful to derive a KVM type that is valid for "none" machine model, which is used by libvirt to probe the availability of KVM. For MIPS, the existing mips_kvm_type() is reused. This function ensures the availability of VZ which is mandatory to use KVM on the current QEMU. Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20230727073134.134102-2-akihiko.odaki@daynix.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added doc comment for new function] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 5e0d65909c6f335d578b90491e165440c99adf81) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10include/hw/virtio/virtio-gpu: Fix virtio-gpu with blob on big endian hostsThomas Huth1-0/+3
Using "-device virtio-gpu,blob=true" currently does not work on big endian hosts (like s390x). The guest kernel prints an error message like: [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x10c) and the display stays black. When running QEMU with "-d guest_errors", it shows an error message like this: virtio_gpu_create_mapping_iov: nr_entries is too big (83886080 > 16384) which indicates that this value has not been properly byte-swapped. And indeed, the virtio_gpu_create_blob_bswap() function (that should swap the fields in the related structure) fails to swap some of the entries. After correctly swapping all missing values here, too, the virtio-gpu device is now also working with blob=true on s390x hosts. Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2230469 Message-Id: <20230815122007.928049-1-thuth@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit d194362910138776e8abd6bb3c9fb3693254e95f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10target/s390x: Check reserved bits of VFMIN/VFMAX's M5Ilya Leoshkevich1-1/+1
VFMIN and VFMAX should raise a specification exceptions when bits 1-3 of M5 are set. Cc: qemu-stable@nongnu.org Fixes: da4807527f3b ("s390x/tcg: Implement VECTOR FP (MAXIMUM|MINIMUM)") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230804234621.252522-1-iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 6a2ea6151835aa4f5fee29382a421c13b0e6619f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10target/s390x: Fix VSTL with a large lengthIlya Leoshkevich1-1/+1
The length is always truncated to 16 bytes. Do not probe more than that. Cc: qemu-stable@nongnu.org Fixes: 0e0a5b49ad58 ("s390x/tcg: Implement VECTOR STORE WITH LENGTH") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230804235624.263260-1-iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 6db3518ba4fcddd71049718f138552999f0d97b4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10target/s390x: Use a 16-bit immediate in VREPIlya Leoshkevich1-2/+2
Unlike most other instructions that contain an immediate element index, VREP's one is 16-bit, and not 4-bit. The code uses only 8 bits, so using, e.g., 0x101 does not lead to a specification exception. Fix by checking all 16 bits. Cc: qemu-stable@nongnu.org Fixes: 28d08731b1d8 ("s390x/tcg: Implement VECTOR REPLICATE") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230807163459.849766-1-iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 23e87d419f347b6b5f4da3bf70d222acc24cdb64) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10target/s390x: Fix the "ignored match" case in VSTRSIlya Leoshkevich1-37/+17
Currently the emulation of VSTRS recognizes partial matches in presence of \0 in the haystack, which, according to PoP, is not correct: If the ZS flag is one and a zero byte was detected in the second operand, then there can not be a partial match ... Add a check for this. While at it, fold a number of explicitly handled special cases into the generic logic. Cc: qemu-stable@nongnu.org Reported-by: Claudio Fontana <cfontana@suse.de> Closes: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg00633.html Fixes: 1d706f314191 ("target/s390x: vxeh2: vector string search") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230804233748.218935-3-iii@linux.ibm.com> Tested-by: Claudio Fontana <cfontana@suse.de> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 791b2b6a930273db694b9ba48bbb406e78715927) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/sd/sdhci: Do not force sdhci_mmio_*_ops onto all SD controllersBernhard Beschow1-1/+7
Since commit c0a55a0c9da2 "hw/sd/sdhci: Support big endian SD host controller interfaces" sdhci_common_realize() forces all SD card controllers to use either sdhci_mmio_le_ops or sdhci_mmio_be_ops, depending on the "endianness" property. However, there are device models which use different MMIO ops: TYPE_IMX_USDHC uses usdhc_mmio_ops and TYPE_S3C_SDHCI uses sdhci_s3c_mmio_ops. Forcing sdhci_mmio_le_ops breaks SD card handling on the "sabrelite" board, for example. Fix this by defaulting the io_ops to little endian and switch to big endian in sdhci_common_realize() only if there is a matchig big endian variant available. Fixes: c0a55a0c9da2 ("hw/sd/sdhci: Support big endian SD host controller interfaces") Signed-off-by: Bernhard Beschow <shentey@gmail.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-Id: <20230709080950.92489-1-shentey@gmail.com> (cherry picked from commit 3b830790151ff231531ef2595793e387dd154efb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10Fixed incorrect LLONG alignment for openrisc and crisLuca Bonissi1-0/+8
OpenRISC (or1k) has long long alignment to 4 bytes, but currently not defined in abitypes.h. This lead to incorrect packing of /epoll_event/ structure and eventually infinite loop while waiting for file descriptor[s] event[s]. Fixed also CRIS alignments (1 byte for all types). Signed-off-by: Luca Bonissi <qemu@bonslack.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1770 Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 6ee960823da8fd780ae9912c4327b7e85e80d846) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10include/exec/user: Set ABI_LLONG_ALIGNMENT to 4 for nios2Richard Henderson1-1/+2
Based on gcc's nios2.h setting BIGGEST_ALIGNMENT to 32 bits. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit ea9812d93f9c3e1a308ac33097021c50d581d10e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10include/exec/user: Set ABI_LLONG_ALIGNMENT to 4 for microblazeRichard Henderson1-1/+3
Based on gcc's microblaze.h setting BIGGEST_ALIGNMENT to 32 bits. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e73f27003e777fd9b77d13e71c5268015b8ed2b6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10linux-user/elfload: Set V in ELF_HWCAP for RISC-VNathan Egge1-1/+2
Set V bit for hwcap if misa is set. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1793 Signed-off-by: Nathan Egge <negge@xiph.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Tested-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230803131424.40744-1-negge@xiph.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 4333f0924c2f2ca8efaebaed8c24f55f77d8b013) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/nvme: fix null pointer access in ruh updateKlaus Jensen1-1/+7
The Reclaim Unit Update operation in I/O Management Receive does not verify the presence of a configured endurance group prior to accessing it. Fix this. Cc: qemu-stable@nongnu.org Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation") Reviewed-by: Jesper Wendel Devantier <j.devantier@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 3439ba9c5da943d96f7a3c86e0a7eb2ff48de41c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-10hw/nvme: fix null pointer access in directive receiveKlaus Jensen1-1/+1
nvme_directive_receive() does not check if an endurance group has been configured (set) prior to testing if flexible data placement is enabled or not. Fix this. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1815 Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation") Reviewed-by: Jesper Wendel Devantier <j.devantier@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 6c8f8456cb0b239812dee5211881426496da7b98) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.1 at 2024-08-04 22:23:48 +0000