qemu.git
3 months agohw/pci: Use -1 as the default value for rombar
Akihiko Odaki [Mon, 12 Feb 2024 10:20:29 +0000 (19:20 +0900)]
hw/pci: Use -1 as the default value for rombar

vfio_pci_size_rom() distinguishes whether rombar is explicitly set to 1
by checking dev->opts, bypassing the QOM property infrastructure.

Use -1 as the default value for rombar to tell if the user explicitly
set it to 1. The property is also converted from unsigned to signed.
-1 is signed so it is safe to give it a new meaning. The values in
[2 ^ 31, 2 ^ 32) become invalid, but nobody should have typed these
values by chance.

Suggested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250104-reuse-v18-13-c349eafd8673@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agoMerge tag 'pull-request-2025-01-08' of https://gitlab.com/thuth/qemu into staging
Stefan Hajnoczi [Wed, 8 Jan 2025 16:38:20 +0000 (11:38 -0500)]
Merge tag 'pull-request-2025-01-08' of https://gitlab.com/thuth/qemu into staging

* Fix compilation problem in s390x tcg tests
* Remove obsolete versioned s390x machine types 2.4 up to 2.8
* Remove deprecated -runas command line option
* Fix the x86_64_hotplug_cpu functional test

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmd+OikRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbXTig/+Kgt0H5KQzCvGuRDYYD20Iq9MLy8iTJdj
# bmPyjyMWI88Mm4qjZUO2Kcv/MSEP3MhnaTLEE/PJYgE2D8Cq2AFMLQf4ES01Uzwt
# kFBSHvAlTOgcMFcu6QiWtetlqbqixuPs146J9vvUde1xTWCpB2FuB+wNneSTl6J1
# Ilrb7SM2TzbZ1s3NPuvBSVltQlA8MYa5VdQMvljAZGe2GE5vlpNjXmJMiZ/QJ7lp
# +LVZppbB5lYxH0SYf56r2tR8fxqfQi6W4WoGeuBf9FnDf815cbcwagpOnaJiQFzx
# iG1WusLt1tlW2arBDP7dzrjNjByjMFhwJvKaoXuSnGS29ivPuVq33mBkcFh80cv3
# 8rElZR+M5tmGfbC/mMwH7FSesUrEH18ZwRyc9RGqZ/QtqoBaukBJpxk6KuyNUbWn
# 3x0ZUbGhAItGGNaZ54T70LdM3dTmEISMOnp5YTlv8oUFoROhfvWn20FMIge0Ib7t
# Epu/nSiHzzdtURHZ1Z8EKNmCOmiKRW4WpF34hzQ+4uid5BAsCNMVMe0JZy5plN9L
# V78CZ4qiqipmHIpKnI81x8L2admyJ3nklYKSRkaCmZFhpSyh8rdMUjCgt9A6xFfe
# 34Jha7+MrJq9nnoeYIH/dS1Jhv+9vygNahDy9XaWXIHFPd7Nrsr79BWSC3fe1w5O
# DlsdrHyGHvU=
# =II7e
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 08 Jan 2025 03:41:13 EST
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg:                 aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg:                 aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg:                 aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2025-01-08' of https://gitlab.com/thuth/qemu:
  tests/functional/test_x86_64_hotplug_cpu: Fix race condition during unplug
  docs/about/deprecated: Remove paragraph about initial deprecation in 2.10
  Remove the deprecated "-runas" command line option
  hw/s390x: Remove the "adapter_routes_max_batch" property from the flic
  hw/s390x/s390-virtio-ccw: Remove the deprecated 2.8 machine type
  hw/s390x: Remove the cpu_model_allowed flag and related code
  hw/s390x/s390-virtio-ccw: Remove the deprecated 2.7 machine type
  hw/s390x/css-bridge: Remove the "css_dev_path" property
  hw/s390x/ipl: Remove the "iplbext_migration" property
  hw/s390x: Remove the "ri_allowed" switch
  hw/s390x/s390-virtio-ccw: Remove the deprecated 2.6 machine type
  hw/s390x/s390-skeys: Remove the "migration-enabled" property
  hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine types
  tests/tcg/s390x: Use the SLOF libc headers for the multiarch tests

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
3 months agotests/functional/test_x86_64_hotplug_cpu: Fix race condition during unplug
Thomas Huth [Tue, 7 Jan 2025 11:52:45 +0000 (12:52 +0100)]
tests/functional/test_x86_64_hotplug_cpu: Fix race condition during unplug

When unplugging the CPU, the test tries to check for a successful
unplug by changing to the /sys/devices/system/cpu/cpu1 directory
to see whether that fails. However, the "cd" could be faster than
the unplug operation in the kernel, so there is a race condition
and the test sometimes fails here.
Fix it by trying to change the directory in a loop until the the
CPU has really been unplugged.
While we're at it, also add a "cd .." before unplugging to make
the console output a little bit less confusing (since the path
is echoed in the shell prompt).

Reported-by: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20250107115245.52755-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agodocs/about/deprecated: Remove paragraph about initial deprecation in 2.10
Thomas Huth [Fri, 3 Jan 2025 14:57:02 +0000 (15:57 +0100)]
docs/about/deprecated: Remove paragraph about initial deprecation in 2.10

When we introduced the deprecation rule of keeping deprecated features
for two more releases, we had to state that we would not remove features
by surprise that had already been marked as deprecated before. Nowadays,
this paragraph is not needed anymore, so we can remove it now.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250103145702.597139-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agoRemove the deprecated "-runas" command line option
Thomas Huth [Fri, 3 Jan 2025 15:54:11 +0000 (16:54 +0100)]
Remove the deprecated "-runas" command line option

It has been marked as deprecated two releases ago, so it should
be fine now to remove this command line option.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250103155411.721759-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x: Remove the "adapter_routes_max_batch" property from the flic
Thomas Huth [Fri, 3 Jan 2025 14:42:32 +0000 (15:42 +0100)]
hw/s390x: Remove the "adapter_routes_max_batch" property from the flic

Now that the s390-ccw-virtio-2.8 machine has been removed, we don't
need the "adapter_routes_max_batch" property anymore and can remove it.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-11-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x/s390-virtio-ccw: Remove the deprecated 2.8 machine type
Thomas Huth [Fri, 3 Jan 2025 14:42:31 +0000 (15:42 +0100)]
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.8 machine type

The s390-ccw-virtio-2.8 machine is older than 6 years, so according to
our machine support policy, it can be removed now.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-10-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x: Remove the cpu_model_allowed flag and related code
Thomas Huth [Fri, 3 Jan 2025 14:42:30 +0000 (15:42 +0100)]
hw/s390x: Remove the cpu_model_allowed flag and related code

Now that the last machine type that disabled cpu_model_allowed has
been removed, we can also remove the cpu_model_allowed flag itself
and all the related conditional code.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-9-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x/s390-virtio-ccw: Remove the deprecated 2.7 machine type
Thomas Huth [Fri, 3 Jan 2025 14:42:29 +0000 (15:42 +0100)]
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.7 machine type

The s390-ccw-virtio-2.7 machine is older than 6 years, so according to
our machine support policy, it can be removed now.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-8-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x/css-bridge: Remove the "css_dev_path" property
Thomas Huth [Fri, 3 Jan 2025 14:42:28 +0000 (15:42 +0100)]
hw/s390x/css-bridge: Remove the "css_dev_path" property

Now that the s390-ccw-virtio-2.6 and older machine types have been
removed, the "css_dev_path" property of the css-bridge is also not
used anymore and thus can be removed.

This way we finally get rid of the problem that has been described
in: https://gitlab.com/qemu-project/qemu/-/issues/2213

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-7-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x/ipl: Remove the "iplbext_migration" property
Thomas Huth [Fri, 3 Jan 2025 14:42:27 +0000 (15:42 +0100)]
hw/s390x/ipl: Remove the "iplbext_migration" property

Now that the old machine types that used this property have been
removed, we can remove the property and the corresponding code.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-6-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x: Remove the "ri_allowed" switch
Thomas Huth [Fri, 3 Jan 2025 14:42:26 +0000 (15:42 +0100)]
hw/s390x: Remove the "ri_allowed" switch

Only s390-ccw-virtio-2.6 and older used to set this switch to "off",
for newer machine types it is always enabled. Since we removed the
old machine types now, we can also remove the switch in the code and
assume that it is always enabled now.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-5-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x/s390-virtio-ccw: Remove the deprecated 2.6 machine type
Thomas Huth [Fri, 3 Jan 2025 14:42:25 +0000 (15:42 +0100)]
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.6 machine type

The s390-ccw-virtio-2.6 machine is older than 6 years, so according to
our machine support policy, it can be removed now.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-4-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x/s390-skeys: Remove the "migration-enabled" property
Thomas Huth [Fri, 3 Jan 2025 14:42:24 +0000 (15:42 +0100)]
hw/s390x/s390-skeys: Remove the "migration-enabled" property

