- Sep 21, 2023
-
-
Richard Henderson authoredRequire i/o as the last insn of a TranslationBlock always, not only with icount. This is required for i/o that alters the address space, such as a pci config space write. Resolves: qemu-project/qemu#1866 Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org>
-
Richard Henderson authored
Without this we can get see loops through cpu_io_recompile, in which the cpu makes no progress. Signed-off-by:
-
Richard Henderson authored
Initialize can_do_io to true if this the TB has CF_LAST_IO and will consist of a single instruction. This avoids a set to 0 followed immediately by a set to 1. Signed-off-by:
-
Richard Henderson authored
Simplify translator_io_start by recording the current known value of can_do_io within DisasContextBase. Signed-off-by:
-
Philippe Mathieu-Daudé authored
Signed-off-by:
-
Richard Henderson authored
The condition checked is loop invariant; check it only once. Signed-off-by:
-
Richard Henderson authored
With CF_NOIRQ and without !CF_USE_ICOUNT, the load isn't used. Avoid emitting it. Signed-off-by:
-
Richard Henderson authored
After system startup, run the update to memory_dispatch and the tlb_flush on the cpu. This eliminates a race, wherein a running cpu sees the memory_dispatch change but has not yet seen the tlb_flush. Since the update now happens on the cpu, we need not use qatomic_rcu_read to protect the read of memory_dispatch. Resolves: qemu-project/qemu#1826 Resolves: qemu-project/qemu#1834 Resolves: qemu-project/qemu#1846 Tested-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Michael Tokarev <mjt@tls.msk.ru>
-
Michael Tokarev authored
Signed-off-by: -
Marc-André Lureau authored
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: 56a3c24f ("tpm: Probe for connected TPM 1.2 or TPM 2") Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Stefan Berger <stefanb@linux.ibm.com> Signed-off-by:
-
Jonathan Perkin authored
qemu 8.1.0 breaks on illumos platforms due to _XOPEN_SOURCE and others no longer being set correctly, leading to breakage such as: https://us-central.manta.mnx.io/pkgsrc/public/reports/trunk/tools/20230908.1404/qemu-8.1.0/build.log This is a result of meson conversion which incorrectly matches against 'solaris' instead of 'sunos' for uname. First time submitting a patch here, hope I did it correctly. Thanks. Signed-off-by:
Jonathan Perkin <jonathan@perkin.org.uk> Message-ID: <ZPtdxtum9UVPy58J@perkin.org.uk> Cc: qemu-stable@nongnu.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit fb0a8b0e ) Signed-off-by:
-
Janosch Frank authored
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 297ec01f
)
Signed-off-by: -
Marc-André Lureau authored
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:
Albert Esteve <aesteve@redhat.com> (cherry picked from commit 48a35e12 ) Signed-off-by:
-
Marc-André Lureau authored
Don't forget to unmap the resource memory. Fixes: commit 9462ff46 ("virtio-gpu/win32: allocate shareable 2d resources/images") Signed-off-by:
-
小田喜陽彦 authored
riscv_trigger_init() had been called on reset events that can happen several times for a CPU and it allocated timers for itrigger. If old timers were present, they were simply overwritten by the new timers, resulting in a memory leak. Divide riscv_trigger_init() into two functions, namely riscv_trigger_realize() and riscv_trigger_reset() and call them in appropriate timing. The timer allocation will happen only once for a CPU in riscv_trigger_realize(). Fixes: 5a4ae64c ("target/riscv: Add itrigger support when icount is enabled") Signed-off-by:
Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by:
LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by:
Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230818034059.9146-1-akihiko.odaki@daynix.com> Signed-off-by:
-
Leon Schuermann authored
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:
-
Daniel Henrique Barboza authoredIn 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 43d1de32 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: 6f23aaeb ("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:
-
Conor Dooley authoredOn 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:
Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20230727-groom-decline-2c57ce42841c@spud>
Signed-off-by: -
LIU Zhiwei authored
We should not use types dependend on host arch for target_ucontext. This bug is found when run rv32 applications. Signed-off-by:
Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: -
Jason Chien authored
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:
-
Jason Chien authored
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:
-
LIU Zhiwei authored
Commit a47842d1 ("riscv: Add support for the Zfa extension") implemented the zfa extension. However, it has some typos for fleq.d and fltq.d. Both of them misused the fltq.s helper function. Fixes: a47842d1 ("riscv: Add support for the Zfa extension") Signed-off-by:
Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Message-ID: <20230728003906.768-1-zhiwei_liu@linux.alibaba.com> Signed-off-by:
-
LIU Zhiwei authored
Commit bef6f008 (accel/tcg: Return bool from page_check_range) converts integer return value to bool type. However, it wrongly converted the use of the API in riscv fault-only-first, where page_check_range < = 0, should be converted to !page_check_range. Signed-off-by:
-
Daniel Henrique Barboza authored
zmmul was promoted from experimental to ratified in commit 6d00ffad. Add a riscv,isa string for it. Fixes: 6d00ffad ("target/riscv: move zmmul out of the experimental properties") Signed-off-by:
Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: -
Thomas Huth authoredValues 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: a6e13e31 ("riscv_htif: Support console output via proxy syscall") Signed-off-by:
Thomas Huth <thuth@redhat.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: -
Thomas Huth authored
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: 50336067 ("RISC-V HTIF Console") Signed-off-by:
Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: -
coltonlewis authored
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:
Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 682814e2 ) Signed-off-by:
-
Kevin Wolf authored
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: -
Marc-André Lureau authored
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: qemu-project/qemu#1829 Signed-off-by:
Thomas Huth <thuth@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: -
Thomas Huth authored
The assert() that checks for valid MTU sizes can be triggered by the guest (e.g. with the reproducer code from the bug ticket qemu-project/qemu#517 ). Let's avoid this problem by simply logging the error and refusing to activate the device instead. Fixes: d05dcd94 ("net: vmxnet3: validate configuration values during activate") Signed-off-by:
Thomas Huth <thuth@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: -
Markus Armbruster authored
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 cbde7be9 (v6.0.0). Hard to see, as test-hmp doesn't check whether the commands work, and iotest 181 appears to be unaffected. Fixes: 263170e6 (docs: Add a doc about multiple thread compression) Fixes: cbde7be9 (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: -
Thomas Huth authored
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: -
Hang Yu authored
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: 6054fc73 ("aspeed/i2c: Add support for pool buffer transfers") Reviewed-by:
Cédric Le Goater <clg@kaod.org> Signed-off-by:
-
Hang Yu authored
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:
-
Niklas Cassel authored
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:
John Snow <jsnow@redhat.com> (cherry picked from commit 9f894235 ) Signed-off-by:
-
Niklas Cassel authored
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 authored
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 authored
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 authored
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 authored
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:
-
