Host drivers do not necessarily set cdb_len in megasas io commands.
With commits 6d1511c ("scsi: Reject commands if the CDB length
exceeds buf_len") and fe9d892 ("scsi: Add buf_len parameter to
scsi_req_new()"), this results in failures to boot Linux from affected
SCSI drives because cdb_len is set to 0 by the host driver.
Set the cdb length to its actual size to solve the problem.

Signed-off-by: Guenter Roeck <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Fiona Ebner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>

Drop V9fsFidState's 'next' member, which is no longer used since:

  f5265c8 ('9pfs: use GHashTable for fid table')

Fixes: f5265c8 ('9pfs: use GHashTable for fid table')
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <[email protected]>

After removing a file from the file system, we should still be able to
work with the file if we already had it open before removal.

As a first step we verify that it is possible to write to an unlinked
file, as this is what already works. This test is extended later on
after having fixed other use cases after unlink that are not working
yet.

Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <3d6449d4df25bcdd3e807eff169f46f1385e5257.1732465720.git.qemu_oss@crudebyte.com>

All 9p response types are prefixed with an "R", therefore fix
"READDIR" -> "RREADDIR" in function rmessage_name().

Fixes: 4829469 ("tests/virtio-9p: added readdir test")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <daad7af58b403aaa2487c566032beca36664b30e.1732465720.git.qemu_oss@crudebyte.com>

'Tgetattr' 9p request and its 'Rgetattr' response types are already used
by test client, however this response type is yet missing in function
rmessage_name(), so add it.

Fixes: a6821b8 ("tests/9pfs: compare QIDs in fs_walk_none() test")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <e183da80d390cfd7d55bdbce92f0ff6e3e5cdced.1732465720.git.qemu_oss@crudebyte.com>

The comment claims that we'd only support basic Tgetattr fields. This is
no longer true, so remove this comment.

Fixes: e06a765 ("hw/9pfs: Add st_gen support in getattr reply")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <fb364d12045217a4c6ccd0dd6368103ddb80698b.1732465720.git.qemu_oss@crudebyte.com>

With a valid file ID (FID) of an open file, it should be possible to send
a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response,
even if the file has been removed in the meantime. Currently this would
fail with ENOENT.

I.e. this fixes the following misbehaviour with a 9p Linux client:

  open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
  unlink("/home/tst/filename") = 0
  fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory)

Expected results:

  open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
  unlink("/home/tst/filename") = 0
  fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0

This is because 9p server is always using a path name based lstat() call
which fails as soon as the file got removed. So to fix this, use fstat()
whenever we have an open file descriptor already.

Fixes: 00ede4c ("virtio-9p: getattr server implementation...")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/103
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_oss@crudebyte.com>

This verifies expected behaviour of previous bug fix patch.

Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <7017658155c517b9665b75333a97c79aa2d4f3df.1732465720.git.qemu_oss@crudebyte.com>

…into staging

* Fix open-unlink-fstat idiom on Linux guests.

* Add test to verify this behaviour.

* Cleanup patches.

# -----BEGIN PGP SIGNATURE-----
#
# iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAmdIvDkXHHFlbXVfb3Nz
# QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5X8ixAApDPStDxYf1CGdLirInHGp77i
# 0MlBsuaP00f8bZyCLJCFgax2+ogXD72Ptw2thDDMtkMsg9lqZwOtG5I4cJGC3TK2
# J4ZXpg/mg0bY+4o2gvnyeKv8BFl5wE91pdIeFX8ufQ+L2WE+fasWOn38TFB/T/8Z
# 1naN4A8Mu5F9myJ+F6pIYlJfkgbZniNib9BgSMG8pYI6uayWD+YVjR139ozWCf1c
# vhFFpLrwW4j3DOC0WblghQmiMwhXo1QxNAEq0x31/eoD1+calJAwhWsLWksuVIqR
# 6wbGPfNVozgk9l7owYB5Gams5zVJRfLD5LCAitUx2qqMMzxuD3QldLjOmFA/8XdG
# +2/ROBeXJ51blCAMFdp9IwTKzimvuWVL3kXbcQ3n+D459iBZzqW+9w4EYVYShpp6
# uwAAkW9fwVR/U7ERG3n8D6Cw1B9Scvtjksw/VCe9XUNFp6H66K/OXy8NFmnZZk9K
# K9SYkKOVixwZDqMoGoLsoxx0DbakYL+lBYrl6qVZUPRLOjJ+JvLAoblJ0ZmUgsl2
# lXG7vO96+LyRvVjqPoi2D7+MHrmFoeRgWjzZqFqWOakXBHCKcCEVzpAoB4eYyQrj
# rXC5BNhdu9yIa7Dy7V6tFoXPdN1is90bJs92DYTsOG1KdU2DviAUSZk4MjTJzQWN
# 3fvOcZPFq74228CWrN4=
# =XP1U
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 28 Nov 2024 18:53:45 GMT
# gpg:                using RSA key 96D8D110CF7AF8084F88590134C2B58765A47395
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Christian Schoenebeck <[email protected]>" [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: ECAB 1A45 4014 1413 BA38  4926 30DB 47C3 A012 D5F4
#      Subkey fingerprint: 96D8 D110 CF7A F808 4F88  5901 34C2 B587 65A4 7395