This property was only set to "off" by the old s390-ccw-virtio-2.4
machine type which has now been removed. So we can now remove the
property and the related code, too.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-3-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agohw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine types
Thomas Huth [Fri, 3 Jan 2025 14:42:23 +0000 (15:42 +0100)]
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine types

They are older than 6 years, so according to our machine support
policy, they can be removed now.

This removes the requirements for the storage keys "migration-enabled"
property which will be removed in the next patch. It also removes
the code that sets "max_revision" to 0 for some CCW devices, but the
relating code in virtio-ccw.c indicates that 0 could have also been in
use for other machines types < 5.1, so further clean-up for code related
to "max_revision" won't be done yet (see also commit d55f518248f -
"virtio: skip legacy support check on machine types less than 5.1").

Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Message-ID: <20250103144232.520383-2-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/tcg/s390x: Use the SLOF libc headers for the multiarch tests
Ilya Leoshkevich [Mon, 16 Dec 2024 13:37:56 +0000 (14:37 +0100)]
tests/tcg/s390x: Use the SLOF libc headers for the multiarch tests

Compiling the s390x tests on Fedora, which has the s390x cross-compiler
installed, fails with:

    In file included from qemu/tests/tcg/s390x/console.c:8:
    qemu/tests/tcg/s390x/../../../pc-bios/s390-ccw/sclp.c:11:10: fatal error: string.h: No such file or directory
       11 | #include <string.h>

This is because Fedora does not have a cross-libc. Since console.c
already uses the SLOF libc implementation, add the respective headers
to the include path.

Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241216133819.78583-1-iii@linux.ibm.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agoMerge tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu into staging
Stefan Hajnoczi [Mon, 6 Jan 2025 14:39:02 +0000 (09:39 -0500)]
Merge tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu into staging

qga-pull-2025-01-06

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEwsLBCepDxjwUI+uE711egWG6hOcFAmd7vqMACgkQ711egWG6
# hOffRxAAotgBsE+o8fsZ2tfOKNPekW0hlw/hceDMJRA2UwOSPfw1fXfw59w4Pnfr
# 4xwMC6O8Lu9ohBCBWHUvh3261gJgXQkLASbbzmF2oewfXZyvPXQI8nz78Ol3LBTG
# gL8lwaBci3YuFtc+2/55VdQsWUqtrRMvBW9WSXTEC+0dQJv+VzblXlEF7hQkKppT
# oGiHQL7pEA1UP7bRo4TyaoDnc8a+xz1J+vtEZUZghtreT7I3ELai/PFdo0U99fkf
# HZfjyj2sHCZto+tAokjBcqf2RXDRqUVRsn3GgC1MQbh1LRdfShmhCTbgYYk/1MmD
# 0xwiqAsw814W25299LM3xP2LHPm1jKtkZyCyuSXme9QtN9mC3F0TipR+HMRErAj0
# GQTBOJ0LinZsx5U/+ih4/qPj7RRov+SFzpVxBV3NUkpneVFp5FQgOo4n8l+h57ap
# fmkZ6/hb8itn2oux7S9v/LkcmWE3FqThKO6qMXOhBhQDCKpICz8liYO/tPdB4x1Q
# /HHQ9oon0A2eQw/53AYqz0SoazOqNtadg/hsQ11OHDExUjdp4M6hyxtmrJEQz4Et
# AFvIby98lJZCZ1u65dv/Prb+gW0E8AQ5Ib0jJllAm7tL/GjVyhbRlUl8S9R2uTcZ
# Gsb6e3DMBOny/lR9+2M4rCyCqXM58gTohuqtcXvAe8l2a3h23B4=
# =uk2Q
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 06 Jan 2025 06:29:39 EST
# gpg:                using RSA key C2C2C109EA43C63C1423EB84EF5D5E8161BA84E7
# gpg: Good signature from "Kostiantyn Kostiuk (Upstream PR sign) <kkostiuk@redhat.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: C2C2 C109 EA43 C63C 1423  EB84 EF5D 5E81 61BA 84E7

* tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu:
  qemu-ga: Optimize freeze-hook script logic of logging error
  qga: implement a 'guest-get-load' command

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
3 months agoqemu-ga: Optimize freeze-hook script logic of logging error
Dehan Meng [Wed, 25 Dec 2024 08:37:44 +0000 (16:37 +0800)]
qemu-ga: Optimize freeze-hook script logic of logging error

Make sure the error log of fsfreeze hooks
when freeze/thaw/snapshot could be logged
to system logs if the default logfile of
qga can't be written or other situations

Signed-off-by: Dehan Meng <demeng@redhat.com>
Reviewed-by: Yan Vugenfirer <yvugenfi@redhat.com>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <20241225083744.277374-1-demeng@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
3 months agoqga: implement a 'guest-get-load' command
Daniel P. Berrangé [Mon, 2 Dec 2024 12:19:27 +0000 (12:19 +0000)]
qga: implement a 'guest-get-load' command

Provide a way to report the process load average, via a new
'guest-get-load' command.

This is only implemented for POSIX platforms providing 'getloadavg'.

Example illustrated with qmp-shell:

(QEMU) guest-get-load
{
    "return": {
        "load15m": 1.546875,
        "load1m": 1.669921875,
        "load5m": 1.9306640625
    }
}

Windows has no native equivalent API, but it would be possible to
simulate it as illustrated here (BSD-3-Clause):

  https://github.com/giampaolo/psutil/pull/1485

This is left as an exercise for future contributors.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <20241202121927.864335-1-berrange@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
3 months agoMerge tag 'qtest-20250102-pull-request' of https://gitlab.com/farosas/qemu into staging
Stefan Hajnoczi [Fri, 3 Jan 2025 14:14:11 +0000 (09:14 -0500)]
Merge tag 'qtest-20250102-pull-request' of https://gitlab.com/farosas/qemu into staging

Qtest pull request

- migration-test: fix UADK build, reinstate postcopy tests and other cleanups
- a couple of memory leak fixes for bios-tables-test and virtio-iommu-test
- drop dead code from fw_cfg-test

# -----BEGIN PGP SIGNATURE-----
#
# iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmd3DSMQHGZhcm9zYXNA
# c3VzZS5kZQAKCRDHmNx0G+wxnUy5EACPnvy3U2jen2Cc5Hke69byCQtMkDTAJHH5
# xlwTLoTEF25AXMjLyee9vM4MoDHl+EUaGd3zmmAu2/P5/zOHWrBh9VbkFKDDvJJS
# XTVSZ0Iv9a0LDGKsv74Pk7LUZCEanr9a0qpfYTFPuwUh9yu7pd4QeYpbEdwzKzX6
# TMpJTYOE5gUTgP6X8Ir6u3po8DChfE9Eb+Z3LhRU7S+Xi3FoUWRFgRzuvXhXLkf3
# SPNEA27XCaqWQjG8SfQ9yhafrEz9OIGq39Q2unSJ8Df8riYurrdhxYrWNZ/6URQi
# /sYoBJZ2IMBzLg4cVOWXXQwdFkmU+0LUYPOANy6MrYRXl1QJtWway3eHOj+ZlkIH
# r2ulAJWAXqIQ3Ki6Dv3TYCg0/snF8arFzmdsaAbn0M8YYQB7XAlcqHus5axEMIVO
# 0VG7rXctRyH2h7DFfKeW/G1aaK5ox+/0aJoVhjmFJSlYZ2DUx+htfsPlIJmwhRRF
# i61VaOw7NsrHsW0fEgTRurQBVVuZ2/nJT8saJwvXpFiJu0X1GQ6lmKQNlWqm5h6C
# JyLc096+vOG0Cqih7p+M3NvKTHNQZQzUPSLJU2UXItPDPv1oAmFrHpVlBQiUD37I
# h/2R6vxZIY5ei2ECFITnl+LaV4MNjGExpeOEi020KSLEz9Y8nk+i5E+4oDUct93z
# wAsWLadmxg==
# =sLkH
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 02 Jan 2025 17:03:15 EST
# gpg:                using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D
# gpg:                issuer "farosas@suse.de"
# gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown]
# gpg:                 aka "Fabiano Almeida Rosas <fabiano.rosas@suse.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: AA1B 48B0 A223 26A5 A4C3  64CF C798 DC74 1BEC 319D

* tag 'qtest-20250102-pull-request' of https://gitlab.com/farosas/qemu:
  qtest/fw-cfg: remove compiled out code
  tests/qtest/migration: Re-enable postcopy tests
  tests/migration: Drop arch_[source|target]
  tests/qtest/virtio-iommu-test: Don't pass uninitialized data into qtest_memwrite
  tests/qtest/bios-tables-test: Free tables at dump_aml_files
  tests/qtest/migration: Initialize buffer in probe_o_direct_support
  tests/qtest/migration: Do proper cleanup in the dirty_limit test
  tests/qtest/migration: Fix compile errors when CONFIG_UADK is set

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
3 months agoqtest/fw-cfg: remove compiled out code
Ani Sinha [Wed, 1 Jan 2025 08:15:55 +0000 (13:45 +0530)]
qtest/fw-cfg: remove compiled out code

