Skip to content
  1. Jul 25, 2023
    • Niklas Cassel's avatar
      hw/ide/ahci: fix broken SError handling · e8630f15
      Niklas Cassel authored and John Snow's avatar John Snow committed 
      

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: default avatarNiklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-9-nks@flawful.org
Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      e8630f15
    • Niklas Cassel's avatar
      hw/ide/ahci: fix ahci_write_fis_sdb() · 64ce1151
      Niklas Cassel authored and John Snow's avatar John Snow committed 
      

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: default avatarNiklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-8-nks@flawful.org
Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      64ce1151
    • Niklas Cassel's avatar
      hw/ide/ahci: PxCI should not get cleared when ERR_STAT is set · 45dbddd0
      Niklas Cassel authored and John Snow's avatar John Snow committed 
      

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: default avatarNiklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-7-nks@flawful.org
Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      45dbddd0
    • Niklas Cassel's avatar
      hw/ide/ahci: PxSACT and PxCI is cleared when PxCMD.ST is cleared · 7a7d8fd3
      Niklas Cassel authored and John Snow's avatar John Snow committed 
      

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: default avatarNiklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-6-nks@flawful.org
Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      7a7d8fd3
    • Niklas Cassel's avatar
      hw/ide/ahci: simplify and document PxCI handling · 40b70dbd
      Niklas Cassel authored and John Snow's avatar John Snow committed 
      

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: default avatarNiklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-5-nks@flawful.org
Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      40b70dbd
    • Niklas Cassel's avatar
      hw/ide/ahci: write D2H FIS when processing NCQ command · e82ac61e
      Niklas Cassel authored and John Snow's avatar John Snow committed 
      

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: default avatarNiklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-4-nks@flawful.org
Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      e82ac61e
    • Niklas Cassel's avatar
      hw/ide/core: set ERR_STAT in unsupported command completion · 7bf13d29
      Niklas Cassel authored and John Snow's avatar John Snow committed 
      

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: default avatarNiklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-3-nks@flawful.org
Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      7bf13d29
    • Peter Maydell's avatar
      Merge tag 'pull-target-arm-20230725' of... · a279ca4e
      Peter Maydell authored 
      Merge tag 'pull-target-arm-20230725' of https://git.linaro.org/people/pmaydell/qemu-arm into staging

target-arm queue:
 * tests/decode: Suppress "error: " string for expected-failure tests
 * ui/curses: For curses display, recognize a few more control keys
 * target/arm: Special case M-profile in debug_helper.c code
 * scripts/git-submodule.sh: Don't rely on non-POSIX 'read' behaviour
 * hw/arm/smmu: Handle big-endian hosts correctly

# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmS/ot8ZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3slqEACaLJwIYl1bJBfCda2u53+C
# q20t50SQjkvV2CSW6A9uOHPPahKUcxAXh6K+d54BhzD6Dsrv5g1rpo/2fnNhHDSG
# 7fHlla+fPnywmAOahE2FPUw4pckRX1tpPIM1RDjM9szLYqkJlShKYP28QsLu1Eku
# bnTty6OcId5hAZILag53QLwL9EYsVYoCEe6xRcgY3He0UZcCEisCUdfeCXEN1Uc8
# 57wd+q3KNUTgOScqmDJRAH2NaET0UOYlUvQGVu8/Bh3t0huQCtfyT4gc8z7v/TZ8
# 2PfI6bFb9nei09avxhBMN9Nu7BVD6eHBkAAe4JHDBhkJKCZn+LASDCMUAFPrFD2V
# NeIObNHBMaE9FqIG/SZxf7kEOaFcUwt4GrVfQNguaqiXIwALsfT/jiX4r+jXX4WS
# ii0mdoS2ZuAcRtUhTA7S6x44B3wa47sidSogoe3t2k8ObYB/AZ34F1cSZDgEmIG7
# nobJE2OgzSRMWUHXhCUEzGvn8MMPeI0HQmKr4sOD6CnlqHIzLZDH4Jx0DL4yvoyc
# XLs0D2G4yscUTtWh15R/nTWTJKxjumbs05bqwRKLTMsVj6kpDDY/EqhHMvB6Xm70
# z+xDGki9xsBOTGRO7GdqGlWEKfnwUIPjipwy9crhsjSe121XrP8uwmmDBL1tOLgc
# L+geqtruzJgFmo3rOBGxXA==
# =4paq
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 25 Jul 2023 11:24:31 BST
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# gpg:                 aka "Peter Maydell <peter@archaic.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* tag 'pull-target-arm-20230725' of https://git.linaro.org/people/pmaydell/qemu-arm