* tag 'pull-9p-20241128' of https://github.com/cschoenebeck/qemu:
  tests/9p: also check 'Tgetattr' in 'use-after-unlink' test
  9pfs: fix 'Tgetattr' after unlink
  9pfs: remove obsolete comment in v9fs_getattr()
  tests/9p: add missing Rgetattr response name
  tests/9p: fix Rreaddir response name
  tests/9p: add 'use-after-unlink' test
  9pfs: cleanup V9fsFidState

Signed-off-by: Peter Maydell <[email protected]>

* amd_iommu: fix clang failure on non-KVM targets
* target/i386/hvf: fix advertised 1G page support
* megasas: fix CDB length

# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmdIokMUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroOpbAf/dxoD/vCFfuMPanIbP4quQGWFTKAo
# x4qlis07s730EWoNzdT42eER+GWcZiT4LhSwAt3EPqjANpnNwcoOGsc5hlJp8emI
# /UbJII90AKLhoJV2gj1xGbRwN1vBJmuBrUQSrLC+5tEr5gFLdHixnlH4pjXGfuF6
# 9eAutgxjRzMiYczsPCev5gbtnvetodP2u9okeQwpQd7N9siCbKx+pB6a67KdvOYn
# tmH0se4ai5w9J4Xnagus/goA5VK5dli6ukvYhLps/LQHj2r7XT6AcPMO7KwFlJkW
# INW0qEzYqa95iH5pNW2lgmJcCn3rp7g1WFVCCocpecp1WpsweVyzMRhGsA==
# =DHEO
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 28 Nov 2024 17:02:59 GMT
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Paolo Bonzini <[email protected]>" [full]
# gpg:                 aka "Paolo Bonzini <[email protected]>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
  scsi: megasas: Internal cdbs have 16-byte length
  hvf: complete 1G page support
  amd_iommu: Fix kvm_enable_x2apic link error with clang in non-KVM builds

Signed-off-by: Peter Maydell <[email protected]>

Allthough the size of MAX_MUX is equal to 4 and likely will never
change, this patch changes type of constant to unsigned long to
be on the safe side.

Also add a static compile check that MAX_MUX never bigger than
`sizeof(d->mux_bitset) * BITS_PER_BYTE`.

Signed-off-by: Roman Penyaev <[email protected]>
Reviewed-by: "Marc-André Lureau" <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Peter Maydell <[email protected]>
Reviewed-by: Clément Mathieu--Drif <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>

This patch simplifies (and makes less confusing) bit checks by
replacing `find_next_bit()` calls with boolean AND operation.

Resolves: Coverity CID 1563776
Signed-off-by: Roman Penyaev <[email protected]>
Reviewed-by: "Marc-André Lureau" <[email protected]>
Cc: Peter Maydell <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Reviewed-by: Clément Mathieu--Drif <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>

 into staging

chardev patch queue