Remove code that is already compiled out. This prevents confusion.

CC: qemu-trivial@nongnu.org
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20250101081555.1050736-1-anisinha@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
3 months agotests/qtest/migration: Re-enable postcopy tests
Fabiano Rosas [Wed, 18 Dec 2024 19:22:22 +0000 (16:22 -0300)]
tests/qtest/migration: Re-enable postcopy tests

Postcopy tests have been inadvertently disabled since commit
124a3c58b8 ("tests/qtest/migration: Move ufd_version_check to
utils"). That commit moved the ufd_version_check() function to another
file but failed to make sense of the ifdefs and includes:

The <sys/syscall> include was incorrectly dropped. It is needed to
pull in <asm/unistd.h> for __NR_userfaultfd.

The <sys/ioctl.h> was moved under the wrong ifdef.

Fixes: 124a3c58b8 ("tests/qtest/migration: Move ufd_version_check to utils")
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-Id: <20241218192223.10551-2-farosas@suse.de>

3 months agotests/migration: Drop arch_[source|target]
Peter Xu [Mon, 16 Dec 2024 16:14:13 +0000 (11:14 -0500)]
tests/migration: Drop arch_[source|target]

Coverity complained about them. These two variables are never used now
after commit 832c732c5d ("migration-test: Create arch_opts"), and/or commit
34cc54fb35 ("tests/qtest/migration-test: Use custom asm bios for ppc64").

Resolves: Coverity CID 1568379
Resolves: Coverity CID 1568380
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20241216161413.1644171-4-peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
3 months agotests/qtest/virtio-iommu-test: Don't pass uninitialized data into qtest_memwrite
Fabiano Rosas [Mon, 9 Dec 2024 20:44:25 +0000 (17:44 -0300)]
tests/qtest/virtio-iommu-test: Don't pass uninitialized data into qtest_memwrite

Valgrind complains about:

Use of uninitialised value of size 8
&
Conditional jump or move depends on uninitialised value(s)

both at:
   at 0x5265931: _itoa_word (_itoa.c:180)
   by 0x527EEC7: __vfprintf_internal (vfprintf-internal.c:1687)
   by 0x528C8B0: __vsprintf_internal (iovsprintf.c:96)
   by 0x526B920: sprintf (sprintf.c:30)
   by 0x1296C7: qtest_memwrite (libqtest.c:1273)
   by 0x193C04: send_map (virtio-iommu-test.c:125)
   by 0x194392: test_attach_detach (virtio-iommu-test.c:214)
   by 0x17BDE7: run_one_test (qos-test.c:181)
   by 0x4B0699D: test_case_run (gtestutils.c:2900)
   by 0x4B0699D: g_test_run_suite_internal (gtestutils.c:2988)
   by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005)
   by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005)
   by 0x4B068B2: g_test_run_suite_internal (gtestutils.c:3005)
 Uninitialised value was created by a stack allocation
   at 0x193AFD: send_map (virtio-iommu-test.c:103)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20241209204427.17763-5-farosas@suse.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
3 months agotests/qtest/bios-tables-test: Free tables at dump_aml_files
Fabiano Rosas [Mon, 9 Dec 2024 20:44:24 +0000 (17:44 -0300)]
tests/qtest/bios-tables-test: Free tables at dump_aml_files

The dump_aml_files() function calls load_expected_aml() to allocate
the tables but never frees it. Add the missing call to
free_test_data().

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20241209204427.17763-4-farosas@suse.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
3 months agotests/qtest/migration: Initialize buffer in probe_o_direct_support
Fabiano Rosas [Mon, 9 Dec 2024 20:44:23 +0000 (17:44 -0300)]
tests/qtest/migration: Initialize buffer in probe_o_direct_support

Valgrind complains about the probe_o_direct_support() function reading
from an uninitialized buffer. For probing O_DIRECT support we don't
actually need to write to the file, just make sure the pwrite call
doesn't reject the write. Still, write zeroes to the buffer to
suppress the warning.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20241209204427.17763-3-farosas@suse.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
3 months agotests/qtest/migration: Do proper cleanup in the dirty_limit test
Fabiano Rosas [Mon, 9 Dec 2024 20:44:22 +0000 (17:44 -0300)]
tests/qtest/migration: Do proper cleanup in the dirty_limit test

The dirty_limit test does two migrations in a row and is leaking the
first 'to' instance. Do proper cleanup.

Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20241209204427.17763-2-farosas@suse.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
3 months agotests/qtest/migration: Fix compile errors when CONFIG_UADK is set
Shameer Kolothum [Tue, 17 Dec 2024 13:10:46 +0000 (13:10 +0000)]
tests/qtest/migration: Fix compile errors when CONFIG_UADK is set

Removes accidental inclusion of unrelated functions within CONFIG_UADK
as this causes compile errors like:

error: redefinition of ‘migrate_hook_start_xbzrle’

Fixes: 932f74f3fe6e ("tests/qtest/migration: Split compression tests from migration-test.c")
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-Id: <20241217131046.83844-1-shameerali.kolothum.thodi@huawei.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
3 months agoMerge tag 'pull-request-2025-01-02' of https://gitlab.com/thuth/qemu into staging
Stefan Hajnoczi [Thu, 2 Jan 2025 14:35:06 +0000 (09:35 -0500)]
Merge tag 'pull-request-2025-01-02' of https://gitlab.com/thuth/qemu into staging

* Update year in copyright statements
* Convert the VNC test to the functional framework
* Improve and update the ppc64_hv functional test
* Fix broken rx_gdbsim and arm_quanta_gsj functional tests

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmd2alsRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbW+phAAhIWX1KlU6nHh6GUKmEgDmvFKn+eE4NlJ
# BP97GUI5jsYAXgq1jqVsSw2xWzjNXVSUGq/J0jPjZElz+iAJWortCef9Ga46A9eS
# qx7MjeNsLiTnaJZwLDtu6w4f9t1vdNnyBIZULV9whevn/GMF4MO4s2aBCTbIG0xT
# 9HBbuVgAaz3Ga+ZWEt9kYt4OsTbWIdmLTDpKiti2qteP0WR7Hyqgztd828JSHk3R
# a98jSdNgObXODacOcis2e0kr5+C1eEYjqggkxeFao1ZXdbn95MFYT1q+WBofVYPR
# fnHmGkIUaJixXApd6DCo2oou99aO8nW/Y6zkj8vraQaSCqCi7NhEmuguN55apyLJ
# uwzMneECZ8Yf0kOAmRT6u0BqHEXqHXaHj9YzJ6fBxKol0WVfjkCyUQ4Ozke/xFQ9
# XeVAXIus/D42OPoO2buERt+Be99TMYUV5RCIoSah2D0pwI65CyQXSpb++mah9SUI
# qrUtn58Z6fcnNGrzScv0c4ZjfNwxm8Rk7hMdThCiy2PDkcYu4L5tm4TPGRm2kzG3
# MNQXEjtVHc2nQmwEZA0piBhEDoWXvcGaps9E8SlQ+MGaXqCsK11eTC6rQY1rI+ZV
# 1XOXenJ2O77SCacZZb2UZk2WleTjcOsaZAMniRM7oML4zOYgCZbYq+zNdoMoTQ6E
# t/2V8B24SrQ=
# =9Hki
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 02 Jan 2025 05:28:43 EST
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg:                 aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg:                 aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg:                 aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2025-01-02' of https://gitlab.com/thuth/qemu:
  tests/functional/test_arm_quanta_gsj: Fix broken test
  tests/functional/test_rx_gdbsim: Use stable URL for test_linux_sash
  tests/functional/test_ppc64_hv: Update to Alpine 3.21.0
  tests/functional/test_ppc64_hv: Update repo management
  tests/functional/test_ppc64_hv: Simplify console handling
  tests/functional: Extract the find_free_ports() function into a helper file
  tests/functional/test_vnc: Remove the test_no_vnc test
  tests/functional/test_vnc: Do not use a hard-coded VNC port
  tests/functional: Convert the vnc test
  docs: update copyright date to the year 2025

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
3 months agotests/functional/test_arm_quanta_gsj: Fix broken test
Thomas Huth [Thu, 2 Jan 2025 07:30:35 +0000 (08:30 +0100)]
tests/functional/test_arm_quanta_gsj: Fix broken test

ASSET_IMAGE needs to be prefixed with "self." ... this bug
apparently went in unnoticed because the test is not run by
default.

Message-ID: <20250102073403.36328-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional/test_rx_gdbsim: Use stable URL for test_linux_sash
Philippe Mathieu-Daudé [Sun, 29 Dec 2024 08:34:19 +0000 (09:34 +0100)]
tests/functional/test_rx_gdbsim: Use stable URL for test_linux_sash

Yoshinori said [*] URL references on OSDN were stable, but they
appear not to be. Mirror the artifacts on GitHub to avoid failures
while testing on CI.