:
  tests/decode: Suppress "error: " string for expected-failure tests
  For curses display, recognize a few more control keys
  target/arm: Special case M-profile in debug_helper.c code
  scripts/git-submodule.sh: Don't rely on non-POSIX 'read' behaviour
  hw/arm/smmu: Handle big-endian hosts correctly

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      a279ca4e
    • Peter Maydell's avatar
      tests/decode: Suppress "error: " string for expected-failure tests · 78cc9034
      Peter Maydell authored 
      

The "expected failure" tests for decodetree result in the
error messages from decodetree ending up in logs and in
V=1 output:

>>> MALLOC_PERTURB_=226 /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/x86/pyvenv/bin/python3 /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/scripts/decodetree.py --output-null --test-for-error /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/x86/../../tests/decode/err_argset1.decode
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀  ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/x86/../../tests/decode/err_argset1.decode:5: error: duplicate argument "a"
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
 1/44 qemu:decodetree / err_argset1                OK              0.05s

This then produces false positives when scanning the
logfiles for strings like "error: ".

For the expected-failure tests, make decodetree print
"detected:" instead of "error:".

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20230720131521.1325905-1-peter.maydell@linaro.org
      78cc9034
    • Sean Estabrooks's avatar
      For curses display, recognize a few more control keys · 9b579543
      Sean Estabrooks authored and Peter Maydell's avatar Peter Maydell committed 
      

The curses display handles most control-X keys, and translates
them into their corresponding keycode.  Here we recognize
a few that are missing, Ctrl-@ (null), Ctrl-\ (backslash),
Ctrl-] (right bracket), Ctrl-^ (caret), Ctrl-_ (underscore).

Signed-off-by: default avatarSean Estabrooks <sean.estabrooks@gmail.com>
Message-id: CAHyVn3Bh9CRgDuOmf7G7Ngwamu8d4cVozAcB2i4ymnnggBXNmg@mail.gmail.com
Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      9b579543
    • Peter Maydell's avatar
      target/arm: Special case M-profile in debug_helper.c code · 5d78893f
      Peter Maydell authored 
      A lot of the code called from helper_exception_bkpt_insn() is written
assuming A-profile, but we will also call this helper on M-profile
CPUs when they execute a BKPT insn.  This used to work by accident,
but recent changes mean that we will hit an assert when some of this
code calls down into lower level functions that end up calling
arm_security_space_below_el3(), arm_el_is_aa64(), and other functions
that now explicitly assert that the guest CPU is not M-profile.

Handle M-profile directly to avoid the assertions:
 * in arm_debug_target_el(), M-profile debug exceptions always
   go to EL1
 * in arm_debug_exception_fsr(), M-profile always uses the short
   format FSR (compare commit d7fe699b, though in this case
   the code in arm_v7m_cpu_do_interrupt() does not need to
   look at the FSR value at all)

Cc: qemu-stable@nongnu.org
Resolves: #1775


Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-id: 20230721143239.1753066-1-peter.maydell@linaro.org
      5d78893f
    • Peter Maydell's avatar
      scripts/git-submodule.sh: Don't rely on non-POSIX 'read' behaviour · f9540bb1
      Peter Maydell authored 
      The POSIX definition of the 'read' utility requires that you
specify the variable name to set; omitting the name and
having it default to 'REPLY' is a bashism. If your system
sh is dash, then it will print an error message during build:

qemu/pc-bios/s390-ccw/../../scripts/git-submodule.sh: 106: read: arg count

Specify the variable name explicitly.

Fixes: fdb8fd8c

 ("git-submodule: allow partial update of .git-submodule-status")
Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230720153038.1587196-1-peter.maydell@linaro.org
      f9540bb1
    • Peter Maydell's avatar
      hw/arm/smmu: Handle big-endian hosts correctly · c6445544
      Peter Maydell authored 
      

The implementation of the SMMUv3 has multiple places where it reads a
data structure from the guest and directly operates on it without
doing a guest-to-host endianness conversion.  Since all SMMU data
structures are little-endian, this means that the SMMU doesn't work
on a big-endian host.  In particular, this causes the Avocado test
  machine_aarch64_virt.py:Aarch64VirtMachine.test_alpine_virt_tcg_gic_max
to fail on an s390x host.

Add appropriate byte-swapping on reads and writes of guest in-memory
data structures so that the device works correctly on big-endian
hosts.

As part of this we constrain queue_read() to operate only on Cmd
structs and queue_write() on Evt structs, because in practice these
are the only data structures the two functions are used with, and we
need to know what the data structure is to be able to byte-swap its
parts correctly.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Tested-by: Thomas Huth's avatarThomas Huth <thuth@redhat.com>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Eric Auger's avatarEric Auger <eric.auger@redhat.com>
Message-id: 20230717132641.764660-1-peter.maydell@linaro.org
Cc: qemu-stable@nongnu.org
      c6445544
  3. Jul 24, 2023
  5. Jul 23, 2023