# -----BEGIN PGP SIGNATURE-----
#
# iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmdNp4EcHG1hcmNhbmRy
# ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5WsaD/92DwK0nKM7HqbqQOHN
# lR715V8ve16+mWYZnWA4jQvclFUigg0Xbxl6d6adsK5QnW2nDGgjf3cXsCngUx7K
# jNCmynQrpmUx7a7BRgXylEl5zN/HLeVvk2Qb4Jg8EAkRK0utK1Aerlx6CV2fzbR/
# zDslP+C7ELk9evNwWx6PZRgeOii0sL7lto67J4a5Iri2IU4yi9zI/irEIxeE4cDT
# P3KFXYsgbm86VC6HaOBWw5+d5JyPr2hVHxvKMpI4YNyU/f2RHdhfqgsLS1gms2Yz
# JBuh8DpIq0E+rdQp4ofH5SBPuOFxg7SgDFAyqgHerDd4uAwUafyOfAEVy2hpZmNT
# 3JlavSMb2SFhWboMUu9B+gRHC+sc7YCoPZEhaIaciW3XaC/S1JJi/fvB8gcugBDs
# lgTUIDEsXLMcgXaFNKbRXpuLG5eXRnzaQ4Y9Gr/3yEvY8eSZ6+x3EDwSMGfg/Ta1
# OW+h09AvWfJR5eZ13x+5CCMFRs8RgQN/D+mxYt3cZ/SdNSBci/4By54IGEgGCCM8
# xoTAqcd2kbpHg2S/MTx7O7OPNC38TbUaOWDR6u0qO0ZXqZA6OdlC+g/Z1uu7ZMqA
# FkOTQZuDDgOOhpsmLy4v3nKmFBQNJAPVyfph88DE1QyrU5nVCS55lyTy/ZH2hayL
# RCVbI20jrgEJoi44EFdFu6QP/Q==
# =0vex
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 02 Dec 2024 12:26:41 GMT
# gpg:                using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Marc-André Lureau <[email protected]>" [full]
# gpg:                 aka "Marc-André Lureau <[email protected]>" [full]
# Primary key fingerprint: 87A9 BD93 3F87 C606 D276  F62D DAE8 E109 7596 9CE5

* tag 'chr-pull-request' of https://gitlab.com/marcandre.lureau/qemu:
  chardev/char-mux: make boolean bit check instead of find_next_bit()
  chardev/char-mux: shift unsigned long to avoid 32-bit overflow

Signed-off-by: Peter Maydell <[email protected]>

By using QemuSystemTest as a base class, we can use the set_machine()
command to check whether the required machine is available in the
binary (otherwise this test is failing when QEMU has been compiled
without the default 'pc' machine type).

Message-ID: <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Ani Sinha <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>

…he machine

Use self_set_machine() to set and check for the availability of the
default pc machine (so that the test is not failing if the machine
has not been included in the QEMU binary).

Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>

When under high load the test VM does not complete running in the
default 30 second timeout. Double it to give more headroom.

Signed-off-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>

…into staging

* Fix timeouts in arm-sx1 test
* Check for the "pc" machine in the virtio_version and acpi-bits tests

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmdNvDsRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbXEDBAAkGHlPrQ9JVDjR+SHn4Bjl7DOQbKuLq1T
# MXPSOUvYtX7/F0WOMBXQOXj86iv3HphvlQD/kFYfdogC8trE1gLyk2vGQnwkr0FK
# cZRQZb9wdg8XYJEP++59WEQL8MIS+TcQkjqpUXbT5T3ZSmODc1FMEZinsvChM/C/
# XC6VcRAibpQ6k7189ORWZfmjlbnxbS95+NJ2FZ/c2oyFbA2fJneef5RWcp/0/1hx
# isjRDI9wTb+l12JcRn06Osh9KyjUbz3qaN7HIrsMoMHYtsYOCn4r/MKD56iGp2Aw
# G86nwGyNIZBcfadnL792gu6xda8A915aWIIn6WzRTnGvWKseoub2hHDYrADW0wvV
# 8lsMa2uHoLp1SLRDE4TYWgzsbgO2ueC73T/QPpmkaAdYaRaFpKl3+oT19UsbtqUg
# xzUpR1nM8sdOF9g5OF971z10LaVFRE710UWuiWVRlS3gSXMvQ93PR7rKhM6bM/yM
# x+fP9/X9wka8ZFXQ67XGqPxE4xrXN0JD4wCKH5KysIO9hJ+c2GkZitFV7VB9r365
# VdbWItw/lTznIuQ+54Zm6xB9kskwnp6XAPzSgQwJEwD8wTDRM7vo0G+CTHYtKJ68
# VZVgwkbSMoI0XDMsAoxS4V+wtuOj7UWTYLskHkV7Tqp87oq7cIgEJy3CnvIjWZ0d
# Uh+L0I4qz60=
# =oeWj
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 02 Dec 2024 13:55:07 GMT
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Thomas Huth <[email protected]>" [full]
# gpg:                 aka "Thomas Huth <[email protected]>" [full]
# gpg:                 aka "Thomas Huth <[email protected]>" [full]
# gpg:                 aka "Thomas Huth <[email protected]>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2024-12-02' of https://gitlab.com/thuth/qemu:
  tests/functional: increase timeouts for arm sx1 test
  tests/functional/test_virtio_version: Check for the availability of the machine
  tests/functional/test_acpi_bits: Turn the test into a QemuSystemTest