[*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg686487.html

Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Reported-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-ID: <20200630202631.7345-1-f4bug@amsat.org>
[huth: Adapt the patch to the new version in the functional framework]
Message-ID: <20241229083419.180423-1-huth@tuxfamily.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional/test_ppc64_hv: Update to Alpine 3.21.0
Nicholas Piggin [Fri, 20 Dec 2024 02:46:17 +0000 (12:46 +1000)]
tests/functional/test_ppc64_hv: Update to Alpine 3.21.0

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20241220024617.1968556-5-npiggin@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional/test_ppc64_hv: Update repo management
Nicholas Piggin [Fri, 20 Dec 2024 02:46:16 +0000 (12:46 +1000)]
tests/functional/test_ppc64_hv: Update repo management

`setup-apkrepos` can be used to set repos rather than open-coding URLs.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20241220024617.1968556-4-npiggin@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional/test_ppc64_hv: Simplify console handling
Nicholas Piggin [Fri, 20 Dec 2024 02:46:15 +0000 (12:46 +1000)]
tests/functional/test_ppc64_hv: Simplify console handling

Since functional tests have character-based console output parsing,
there is no need for strange hacks to work around old line-based.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20241220024617.1968556-3-npiggin@gmail.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional: Extract the find_free_ports() function into a helper file
Thomas Huth [Wed, 18 Dec 2024 13:14:38 +0000 (14:14 +0100)]
tests/functional: Extract the find_free_ports() function into a helper file

We'll need this functionality in other functional tests, too, so
let's extract it into the qemu_test module.
Also add  an __enter__ and __exit__ function that can be used for
using this functionality in a locked context, so that tests that
are running in parallel don't try to compete for the same ports
later.
Also make sure to only use ports in the "Dynamic Ports" range
(see https://www.rfc-editor.org/rfc/rfc6335) and "randomize" the
start of the probed range with the PID of the test process to
further avoid possible clashes with other competing processes.

Message-ID: <20241218131439.255841-5-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional/test_vnc: Remove the test_no_vnc test
Thomas Huth [Wed, 18 Dec 2024 13:14:36 +0000 (14:14 +0100)]
tests/functional/test_vnc: Remove the test_no_vnc test

This test matches exactly the first three lines of the following
test_no_vnc_change_password test, so there is exactly zero additional
test coverage in here.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20241218131439.255841-3-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional/test_vnc: Do not use a hard-coded VNC port
Thomas Huth [Wed, 18 Dec 2024 13:14:37 +0000 (14:14 +0100)]
tests/functional/test_vnc: Do not use a hard-coded VNC port

Two tests here are using the hard-coded VNC port :0 ... if there
is already a QEMU or other program running that is using this
port, the tests will be failing. Fortunately, QEMU can also
auto-detect a free port with the "to=..." parameter, so let's
use that for the tests to avoid the problem.

Message-ID: <20241218131439.255841-4-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agotests/functional: Convert the vnc test
Thomas Huth [Wed, 18 Dec 2024 13:14:35 +0000 (14:14 +0100)]
tests/functional: Convert the vnc test

Nothing thrilling in here, it's just a straight forward conversion.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241218131439.255841-2-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agodocs: update copyright date to the year 2025
Ani Sinha [Wed, 1 Jan 2025 08:01:16 +0000 (13:31 +0530)]
docs: update copyright date to the year 2025

We are already in January 2025! Update copyright notices.

Cc: peter.maydell@linaro.org
Cc: qemu-trivial@nongnu.org
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20250101080116.1050336-1-anisinha@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
3 months agoMerge tag 'hw-misc-20241231' of https://github.com/philmd/qemu into staging
Stefan Hajnoczi [Wed, 1 Jan 2025 20:17:07 +0000 (15:17 -0500)]
Merge tag 'hw-misc-20241231' of https://github.com/philmd/qemu into staging

Misc HW patches queue

- Allow more than 4 legacy IRQs on Generic PCI Express Bridge (Alexander)
- Add MMIO-based Inter-VM shared memory device 'ivshmem-flat' (Gustavo)
- Use UHCI register definitions (Guenter)
- Propagate CPU endianness to microblaze_load_kernel (Philippe)
- Mark x86/TriCore devices as little-endian, OpenRISC/SPARC as big (Philippe)
- Don't set callback_opaque NULL in fw_cfg_modify_bytes_read (Shameer)
- Simplify non-KVM checks on AMD IOMMU XTSup feature (Philippe)
- Trivial cleanups on xilinx_ethlite, vmcoreinfo, qxl (Philippe, Hyman)
- Move USB-HCD-XHCI msi/msix properties from NEC to superclass (Phil)
- Redesign of main thread event handling due to macOS Cocoa (Phil)
- Introduce ParavirtualizedGraphics.Framework support 'apple-gfx' (Phil)
- Pad short Ethernet frames on macOS vmnet (William)

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmd0Ul0ACgkQ4+MsLN6t
# wN7sCA/9HFWahKYW+6Y+gHfLPvJzkIqC5mwfQAUY7GsrNVFdIpUjK9ln9xUEqCQz
# DkVxoZQcP++d8cnnl17wXHsRcavyDDadGU5/161eNC7fbKbLRAslObz/dtExxDn2
# sctx9HMcbLl1UMFPqi/Pbt8NEZr0iOLzDDl+nRuOK8QRFnd2zGm1lF1oHeyja3t1
# flnQKI9YD0U/+0RVNR2FOpUam2Fu1EuQEPp0jMwkmcoyoNLwCXrP9XyRybVZnzgM
# cFm9fYbVlwjsVia+Bsk3CmHX5Gna/1bS3CL8Y9gUScYYwYU5VDAA8Fvv4gPsa4+u
# WSyttL2qCFdgF75S5FoAvEQzYFBcw25eFf8jJhbEn4I6MuQew8lww5OZEyvE8rag
# 2hg3nc4W0x76mLunqrNm+h+Z3vqd/amFcd9YNZjpzxQK//TwvOAQTWi31VtWa4OF
# F1qdv78tQKkRY7noq8WkcL/io6D7iE/BMx/XIOF8uPf8BLIBMvPDnDABjaB/yLkS
# Q/e+/monxkhknDY6K9xkVei7rn6c0LkuLzKxVzEzVKPVzM8N0JAl/1KaNVO8fxjJ
# kLvfGP/RdYOZqG4dNi8W3PhV/+UZz1FS3L1MpI4NXQ59br57BbVQP9ARGO6WpPWn
# O9zIJOAqdzcWU0aULIsvQA3nC1iJnFHEovq0bl8qBbY51k26Lg0=
# =AL3L
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 31 Dec 2024 15:21:49 EST
# gpg:                using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD  6BB2 E3E3 2C2C DEAD C0DE

* tag 'hw-misc-20241231' of https://github.com/philmd/qemu: (29 commits)
  hw/display/qxl: Do not use C99 // comments
  net/vmnet: Pad short Ethernet frames
  MAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF
  hw/display/apple-gfx: Adds configurable mode list
  hw/display/apple-gfx: Adds PCI implementation
  hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support
  ui & main loop: Redesign of system-specific main thread event handling
  hw/usb/hcd-xhci: Unimplemented/guest error logging for port MMIO
  hw/usb/hcd-xhci-pci: Move msi/msix properties from NEC to superclass
  hw/block/virtio-blk: Replaces request free function with g_free
  hw/i386/amd_iommu: Simplify non-KVM checks on XTSup feature
  hw/misc/vmcoreinfo: Rename opaque pointer as 'opaque'
  hw/misc/vmcoreinfo: Declare QOM type using DEFINE_TYPES macro
  fw_cfg: Don't set callback_opaque NULL in fw_cfg_modify_bytes_read()
  hw/net/xilinx_ethlite: Rename rxbuf -> port_index
  hw/net/xilinx_ethlite: Correct maximum RX buffer size
  hw/net/xilinx_ethlite: Update QOM style
  hw/net/xilinx_ethlite: Remove unuseful debug logs
  hw/net/xilinx_ethlite: Convert some debug logs to trace events
  hw/sparc: Mark devices as big-endian
  ...

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
3 months agoMerge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
Stefan Hajnoczi [Wed, 1 Jan 2025 20:14:50 +0000 (15:14 -0500)]
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging

trivial patches for 2024-12-31

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmd0C88ACgkQgqpKJDse
# lHjRoxAAgfdMuMScLk4K4OprUfTEyPIT2Fmp2sAcMqpciQO0JDP6RIyKbt+GVyK5
# aqYWwRxjBhwlmbHQH8TaFkdbv5SSZIHwU5087QP09YDVzlmSOfF+/SySUC7H/jKL
# 4zgumF2lc0+P5OftAbnrU8UlrapTlkxcI8sEBSl5Mz7NOv7cCoVzGu0KnlMQyh8q
# nrdyk7QJl/HdF4mMTlTtnNCcr5oz7wAKadoFS40pIHLU9jt49s2OyQLL2OTEjF30
# yAM5EULfoWYbUk6GBH55ZzBSIL1g4U53khDzi3/i8b8HMUU4c2VHueipZB51k1Xx
# KcK2CkRMtK1/UCQ5J7RL6X6GwJxXfQ2wYprEpcixxah9Pl99dTqUh3Uko58jglGt
# uDoIoiUyIJBUOedlZdeapH5BbesexwrM6x6bIVcluVy3l/IuDZ1UfIASxRgdqkEN
# kBGJhK01S3hZT0chxVIOXCB6NbOj0IF7D/Wh3lB/nuP9QwizaiK3eT9ThJYKERSC
# x69EKlsvwcrb+8HL8H3hfQ9CbuNru9mrnifFLntSaQdMXg5P0/mUb+sEs/cgtB+j
# 8tVYYEVOa4JKK2O+SVxt/o+JMZcFxOMAwEwRnGjokvY3uhWJdgSieUC5ZbKQyxF6
# JqK0os12p2LUbnXWPm9cbA4s8bEnu7cjeNwGEPhwzJnQIre1oUw=
# =eAHD
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 31 Dec 2024 10:20:47 EST
# gpg:                using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478
# gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown]
# gpg:                 aka "Michael Tokarev <mjt@corpit.ru>" [unknown]
# gpg:                 aka "Michael Tokarev <mjt@tls.msk.ru>" [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

* tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu:
  Revert "vvfat: fix ubsan issue in create_long_filename"

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
3 months agohw/display/qxl: Do not use C99 // comments
Hyman Huang [Thu, 19 Dec 2024 18:46:57 +0000 (02:46 +0800)]
hw/display/qxl: Do not use C99 // comments

Do not use C99 // comments to fix the checkpatch.pl error

Signed-off-by: Hyman Huang <yong.huang@smartx.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <7d287eaf00e0b52b600431efd350b15a0b5b3544.1734633496.git.yong.huang@smartx.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agonet/vmnet: Pad short Ethernet frames
William Hooper [Sat, 6 Jan 2024 22:35:46 +0000 (14:35 -0800)]
net/vmnet: Pad short Ethernet frames

At least on macOS 12.7.2, vmnet doesn't pad Ethernet frames, such as the
host's ARP replies, to the minimum size (60 bytes before the frame check
sequence) defined in IEEE Std 802.3-2022, so guests' Ethernet device
drivers may drop them with "frame too short" errors.

This patch calls eth_pad_short_frame() to add padding, as in net/tap.c
and net/slirp.c. Thanks to Bin Meng, Philippe Mathieu-Daudé, and Phil
Dennis-Jordan for reviewing earlier versions.

Signed-off-by: William Hooper <wsh@wshooper.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2058
Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
Message-ID: <20241102205653.30476-1-wsh@wshooper.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agoMAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF
Phil Dennis-Jordan [Mon, 15 Jul 2024 21:07:04 +0000 (23:07 +0200)]
MAINTAINERS: Add myself as maintainer for apple-gfx, reviewer for HVF

I'm happy to take responsibility for the macOS PV graphics code. As
HVF patches don't seem to get much attention at the moment, I'm also
adding myself as designated reviewer for HVF and x86 HVF to try and
improve that.

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Roman Bolshakov <rbolshakov@ddn.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241223221645.29911-6-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/display/apple-gfx: Adds configurable mode list
Phil Dennis-Jordan [Mon, 15 Jul 2024 21:07:03 +0000 (23:07 +0200)]
hw/display/apple-gfx: Adds configurable mode list

This change adds a property 'display_modes' on the graphics device
which permits specifying a list of display modes. (screen resolution
and refresh rate)

The property is an array of a custom type to make the syntax slightly
less awkward to use, for example:

-device '{"driver":"apple-gfx-pci", "display-modes":["1920x1080@60", "3840x2160@60"]}'

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-5-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/display/apple-gfx: Adds PCI implementation
Phil Dennis-Jordan [Mon, 15 Jul 2024 21:06:57 +0000 (23:06 +0200)]
hw/display/apple-gfx: Adds PCI implementation

This change wires up the PCI variant of the paravirtualised
graphics device, mainly useful for x86-64 macOS guests, implemented
by macOS's ParavirtualizedGraphics.framework. It builds on code
shared with the vmapple/mmio variant of the PVG device.

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-4-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support
Phil Dennis-Jordan [Wed, 14 Jun 2023 22:57:33 +0000 (22:57 +0000)]
hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

MacOS provides a framework (library) that allows any vmm to implement a
paravirtualized 3d graphics passthrough to the host metal stack called
ParavirtualizedGraphics.Framework (PVG). The library abstracts away
almost every aspect of the paravirtualized device model and only provides
and receives callbacks on MMIO access as well as to share memory address
space between the VM and PVG.

This patch implements a QEMU device that drives PVG for the VMApple
variant of it.

Signed-off-by: Alexander Graf <graf@amazon.com>
Co-authored-by: Alexander Graf <graf@amazon.com>
Subsequent changes:

 * Cherry-pick/rebase conflict fixes, API use updates.
 * Moved from hw/vmapple/ (useful outside that machine type)
 * Overhaul of threading model, many thread safety improvements.
 * Asynchronous rendering.
 * Memory and object lifetime fixes.
 * Refactoring to split generic and (vmapple) MMIO variant specific
   code.

Implementation wise, most of the complexity lies in the differing threading
models of ParavirtualizedGraphics.framework, which uses libdispatch and
internal locks, versus QEMU, which heavily uses the BQL, especially during
memory-mapped device I/O. Great care has therefore been taken to prevent
deadlocks by never calling into PVG methods while holding the BQL, and
similarly never acquiring the BQL in a callback from PVG. Different strategies
have been used (libdispatch, blocking and non-blocking BHs, RCU, etc.)
depending on the specific requirements at each framework entry and exit point.

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-3-phil@philjordan.eu>
[PMD: Re-ordered imported headers, style fixups]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agoui & main loop: Redesign of system-specific main thread event handling
Phil Dennis-Jordan [Thu, 24 Oct 2024 10:27:59 +0000 (12:27 +0200)]
ui & main loop: Redesign of system-specific main thread event handling

macOS's Cocoa event handling must be done on the initial (main) thread
of the process. Furthermore, if library or application code uses
libdispatch, the main dispatch queue must be handling events on the main
thread as well.

So far, this has affected Qemu in both the Cocoa and SDL UIs, although
in different ways: the Cocoa UI replaces the default qemu_main function
with one that spins Qemu's internal main event loop off onto a
background thread. SDL (which uses Cocoa internally) on the other hand
uses a polling approach within Qemu's main event loop. Events are
polled during the SDL UI's dpy_refresh callback, which happens to run
on the main thread by default.

As UIs are mutually exclusive, this works OK as long as nothing else
needs platform-native event handling. In the next patch, a new device is
introduced based on the ParavirtualizedGraphics.framework in macOS.
This uses libdispatch internally, and only works when events are being
handled on the main runloop. With the current system, it works when
using either the Cocoa or the SDL UI. However, it does not when running
headless. Moreover, any attempt to install a similar scheme to the
Cocoa UI's main thread replacement fails when combined with the SDL
UI.

This change tidies up main thread management to be more flexible.

 * The qemu_main global function pointer is a custom function for the
   main thread, and it may now be NULL. When it is, the main thread
   runs the main Qemu loop. This represents the traditional setup.
 * When non-null, spawning the main Qemu event loop on a separate
   thread is now done centrally rather than inside the Cocoa UI code.
 * For most platforms, qemu_main is indeed NULL by default, but on
   Darwin, it defaults to a function that runs the CFRunLoop.
 * The Cocoa UI sets qemu_main to a function which runs the
   NSApplication event handling runloop, as is usual for a Cocoa app.
 * The SDL UI overrides the qemu_main function to NULL, thus
   specifying that Qemu's main loop must run on the main
   thread.
 * The GTK UI also overrides the qemu_main function to NULL.
 * For other UIs, or in the absence of UIs, the platform's default
   behaviour is followed.

This means that on macOS, the platform's runloop events are always
handled, regardless of chosen UI. The new PV graphics device will
thus work in all configurations. There is no functional change on other
operating systems.

Implementing this via a global function pointer variable is a bit
ugly, but it's probably worth investigating the existing UI thread rule
violations in the SDL (e.g. #2537) and GTK+ back-ends. Fixing those
issues might precipitate requirements similar but not identical to those
of the Cocoa UI; hopefully we'll see some kind of pattern emerge, which
can then be used as a basis for an overhaul. (In fact, it may turn
out to be simplest to split the UI/native platform event thread from the
QEMU main event loop on all platforms, with any UI or even none at all.)

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-2-phil@philjordan.eu>
[PMD: Declare 'qemu_main' symbol in tests/qtest/fuzz/fuzz.c,
      add missing g_assert_not_reached() call in main()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/usb/hcd-xhci: Unimplemented/guest error logging for port MMIO
Phil Dennis-Jordan [Fri, 27 Dec 2024 12:13:34 +0000 (13:13 +0100)]
hw/usb/hcd-xhci: Unimplemented/guest error logging for port MMIO

The XHCI device code uses tracing rather than logging on various code
paths that are so far unimplemented. In some cases, these code paths
actually indicate faulty guest software. This patch switches instances
in the read and write handlers for the port MMIO region to use
qemu_log_mask() with LOG_UNIMP or LOG_GUEST_ERROR, as appropriate in
each case.

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241227121336.25838-5-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/usb/hcd-xhci-pci: Move msi/msix properties from NEC to superclass
Phil Dennis-Jordan [Sun, 8 Dec 2024 19:16:42 +0000 (20:16 +0100)]
hw/usb/hcd-xhci-pci: Move msi/msix properties from NEC to superclass

The NEC XHCI controller exposes the underlying PCI device's msi and
msix properties, but the superclass and thus the qemu-xhci device do
not. There does not seem to be any obvious reason for this limitation.
This change moves these properties to the superclass so they are
exposed by both PCI XHCI device variants.

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241227121336.25838-3-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/block/virtio-blk: Replaces request free function with g_free
Phil Dennis-Jordan [Thu, 24 Oct 2024 10:28:12 +0000 (12:28 +0200)]
hw/block/virtio-blk: Replaces request free function with g_free

The virtio_blk_free_request() function has been a 1-liner forwarding
to g_free() for a while now. We may as well call g_free on the request
pointer directly.

Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241223221645.29911-14-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/i386/amd_iommu: Simplify non-KVM checks on XTSup feature
Philippe Mathieu-Daudé [Fri, 29 Nov 2024 11:15:40 +0000 (12:15 +0100)]
hw/i386/amd_iommu: Simplify non-KVM checks on XTSup feature

Generic code wanting to access KVM specific methods should
do so being protected by the 'kvm_enabled()' helper.

Doing so avoid link failures when optimization is disabled
(using --enable-debug), see for example commits c04cfb4596a
("hw/i386: fix short-circuit logic with non-optimizing builds")
and 0266aef8cd6 ("amd_iommu: Fix kvm_enable_x2apic link error
with clang in non-KVM builds").

XTSup feature depends on KVM, so protect the whole block
checking the XTSup feature with a check on whether KVM is
enabled.

Since x86_cpus_init() already checks APIC ID > 255 imply
kernel support for irqchip and X2APIC, remove the confuse
and unlikely reachable "AMD IOMMU xtsup=on requires support
on the KVM side" message.

Fix a type in "configuration" in error message.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Message-Id: <20241129155802.35534-1-philmd@linaro.org>

3 months agohw/misc/vmcoreinfo: Rename opaque pointer as 'opaque'
Philippe Mathieu-Daudé [Thu, 19 Dec 2024 13:46:11 +0000 (14:46 +0100)]
hw/misc/vmcoreinfo: Rename opaque pointer as 'opaque'

Both QEMUResetHandler and FWCfgWriteCallback take an opaque
pointer argument, no need to cast.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20241219153857.57450-3-philmd@linaro.org>

3 months agohw/misc/vmcoreinfo: Declare QOM type using DEFINE_TYPES macro
Philippe Mathieu-Daudé [Thu, 19 Dec 2024 13:30:35 +0000 (14:30 +0100)]
hw/misc/vmcoreinfo: Declare QOM type using DEFINE_TYPES macro

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20241219153857.57450-2-philmd@linaro.org>

3 months agofw_cfg: Don't set callback_opaque NULL in fw_cfg_modify_bytes_read()
Shameer Kolothum [Tue, 3 Dec 2024 13:18:06 +0000 (13:18 +0000)]
fw_cfg: Don't set callback_opaque NULL in fw_cfg_modify_bytes_read()

On arm/virt platform, Chen Xiang reported a Guest crash while
attempting the below steps,

1. Launch the Guest with nvdimm=on
2. Hot-add a NVDIMM dev
3. Reboot
4. Guest boots fine.
5. Reboot again.
6. Guest boot fails.

QEMU_EFI reports the below error:
ProcessCmdAddPointer: invalid pointer value in "etc/acpi/tables"
OnRootBridgesConnected: InstallAcpiTables: Protocol Error

Debugging shows that on first reboot(after hot adding NVDIMM),
Qemu updates the etc/table-loader len,

qemu_ram_resize()
  fw_cfg_modify_file()
     fw_cfg_modify_bytes_read()

And in fw_cfg_modify_bytes_read() we set the "callback_opaque" for
the key entry to NULL. Because of this, on the second reboot,
virt_acpi_build_update() is called with a NULL "build_state" and
returns without updating the ACPI tables. This seems to be
upsetting the firmware.

To fix this, don't change the callback_opaque in fw_cfg_modify_bytes_read().

Fixes: bdbb5b1706d165 ("fw_cfg: add fw_cfg_machine_reset function")
Reported-by: chenxiang <chenxiang66@hisilicon.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Message-ID: <20241203131806.37548-1-shameerali.kolothum.thodi@huawei.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/net/xilinx_ethlite: Rename rxbuf -> port_index
Philippe Mathieu-Daudé [Sat, 9 Nov 2024 18:29:55 +0000 (19:29 +0100)]
hw/net/xilinx_ethlite: Rename rxbuf -> port_index

'rxbuf' is the index of the dual port RAM used.
Rename it as 'port_index'.

Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20241112181044.92193-8-philmd@linaro.org>

3 months agohw/net/xilinx_ethlite: Correct maximum RX buffer size
Philippe Mathieu-Daudé [Sat, 9 Nov 2024 18:32:56 +0000 (19:32 +0100)]
hw/net/xilinx_ethlite: Correct maximum RX buffer size

The current max RX bufsize is set to 0x800. This is
invalid, since it contains the MMIO registers region.
Add the correct definition (valid for both TX & RX,
see datasheet p. 20, Table 11 "XPS Ethernet Lite MAC
Memory Map") and use it.

Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20241112181044.92193-6-philmd@linaro.org>

3 months agohw/net/xilinx_ethlite: Update QOM style
Philippe Mathieu-Daudé [Sat, 9 Nov 2024 18:28:39 +0000 (19:28 +0100)]
hw/net/xilinx_ethlite: Update QOM style

Use XlnxXpsEthLite typedef, OBJECT_DECLARE_SIMPLE_TYPE macro;
convert type_init() to DEFINE_TYPES().

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20241112181044.92193-5-philmd@linaro.org>

3 months agohw/net/xilinx_ethlite: Remove unuseful debug logs
Philippe Mathieu-Daudé [Sat, 9 Nov 2024 18:26:49 +0000 (19:26 +0100)]
hw/net/xilinx_ethlite: Remove unuseful debug logs

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20241112181044.92193-4-philmd@linaro.org>

3 months agohw/net/xilinx_ethlite: Convert some debug logs to trace events
Philippe Mathieu-Daudé [Sat, 9 Nov 2024 18:25:28 +0000 (19:25 +0100)]
hw/net/xilinx_ethlite: Convert some debug logs to trace events

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20241112181044.92193-3-philmd@linaro.org>

3 months agohw/sparc: Mark devices as big-endian
Philippe Mathieu-Daudé [Wed, 6 Nov 2024 17:43:47 +0000 (17:43 +0000)]
hw/sparc: Mark devices as big-endian

These devices are only used by the SPARC targets, which are
only built as big-endian. Therefore the DEVICE_NATIVE_ENDIAN
definition expand to DEVICE_BIG_ENDIAN (besides, the
DEVICE_LITTLE_ENDIAN case isn't tested). Simplify directly
using DEVICE_BIG_ENDIAN.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20241106184612.71897-6-philmd@linaro.org>

3 months agohw/openrisc: Mark devices as big-endian
Philippe Mathieu-Daudé [Wed, 6 Nov 2024 17:42:06 +0000 (17:42 +0000)]
hw/openrisc: Mark devices as big-endian

The openrisc little-endian control is in a control register:
SR[LEE] (which we do not implement at present).

These devices are only used by the OpenRISC target, which is
only built as big-endian. Therefore the DEVICE_NATIVE_ENDIAN
definition expand to DEVICE_BIG_ENDIAN (besides, the
DEVICE_LITTLE_ENDIAN case isn't tested). Simplify directly
using DEVICE_BIG_ENDIAN.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-Id: <20241106184612.71897-5-philmd@linaro.org>

3 months agohw/tricore: Mark devices as little-endian
Philippe Mathieu-Daudé [Wed, 6 Nov 2024 17:44:01 +0000 (17:44 +0000)]
hw/tricore: Mark devices as little-endian

These devices are only used by the TriCore target, which is
only built as little-endian. Therefore the DEVICE_NATIVE_ENDIAN
definition expand to DEVICE_LITTLE_ENDIAN (besides, the
DEVICE_BIG_ENDIAN case isn't tested). Simplify directly using
DEVICE_LITTLE_ENDIAN.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-Id: <20241106184612.71897-3-philmd@linaro.org>

3 months agohw/i386: Mark devices as little-endian
Philippe Mathieu-Daudé [Wed, 6 Nov 2024 17:45:11 +0000 (17:45 +0000)]
hw/i386: Mark devices as little-endian

These devices are only used by the X86 targets, which are only
built as little-endian. Therefore the DEVICE_NATIVE_ENDIAN
definition expand to DEVICE_LITTLE_ENDIAN (besides, the
DEVICE_BIG_ENDIAN case isn't tested). Simplify directly using
DEVICE_LITTLE_ENDIAN.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-Id: <20241106184612.71897-2-philmd@linaro.org>

3 months agohw/microblaze: Propagate CPU endianness to microblaze_load_kernel()
Philippe Mathieu-Daudé [Mon, 4 Nov 2024 15:36:49 +0000 (16:36 +0100)]
hw/microblaze: Propagate CPU endianness to microblaze_load_kernel()

Pass vCPU endianness as argument so we can load kernels
with different endianness (different from the qemu-system-binary
builtin one).

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20241107012223.94337-3-philmd@linaro.org>

3 months agohw/usb/uhci: Introduce and use register defines
Guenter Roeck [Fri, 6 Sep 2024 12:25:36 +0000 (05:25 -0700)]
hw/usb/uhci: Introduce and use register defines

Introduce defines for UHCI registers to simplify adding register access
in subsequent patches of the series.

No functional change.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20240906122542.3808997-3-linux@roeck-us.net>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/usb/uhci: checkpatch cleanup
Guenter Roeck [Fri, 6 Sep 2024 12:25:35 +0000 (05:25 -0700)]
hw/usb/uhci: checkpatch cleanup

Fix reported checkpatch issues to prepare for next patches
in the series.

No functional change.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20240906122542.3808997-2-linux@roeck-us.net>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/misc/ivshmem: Rename ivshmem to ivshmem-pci
Gustavo Romero [Mon, 27 Nov 2023 05:20:24 +0000 (05:20 +0000)]
hw/misc/ivshmem: Rename ivshmem to ivshmem-pci

Because now there is also an MMIO ivshmem device (ivshmem-flat.c), and
ivshmem.c is a PCI specific implementation, rename it to ivshmem-pci.c.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
Message-ID: <20241216141818.111255-5-gustavo.romero@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agohw/misc/ivshmem-flat: Add ivshmem-flat device
Gustavo Romero [Mon, 27 Nov 2023 05:20:20 +0000 (05:20 +0000)]
hw/misc/ivshmem-flat: Add ivshmem-flat device

Add a new device, ivshmem-flat, which is similar to the ivshmem PCI but
does not require a PCI bus. It's meant to be used on machines like those
with Cortex-M MCUs, which usually lack a PCI/PCIe bus, e.g. lm3s6965evb
and mps2-an385.

The device currently only supports the sysbus bus.

The new device, just like the ivshmem PCI device, supports both peer
notification via hardware interrupts and shared memory.

The device shared memory size can be set using the 'shmem-size' option
and it defaults to 4 MiB, which is the default size of shmem allocated
by the ivshmem server.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1134
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
[PMD: Rebased updating Property and using DEFINE_TYPES macro]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241216141818.111255-2-gustavo.romero@linaro.org>

3 months agoRevert "vvfat: fix ubsan issue in create_long_filename"
Michael Tokarev [Sun, 29 Dec 2024 21:08:50 +0000 (00:08 +0300)]
Revert "vvfat: fix ubsan issue in create_long_filename"

This reverts commit 0cb3ff7c22671aa1e1e227318799ccf6762c3bea.

The original code was right in that long name in LFN directory
entry uses other parts of the entry for the name too, not just
the original "name" field.  So it is wrong to limit the offset
to be within the name field.  Some other mechanism is needed
to fix the ubsan report and whole messy usage of bytes past the
given field.

Reported-by: Volker Rümelin <vr_qemu@t-online.de>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
3 months agohw/pci-host/gpex: Allow more than 4 legacy IRQs
Alexander Graf [Wed, 14 Jun 2023 22:56:24 +0000 (22:56 +0000)]
hw/pci-host/gpex: Allow more than 4 legacy IRQs

Some boards such as vmapple don't do real legacy PCI IRQ swizzling.
Instead, they just keep allocating more board IRQ lines for each new
legacy IRQ. Let's support that mode by giving instantiators a new
"nr_irqs" property they can use to support more than 4 legacy IRQ lines.
In this mode, GPEX will export more IRQ lines, one for each device.

Signed-off-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241223221645.29911-9-phil@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
3 months agoMerge tag 'pull-request-2024-12-29' of https://gitlab.com/huth/qemu into staging
Stefan Hajnoczi [Sun, 29 Dec 2024 08:25:40 +0000 (03:25 -0500)]
Merge tag 'pull-request-2024-12-29' of https://gitlab.com/huth/qemu into staging

* Rework "next-cube" to bring it up-to-date with current coding standards/APIs
* Remove overlapping memory regions of the "next-cube" machine
* Encapsulate the next-cube SCSI related code into a separate device
* QOM-ify the next-rtc device
* Declare m68k devices as big endian instead of native endian
* Disable the CD-ROM drive for the next-cube machine

# -----BEGIN PGP SIGNATURE-----
#
# iQJHBAABCAAxFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmdw93wTHGh1dGhAdHV4
# ZmFtaWx5Lm9yZwAKCRAu2dd0/nAttdVOEACEqPMTb5cea/fsI6x29dxx0btnNZaB
# MhN72qmmGS1GMr03u6hGMrIPgkFa/HQL86SAUxWDt4qg3XJKpJ8p9KLqFm393Dgi
# UEZnvzhX2NP23Cf4M0EaHSAeQOfaYdsgOzivo+7fQUIkpXaRpmu+3VIjvhUESSOb
# 37p1kqdjXf73t7aUMBXA2hCZctm+vOOKdJd25MfrhZp6Yvxly90P2QW+lKzFBUIp
# d2uyZ/FaBXKiGWHMTmpbloIvL6sP8ag/e+deRfKQlBlC3lVpTyREvAKoNret5Rgt
# uYQ1Erbo7Bz8BKrwFrlObbGxn1WoaoCmiPJGzPtn8mfQ33QwS8B3+Np5OfgvinAR
# B6YBXNBIenjUFgJKY9jSXy4IlzfFc4mMKn6kgTv+y9srf9Np1EgmkYuOXxxytPzP
# fE+blTWXgj6EvhUYNtqDgaN0NdW+4YSbr2Lzy/ZNGX7eLJ5S9PZdSU7gb2T+2y2N
# sdAkPiXP1lmTzPkG9gzQ0EljO36gOgSpKWjxf72NvluVGoTBLtKqB8NmVO1YnyVC
# 0/QA/SxZGjsT8MMlhjheWg+lCKRjzTpjfw4C8CvukSsiOHX4pnX9yRreJ2s7z6W3
# 26SxK1nIvn3VODXhXAgB23zHZlgk/lWSJXUuBOsnAk5YMgy7KyDn6r92FNBhj+e2
# 3O0SEi9HC/wUKw==
# =js2G
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 29 Dec 2024 02:17:16 EST
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "huth@tuxfamily.org"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg:                 aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg:                 aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg:                 aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2024-12-29' of https://gitlab.com/huth/qemu: (35 commits)
  next-cube: add my copyright to the top of the file
  next-cube: rename old_scr2 and scr2_2 in next_scr2_rtc_update()
  next-cube: move next_rtc_cmd_is_write() and next_rtc_data_in_irq() functions
  next-cube: add rtc-power-out named gpio to trigger the NEXT_PWR_I interrupt
  next-cube: add rtc-cmd-reset named gpio to reset the rtc state machine
  next-cube: use named gpio output for next-rtc data
  next-cube: move rtc-data-in gpio from next-pc to next-rtc device
  next-cube: move reset of next-rtc fields from next-pc to next-rtc
  next-cube: QOMify NeXTRTC
  next-cube: don't use rtc phase value of -1
  next-cube: use named gpio to read RTC data bit in scr2
  next-cube: use named gpio to set RTC data bit in scr2
  next-cube: always use retval to return rtc read values
  next-cube: separate rtc read and write shift logic
  next-cube: use qemu_irq to drive int_status in next_scr2_rtc_update()
  next-cube: rename typedef struct NextRtc to NeXTRTC
  next-cube: convert next-pc device to use Resettable interface
  next-cube: rearrange NeXTState declarations to improve readability
  next-cube: remove unused next.scr memory region
  next-cube: add empty slots for unknown accesses to next.scr memory region
  ...

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
3 months agonext-cube: add my copyright to the top of the file
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:12 +0000 (13:00 +0000)]
next-cube: add my copyright to the top of the file

This series has involved rewriting and/or updating a considerable part of the
next-cube emulation so update the copyright in next-cube.c to reflect this.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241222130012.1013374-34-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: rename old_scr2 and scr2_2 in next_scr2_rtc_update()
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:11 +0000 (13:00 +0000)]
next-cube: rename old_scr2 and scr2_2 in next_scr2_rtc_update()

Rename them to old_scr2_rtc and scr2_rtc to reflect that they contain the previous
and current values of the SCR2 RTC bits.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-33-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move next_rtc_cmd_is_write() and next_rtc_data_in_irq() functions
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:10 +0000 (13:00 +0000)]
next-cube: move next_rtc_cmd_is_write() and next_rtc_data_in_irq() functions

Move these functions in next-cube.c so that they are with the rest of the
next-rtc functions.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-32-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: add rtc-power-out named gpio to trigger the NEXT_PWR_I interrupt
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:09 +0000 (13:00 +0000)]
next-cube: add rtc-power-out named gpio to trigger the NEXT_PWR_I interrupt

This allows us to decouple the next-pc and next-rtc devices from each
other in next_rtc_data_in_irq().

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-ID: <20241222130012.1013374-31-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: add rtc-cmd-reset named gpio to reset the rtc state machine
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:08 +0000 (13:00 +0000)]
next-cube: add rtc-cmd-reset named gpio to reset the rtc state machine

This allows us to decouple the next-pc and next-rtc devices from each
other in next_scr2_rtc_update().

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-ID: <20241222130012.1013374-30-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: use named gpio output for next-rtc data
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:07 +0000 (13:00 +0000)]
next-cube: use named gpio output for next-rtc data

Add a named gpio output for the next-rtc data and then update
next_rtc_data_in_irq() to drive the IRQ directly. This enables the next-rtc to
next-pc data to be wired up using the standard qdev gpio APIs.

At the same time rename the pc-rtc-data-in gpio to rtc-data-in which is possible
now that the previous rtc-data-in gpio has been moved to the next-rtc device.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-ID: <20241222130012.1013374-29-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move rtc-data-in gpio from next-pc to next-rtc device
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:06 +0000 (13:00 +0000)]
next-cube: move rtc-data-in gpio from next-pc to next-rtc device

Add a new rtc-data-out gpio to the next-pc device and wire it up to the next-rtc
rtc-data-in gpio using the standard qdev gpio APIs.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-28-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move reset of next-rtc fields from next-pc to next-rtc
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:05 +0000 (13:00 +0000)]
next-cube: move reset of next-rtc fields from next-pc to next-rtc

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-27-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: QOMify NeXTRTC
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:04 +0000 (13:00 +0000)]
next-cube: QOMify NeXTRTC

This is to allow the RTC functionality to be maintained within its own separate
device rather than as part of the next-pc device.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-ID: <20241222130012.1013374-26-mark.cave-ayland@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: don't use rtc phase value of -1
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:03 +0000 (13:00 +0000)]
next-cube: don't use rtc phase value of -1

The rtc phase value of -1 is directly equivalent to using a phase value of 0 so
simplify the logic to use an initial rtc phase of 0.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-25-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: use named gpio to read RTC data bit in scr2
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:02 +0000 (13:00 +0000)]
next-cube: use named gpio to read RTC data bit in scr2

This is in preparation for moving NeXTRTC to its own separate device.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-24-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: use named gpio to set RTC data bit in scr2
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:01 +0000 (13:00 +0000)]
next-cube: use named gpio to set RTC data bit in scr2

This is in preparation for moving NeXTRTC to its own separate device.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-23-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: always use retval to return rtc read values
Mark Cave-Ayland [Sun, 22 Dec 2024 13:00:00 +0000 (13:00 +0000)]
next-cube: always use retval to return rtc read values

Instead of shifting out rtc read values from individual rtc registers, change
the logic so that rtc read commands are executed when the last bit of the rtc
command is received and the result stored in retval. This simplifies the rtc
read logic such that the shift out logic can be consolidated for rtc phases
between 8 and 16.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-ID: <20241222130012.1013374-22-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: separate rtc read and write shift logic
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:59 +0000 (12:59 +0000)]
next-cube: separate rtc read and write shift logic