Signed-off-by: Peter Maydell <[email protected]>

Multifd receive threads run on the destination side.
Correct the thread name marco to indicate the same.

Fixes: e620b1e ("migration: Put thread names together with macros")
Signed-off-by: Prasad Pandit <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>

Commit fa905f6 introduced a machine compatibility parameter to
enable an exclusive bar for msix. It failed to account for this when
cleaning up. Make sure that if an exclusive bar is enabled, we use the
proper cleanup routine.

Cc: [email protected]
Fixes: fa905f6 ("hw/nvme: add machine compatibility parameter to enable msix exclusive bar")
Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>

Only call msix_{un,}use_vector() when interrupts are actually enabled
for a completion queue.

Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>

The PCI Interrupt Pin Register does not apply to VFs and MUST be
hardwired to zero.

Fixes: 44c2c09 ("hw/nvme: Add support for SR-IOV")
Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>

Make sure we grab a reference on the subsystem when a VF is realized.
Otherwise, the subsytem will be unrealized automatically when the VFs
are unregistered and unreffed.

This fixes a latent bug but was not exposed until commit 08f6328
("pcie: Release references of virtual functions"). This was then fixed
(or rather, hidden) by commit c613ad2 ("pcie_sriov: Do not manually
unrealize"), but that was then reverted (due to other issues) in commit
b0fdaee, exposing the bug yet again.

Cc: [email protected]
Fixes: 08f6328 ("pcie: Release references of virtual functions")
Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>

…erx/qemu into staging

Migration pull for 9.2-rc3

- Prasad's one fix on thread name typo

# -----BEGIN PGP SIGNATURE-----
#
# iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCZ04mxBIccGV0ZXJ4QHJl
# ZGhhdC5jb20ACgkQO1/MzfOr1wbyegEAxWBfoGpPoysYOe+ijwMZKgsXylWzHrfJ
# HGlVck7f1RQA/jAwS8aR3t6QZwhL42lXfAlGPX2ebz4IL+f52qs6/nQP
# =L+tL
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 02 Dec 2024 21:29:40 GMT
# gpg:                using EDDSA key B9184DC20CC457DACF7DD1A93B5FCCCDF3ABD706
# gpg:                issuer "[email protected]"
# gpg: Good signature from "Peter Xu <[email protected]>" [marginal]
# gpg:                 aka "Peter Xu <[email protected]>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: B918 4DC2 0CC4 57DA CF7D  D1A9 3B5F CCCD F3AB D706

* tag 'migration-20241202-pull-request' of https://gitlab.com/peterx/qemu:
  migration: correct multifd receive thread name

Signed-off-by: Peter Maydell <[email protected]>

…nto staging

nvme queue

# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmdOpR0ACgkQTeGvMW1P
# DenTOgf/S4+yjo1pkOIyWoDEQZ434eOwXeUqcM8taGwwRB/IyulFBbGexkY8Feu3
# iCYA78FTtGcTCIKWc0ze5TsA2abbrX1mB1IxR3keeYPdQyZPacfxXG5qjjeygU0N
# 2Ws6UZBFZDNBkLxasT6yHBl9oHriz91IjksA62FYr1pXGHfLbluWTyKYghPfoY4t
# ifc0tTSinhsFjKixRvuyUo7AWd+jm29QJbcfhckcPTVZ52VE5FUGg0bWvdLk/zWY
# K4qlPVa2MngV3fSY04Qt1lHuLUCegiHMCjyJHvN3S2nxhJLSWLyE/RU9zUJCXFsd
# HvJ7nKxq8GODjLNghsjOzdL1rxQPdA==
# =yOQB
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 03 Dec 2024 06:28:45 GMT
# gpg:                using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9
# gpg: Good signature from "Klaus Jensen <[email protected]>" [full]
# gpg:                 aka "Klaus Jensen <[email protected]>" [full]
# Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468  4272 63D5 6FC5 E55D A838
#      Subkey fingerprint: 5228 33AA 75E2 DCE6 A247  66C0 4DE1 AF31 6D4F 0DE9

* tag 'pull-nvme-20241203' of https://gitlab.com/birkelund/qemu:
  hw/nvme: take a reference on the subsystem on vf realization
  hw/nvme: SR-IOV VFs must hardwire pci interrupt pin register to zero
  hw/nvme: fix use/unuse of msix vectors
  hw/nvme: fix msix_uninit with exclusive bar

Signed-off-by: Peter Maydell <[email protected]>

We used to only have a single UART on the platform and it was located at
address 0x90000000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.

This caused QEMU to pick 0x90000300 as the default UART, which broke
software that hardcoded the address of 0x90000000 and expected it's
output to be visible when the user configured only a single console.

This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.

Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x90000300 as the default for ttyS0.  To fix
Linux we fix three things in the device tree:

 1. Define stdout-path only one time for the first registered UART
    instead of incorrectly defining for each UART.
 2. Change the UART alias name from 'uart0' to 'serial0' as almost all
    Linux tty drivers look for an alias starting with "serial".
 3. Add the UART nodes so they appear in the final DTB in the
    order starting with the lowest address and working upwards.

In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:

 * serial_hd(0) is the lowest-address UART
 * serial_hd(0) is listed first in the DTB
 * serial_hd(0) is the /chosen/stdout-path one
 * the /aliases/serial0 alias points at serial_hd(0)

[1]: https://lore.barebox.org/barebox/[email protected]/T/#m5da26e8a799033301489a938b5d5667b81cef6ad

Fixes: 777784b ("hw/openrisc: support 4 serial ports in or1ksim")
Cc: [email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
[stafford: Change to serial0 alias and update change message, reverse
 uart registration order]
Signed-off-by: Stafford Horne <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>

In the existing design, TTCR is prone to undercounting when running in
continuous mode. This manifests as a timer interrupt appearing to
trigger a few cycles prior to the deadline set in SPR_TTMR_TP.

When the timer triggers, the virtual time delta in nanoseconds between
the time when the timer was set, and when it triggers is calculated.
This nanoseconds value is then divided by TIMER_PERIOD (50) to compute
an increment of cycles to apply to TTCR.

However, this calculation rounds down the number of cycles causing the
undercounting.

A simplistic solution would be to instead round up the number of cycles,
however this will result in the accumulation of timing error over time.

This patch corrects the issue by calculating the time delta in
nanoseconds between when the timer was last reset and the timer event.
This approach allows the TTCR value to be rounded up, but without
accumulating error over time.

Signed-off-by: Joel Holdsworth <[email protected]>
[stafford: Incremented version in vmstate_or1k_timer, checkpatch fixes]
Signed-off-by: Stafford Horne <[email protected]>

In the existing design, TTCR is prone to undercounting when running in
continuous mode. This manifests as a timer interrupt appearing to
trigger a few cycles prior to the deadline set in SPR_TTMR_TP.

When the timer triggers, the virtual time delta in nanoseconds between
the time when the timer was set, and when it triggers is calculated.
This nanoseconds value is then divided by TIMER_PERIOD (50) to compute
an increment of cycles to apply to TTCR.

However, this calculation rounds down the number of cycles causing the
undercounting.

A simplistic solution would be to instead round up the number of cycles,
however this will result in the accumulation of timing error over time.

This patch corrects the issue by calculating the time delta in
nanoseconds between when the timer was last reset and the timer event.
This approach allows the TTCR value to be rounded up, but without
accumulating error over time.

Signed-off-by: Joel Holdsworth <[email protected]>
[stafford: Incremented version in vmstate_or1k_timer, checkpatch fixes]
Signed-off-by: Stafford Horne <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>

We used to only have a single UART on the platform and it was located at
address 0x90000000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.

This caused QEMU to pick 0x90000300 as the default UART, which broke
software that hardcoded the address of 0x90000000 and expected it's
output to be visible when the user configured only a single console.

This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.

Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x90000300 as the default for ttyS0.  To fix
Linux we fix three things in the device tree:

 1. Define stdout-path only one time for the first registered UART
    instead of incorrectly defining for each UART.
 2. Change the UART alias name from 'uart0' to 'serial0' as almost all
    Linux tty drivers look for an alias starting with "serial".
 3. Add the UART nodes so they appear in the final DTB in the
    order starting with the lowest address and working upwards.

In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:

 * serial_hd(0) is the lowest-address UART
 * serial_hd(0) is listed first in the DTB
 * serial_hd(0) is the /chosen/stdout-path one
 * the /aliases/serial0 alias points at serial_hd(0)

[1]: https://lore.barebox.org/barebox/[email protected]/T/#m5da26e8a799033301489a938b5d5667b81cef6ad

[stafford: Change to serial0 alias and update change message, reverse
 uart registration order]

Fixes: 777784b ("hw/openrisc: support 4 serial ports in or1ksim")
Cc: [email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
Signed-off-by: Stafford Horne <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>

These warnings are breaking some build configurations since 2 months
now (https://gitlab.com/qemu-project/qemu/-/issues/2575):

  ui/cocoa.m:662:14: error: 'CVDisplayLinkCreateWithCGDisplay' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:)  [-Werror,-Wdeprecated-declarations]
    662 |         if (!CVDisplayLinkCreateWithCGDisplay(display, &displayLink)) {
        |              ^
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:89:20: note: 'CVDisplayLinkCreateWithCGDisplay' has been explicitly marked deprecated here
     89 | CV_EXPORT CVReturn CVDisplayLinkCreateWithCGDisplay(
        |                    ^
  ui/cocoa.m:663:29: error: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:)  [-Werror,-Wdeprecated-declarations]
    663 |             CVTime period = CVDisplayLinkGetNominalOutputVideoRefreshPeriod(displayLink);
        |                             ^
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:182:18: note: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' has been explicitly marked deprecated here
    182 | CV_EXPORT CVTime CVDisplayLinkGetNominalOutputVideoRefreshPeriod( CVDisplayLinkRef CV_NONNULL displayLink );
        |                  ^
  ui/cocoa.m:664:13: error: 'CVDisplayLinkRelease' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:)  [-Werror,-Wdeprecated-declarations]
    664 |             CVDisplayLinkRelease(displayLink);
        |             ^
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:249:16: note: 'CVDisplayLinkRelease' has been explicitly marked deprecated here
    249 | CV_EXPORT void CVDisplayLinkRelease( CV_RELEASES_ARGUMENT CVDisplayLinkRef CV_NULLABLE displayLink );
        |                ^
  3 errors generated.

For the next release, ignore the warnings using #pragma directives.
At least until we figure the correct new API usage.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Phil Dennis-Jordan <[email protected]>
Tested-by: Phil Dennis-Jordan <[email protected]>
Message-Id: <[email protected]>

Song Gao is will be sick leave for a long time, I apply for maintainer
for LoongArch Virt Machine during this period, LoongArch TCG keeps unchanged
since I am not familiar with it. The maintainer duty will transfer to him
after he comes back to work.

Signed-off-by: Bibo Mao <[email protected]>
Acked-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>

When USBPacket in OUT direction has larger payload
than the ep_out_buffer (of size 512), a buffer overflow
would occur.

It could be fixed by limiting the size of usb_packet_copy
to be at most buffer size. Further optimization gets rid
of the ep_out_buffer and directly uses ep_out as the target
buffer.

This is reported by a security researcher who artificially
constructed an OUT packet of size 2047. The report has gone
through the QEMU security process, and as this device is for
testing purpose and no deployment of it in virtualization
environment is observed, it is triaged not to be a security bug.

Cc: [email protected]
Fixes: d7d3491 ("hw/usb: Add CanoKey Implementation")
Reported-by: Juan Jose Lopez Jaimez <[email protected]>
Signed-off-by: Hongren Zheng <[email protected]>
Message-id: Z4TfMOrZz6IQYl_h@Sun
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 664280abddcb3cacc9c6204706bb739fcc1316f7)
Signed-off-by: Michael Tokarev <[email protected]>

qemu_ram_alloc_from_fd allocates space if file_size == 0.  If non-zero,
it uses the existing space and verifies it is large enough, but the
verification was broken when the offset parameter was introduced.  As
a result, a file smaller than offset passes the verification and causes
errors later.  Fix that, and update the error message to include offset.

Peter provides this concise reproducer:

  $ touch ramfile
  $ truncate -s 64M ramfile
  $ ./qemu-system-x86_64 -object memory-backend-file,mem-path=./ramfile,offset=128M,size=128M,id=mem1,prealloc=on
  qemu-system-x86_64: qemu_prealloc_mem: preallocating memory failed: Bad address

With the fix, the error message is:
  qemu-system-x86_64: mem1 backing store size 0x4000000 is too small for 'size' option 0x8000000 plus 'offset' option 0x8000000

Cc: [email protected]
Fixes: 4b870dc ("hostmem-file: add offset option")
Signed-off-by: Steve Sistare <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 719168fba7c3215cc996dcfd32a6e5e9c7b8eee0)
Signed-off-by: Michael Tokarev <[email protected]>

Node.js crashes in qemu-system-s390x with random SIGSEGVs / SIGILLs.

The v8 JIT used by Node.js can garbage collect and overwrite unused
code. Overwriting is performed by WritableJitAllocation::CopyCode(),
which ultimately calls memcpy(). For certain sizes, memcpy() uses the
MVC instruction.

QEMU implements MVC and other similar instructions using helpers. While
TCG store ops invalidate affected translation blocks automatically,
helpers must do this manually by calling probe_access_flags(). The MVC
helper does this using the access_prepare() -> access_prepare_nf() ->
s390_probe_access() -> probe_access_flags() call chain.

At the last step of this chain, the store size is replaced with 0. This
causes the probe_access_flags() -> notdirty_write() ->
tb_invalidate_phys_range_fast() chain to miss some translation blocks.

When this happens, QEMU executes a mix of old and new code. This
quickly leads to either a SIGSEGV or a SIGILL in case the old code
ends in the middle of a new instruction.

Fix by passing the true size.

Reported-by: Berthold Gunreben <[email protected]>
Cc: Sarah Kriesch <[email protected]>
Cc: [email protected]
Closes: https://bugzilla.opensuse.org/show_bug.cgi?id=1235709
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Fixes: e2faabe ("accel/tcg: Forward probe size on to notdirty_write")
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e43ced8be18dda77c229ab09f85136a4d600d40d)
Signed-off-by: Michael Tokarev <[email protected]>