Introduce a new next_rtc_cmd_is_write() function to determine if an rtc command
is a read or write, and start by using it to avoid shifting the rtc input value
if a rtc read command is executed.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-21-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: use qemu_irq to drive int_status in next_scr2_rtc_update()
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:58 +0000 (12:59 +0000)]
next-cube: use qemu_irq to drive int_status in next_scr2_rtc_update()

Rather than directly clear bit 3 in int_status in next_scr2_rtc_update(), use
a qemu_irq to drive the equivalent NEXT_PWR_I signal.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-20-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: rename typedef struct NextRtc to NeXTRTC
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:57 +0000 (12:59 +0000)]
next-cube: rename typedef struct NextRtc to NeXTRTC

This brings the capitalisation in line with the other NeXTCube definitions.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-19-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: convert next-pc device to use Resettable interface
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:56 +0000 (12:59 +0000)]
next-cube: convert next-pc device to use Resettable interface

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Acked-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241222130012.1013374-18-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: rearrange NeXTState declarations to improve readability
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:55 +0000 (12:59 +0000)]
next-cube: rearrange NeXTState declarations to improve readability

Move the NeXTState, next_dma and TYPE_NEXT_MACHINE definition to the same area
at the top of next-cube.c.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241222130012.1013374-17-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: remove unused next.scr memory region
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:54 +0000 (12:59 +0000)]
next-cube: remove unused next.scr memory region