b9ad513 ("net: Remove receive_raw()") adds an iovec entry
in qemu_deliver_packet_iov() to add the virtio-net header
in the data when QEMU_NET_PACKET_FLAG_RAW is set but forgets
to increase the number of iovec entries in the array, so
receive_iov() will only send the first entry (the virtio-net
entry, full of 0) and no data. The packet will be discarded.

The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self.

We can see the problem with tcpdump:

- QEMU parameters:

  .. -monitor stdio \
     -netdev bridge,id=netdev0,br=virbr0 \
     -device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \

- HMP command:

  (qemu) announce_self

- TCP dump:

  $ sudo tcpdump -nxi virbr0

  without the fix:

    <nothing>

  with the fix:

   ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f, length 46
        0x0000:  0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
        0x0010:  0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000

Reported-by: Xiaohui Li <[email protected]>
Bug: https://issues.redhat.com/browse/RHEL-73891
Fixes: b9ad513 ("net: Remove receive_raw()")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 84dfdcbff33fff185528501be408c25c44499f32)
Signed-off-by: Michael Tokarev <[email protected]>

When a packet is sent with QEMU_NET_PACKET_FLAG_RAW by QEMU it
never includes virtio-net header even if qemu_get_vnet_hdr_len()
is not 0, and filter-dump is not managing this case.

The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self,
we can show the problem using it and tcpddump:

- QEMU parameters:

  .. -monitor stdio \
     -netdev bridge,id=netdev0,br=virbr0 \
     -device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \
     -object filter-dump,netdev=netdev0,file=log.pcap,id=pcap0

- HMP command:

  (qemu) announce_self

- TCP dump:

  $ tcpdump -nxr log.pcap

  without the fix:

    08:00:06:04:00:03 > 2e:2f:80:35:00:01, ethertype Unknown (0x9a2b), length 50:
         0x0000:  2c2d 2e2f 0000 0000 9a2b 2c2d 2e2f 0000
         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000
         0x0020:  0000 0000

  with the fix:

    ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f, length 46
         0x0000:  0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
         0x0010:  0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
         0x0020:  0000 0000 0000 0000 0000 0000 0000

Fixes: 481c523 ("net: Strip virtio-net header when dumping")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit c6a1b591a68b4d7230d6c3f56965e18080d737e5)
Signed-off-by: Michael Tokarev <[email protected]>

This commit fixes an incorrect format string for formatting integers
provided to GDB when debugging a target run in QEMU user mode.

The correct format is hexadecimal for both success and errno values,
some of which can be seen here [0].

[0] https://github.com/bminor/binutils-gdb/blob/e65a355022d0dc6b5707310876a72b5693ec0aa5/gdbserver/hostio.cc#L196-L213