Now that the next.scr memory region is unused it can be removed and the next-pc
devices mapped directly within the machine init function. This is the last
remaining overlapping memory region within the NeXTCube machine.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-16-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: add empty slots for unknown accesses to next.scr memory region
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:53 +0000 (12:59 +0000)]
next-cube: add empty slots for unknown accesses to next.scr memory region

The next.scr memory is now effectively unused, however there are 3 separate region
accesses still logged that occur when booting a NeXTStep disk image. Use the
empty_slot device to capture and ignore memory accesses to these 3 memory regions.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-15-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move en ethernet MMIO to separate memory region on next-pc device
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:52 +0000 (12:59 +0000)]
next-cube: move en ethernet MMIO to separate memory region on next-pc device

Move the en ethernet MMIO accesses to a separate memory region on the next-pc
device instead of being part of the next.scr MMIO memory region.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-14-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move timer MMIO to separate memory region on next-pc device
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:51 +0000 (12:59 +0000)]
next-cube: move timer MMIO to separate memory region on next-pc device

Move the timer MMIO accesses to a separate memory region on the next-pc device
instead of being part of the next.scr MMIO memory region.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241222130012.1013374-13-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move ESCC to be QOM child of next-pc device
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:50 +0000 (12:59 +0000)]
next-cube: move ESCC to be QOM child of next-pc device

Since the ESCC is part of the next-pc device, move the ESCC to be a QOM child
of the next-pc device.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241222130012.1013374-12-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: map ESCC registers as a subregion of the next.scr memory region
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:49 +0000 (12:59 +0000)]
next-cube: map ESCC registers as a subregion of the next.scr memory region

Since the ESCC device exists within the memory range of the next.scr memory region, map
the ESCC device registers as a subregion of the next.scr memory region instead of
directly to the system address space.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241222130012.1013374-11-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move floppy disk MMIO to separate memory region in next-pc
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:48 +0000 (12:59 +0000)]
next-cube: move floppy disk MMIO to separate memory region in next-pc

The dummy floppy disk device is part of the next-pc device, and not related to
the NeXTCube SCRs.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-10-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move SCSI 4020/4021 logic from next-pc device to next-scsi device
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:47 +0000 (12:59 +0000)]
next-cube: move SCSI 4020/4021 logic from next-pc device to next-scsi device

The SCSI 4020/4021 logic refers to the offset of the SCSI CSRs within the NeXTCube
address space. Due to the previously overlapping memory regions, there were
duplicate MMIO accessors in the next.scr memory region for these registers but
this has now been resolved.

Move the remaining SCSI 4020/4021 logic from the next-pc device to the next-scsi
device, with the exception that the SCSI 4021 register now returns its previous
value like a normal register instead of a hardcoded 0x40 value. This also matches
how the registers are implemented in the Previous emulator.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-9-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: move SCSI CSRs from next-pc to the next-scsi device
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:46 +0000 (12:59 +0000)]
next-cube: move SCSI CSRs from next-pc to the next-scsi device

The SCSI CSRs are located within the SCSI subsystem of the NeXT PC (Peripheral
Contoller) which is now modelled as a separate QEMU device. Add a new memory
region subregion to contain the SCSI CSRs that simply store and retrieve the
register values.

Add a new VMStateDescription for the next-scsi device to enable the SCSI CSRs
to be migrated.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-8-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
3 months agonext-cube: introduce next-scsi device
Mark Cave-Ayland [Sun, 22 Dec 2024 12:59:45 +0000 (12:59 +0000)]
next-cube: introduce next-scsi device

This device is intended to hold the ESP SCSI controller and the NeXT SCSI CSRs.
Start by creating the device and moving the ESP SCSI controller to be an
embedded child device.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Message-ID: <20241222130012.1013374-7-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Thomas Huth <huth@tuxfamily.org>