Signed-off-by: Dominik 'Disconnect3d' Czarnota <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Fixes: e282010 ("gdbstub: Add support for info proc mappings")
Cc: [email protected]
Reviewed-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 8b647bd352505234cab2acd2422aba183a1aa1fd)
Signed-off-by: Michael Tokarev <[email protected]>

This reverts commit 2b05d18.

…sepfw from iOS 14.7.1

Signed-off-by: Michael Tokarev <[email protected]>

v9.2.1 release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmenP10ACgkQgqpKJDse
# lHhYXxAAhSGXrrfEjfyNPO0N5tRKqCzYkoeB5GDScRMb3UogF2/jg/VV2uAVBKnl
# ikCO87w81+8FctiYKfMYnhTk+axlxYq//H8JALX3tyt35BpSfSkyxS8RGzVl4S3l
# 0TMA0l+cs3zPDq+yA3UAhppV5CgwBbzaN8xCm9mNFe49nlIHymgcFc3tFFtS0x+H
# PLjbqGX3X7joyqZ0O2cYk3UwzF01ZR1RKgM3sUumvsoSOwuKGul4jc0iLCn9hTHX
# QdxrThxb9KL5iL+fY5DlYc/LiJNPk1NcU1dQzqJinzrux9wNr4RpF7iSrs+m0Y/d
# 3FNzMTPuiqwBh4JJFGuSguR83q6nJLlVR/kKxPmPNBSX86q4L1Dw0rbyb40ZRGAA
# xV88kv8gzvmhR2hnScn7S+2d3EG9D3DKDCKTPp0unHhMjZk9rP+hcPmQaTqi1CIW
# c400CI2gP0e0a8TFLKTnTFVP2+scvOkVn6rBy9+pQat0eTMgWjA9VSxvG5GRJ4W9
# +i/9RSTyCLy3s7DWX3JN9nytZ5mS/RDv5YB3FfeMlT/1wH5PFYitxHdyxjHrBE+8
# KjXPtqDsJTMvwqPP+2nDD7D1MQWJgz0468GeuPK5itJCYBVYilIOUlibKfAEPbo+
# 0eUtq1oVMJfKnJadARf2cQrzR2IGEWF1rZqrRrkxfl+mHnTxnss=
# =XhYS
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat Feb  8 13:26:21 2025 EET
# gpg:                using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478
# gpg: key 61AD3D98ECDF2C8E: public key "Michael Tokarev <[email protected]>" imported
# gpg: Total number processed: 1
# gpg:               imported: 1
# gpg: Good signature from "Michael Tokarev <[email protected]>" [unknown]
# gpg:                 aka "Michael Tokarev <[email protected]>" [unknown]
# gpg:                 aka "Michael Tokarev <[email protected]>" [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: 9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 ECDF 2C8E
#      Subkey fingerprint: 64AA 2AB5 31D5 6903 366B  FEF9 82AA 4A24 3B1E 9478