* [PULL 1/9] hw/arm/virt: Check bypass iommu is not set for iommu-map DT property
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 2/9] tests/functional: Add a test for the realview-eb-mpcore machine Peter Maydell
` (8 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
default_bus_bypass_iommu tells us whether the bypass_iommu is set
for the default PCIe root bus. Make sure we check that before adding
the "iommu-map" DT property.
Cc: qemu-stable@nongnu.org
Fixes: 6d7a85483a06 ("hw/arm/virt: Add default_bus_bypass_iommu machine option")
Suggested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Donald Dutile <ddutile@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20250602114655.42920-1-shameerali.kolothum.thodi@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/arm/virt.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9a6cd085a37..99fde5836c9 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1487,9 +1487,12 @@ static void create_virtio_iommu_dt_bindings(VirtMachineState *vms)
qemu_fdt_setprop_cell(ms->fdt, node, "phandle", vms->iommu_phandle);
g_free(node);
- qemu_fdt_setprop_cells(ms->fdt, vms->pciehb_nodename, "iommu-map",
- 0x0, vms->iommu_phandle, 0x0, bdf,
- bdf + 1, vms->iommu_phandle, bdf + 1, 0xffff - bdf);
+ if (!vms->default_bus_bypass_iommu) {
+ qemu_fdt_setprop_cells(ms->fdt, vms->pciehb_nodename, "iommu-map",
+ 0x0, vms->iommu_phandle, 0x0, bdf,
+ bdf + 1, vms->iommu_phandle, bdf + 1,
+ 0xffff - bdf);
+ }
}
static void create_pcie(VirtMachineState *vms)
@@ -1612,8 +1615,10 @@ static void create_pcie(VirtMachineState *vms)
switch (vms->iommu) {
case VIRT_IOMMU_SMMUV3:
create_smmu(vms, vms->bus);
- qemu_fdt_setprop_cells(ms->fdt, nodename, "iommu-map",
- 0x0, vms->iommu_phandle, 0x0, 0x10000);
+ if (!vms->default_bus_bypass_iommu) {
+ qemu_fdt_setprop_cells(ms->fdt, nodename, "iommu-map",
+ 0x0, vms->iommu_phandle, 0x0, 0x10000);
+ }
break;
default:
g_assert_not_reached();
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 2/9] tests/functional: Add a test for the realview-eb-mpcore machine
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
2025-06-16 14:06 ` [PULL 1/9] hw/arm/virt: Check bypass iommu is not set for iommu-map DT property Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 3/9] qemu-options.hx: Fix reversed description of icount sleep behavior Peter Maydell
` (7 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: Thomas Huth <thuth@redhat.com>
Check that we can boot a Linux kernel here and that we can at
least send one ping network packet.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 20250603101526.21217-1-thuth@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
MAINTAINERS | 1 +
tests/functional/meson.build | 1 +
tests/functional/test_arm_realview.py | 47 +++++++++++++++++++++++++++
3 files changed, 49 insertions(+)
create mode 100755 tests/functional/test_arm_realview.py
diff --git a/MAINTAINERS b/MAINTAINERS
index 28b3dd2684b..84cfef835eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -955,6 +955,7 @@ F: hw/cpu/realview_mpcore.c
F: hw/intc/realview_gic.c
F: include/hw/intc/realview_gic.h
F: docs/system/arm/realview.rst
+F: tests/functional/test_arm_realview.py
SABRELITE / i.MX6
M: Peter Maydell <peter.maydell@linaro.org>
diff --git a/tests/functional/meson.build b/tests/functional/meson.build
index 7faa2b6e3c0..e7e051ef3c8 100644
--- a/tests/functional/meson.build
+++ b/tests/functional/meson.build
@@ -135,6 +135,7 @@ tests_arm_system_thorough = [
'arm_orangepi',
'arm_quanta_gsj',
'arm_raspi2',
+ 'arm_realview',
'arm_replay',
'arm_smdkc210',
'arm_stellaris',
diff --git a/tests/functional/test_arm_realview.py b/tests/functional/test_arm_realview.py
new file mode 100755
index 00000000000..82cc964333e
--- /dev/null
+++ b/tests/functional/test_arm_realview.py
@@ -0,0 +1,47 @@
+#!/usr/bin/env python3
+#
+# Functional test that boots a Linux kernel on a realview arm machine
+# and checks the console
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+from qemu_test import LinuxKernelTest, exec_command_and_wait_for_pattern
+from qemu_test import Asset
+
+
+class RealviewMachine(LinuxKernelTest):
+
+ ASSET_REALVIEW_MPCORE = Asset(
+ ('https://archive.openwrt.org/chaos_calmer/15.05.1/realview/generic/'
+ 'openwrt-15.05.1-realview-vmlinux-initramfs.elf'),
+ 'd3a01037f33e7512d46d50975588d5c3a0e0cbf25f37afab44775c2a2be523e6')
+
+ def test_realview_ep_mpcore(self):
+ self.require_netdev('user')
+ self.set_machine('realview-eb-mpcore')
+ kernel_path = self.ASSET_REALVIEW_MPCORE.fetch()
+ self.vm.set_console()
+ kernel_param = 'console=ttyAMA0 mem=128M quiet'
+ self.vm.add_args('-kernel', kernel_path,
+ '-append', kernel_param)
+ self.vm.launch()
+ self.wait_for_console_pattern('Please press Enter to activate')
+ prompt = ':/#'
+ exec_command_and_wait_for_pattern(self, '', prompt)
+ exec_command_and_wait_for_pattern(self, 'dmesg', kernel_param)
+ self.wait_for_console_pattern(prompt)
+ exec_command_and_wait_for_pattern(self,
+ ('while ! dmesg | grep "br-lan: port 1(eth0) entered" ;'
+ ' do sleep 1 ; done'),
+ 'entered forwarding state')
+ self.wait_for_console_pattern(prompt)
+ exec_command_and_wait_for_pattern(self,
+ 'while ! ifconfig | grep "10.0.2.15" ; do sleep 1 ; done',
+ 'addr:10.0.2.15')
+ self.wait_for_console_pattern(prompt)
+ exec_command_and_wait_for_pattern(self, 'ping -c 1 10.0.2.2',
+ '1 packets received, 0% packet loss')
+
+
+if __name__ == '__main__':
+ LinuxKernelTest.main()
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 3/9] qemu-options.hx: Fix reversed description of icount sleep behavior
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
2025-06-16 14:06 ` [PULL 1/9] hw/arm/virt: Check bypass iommu is not set for iommu-map DT property Peter Maydell
2025-06-16 14:06 ` [PULL 2/9] tests/functional: Add a test for the realview-eb-mpcore machine Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 4/9] target/arm: Define raw write for PMU CLR registers Peter Maydell
` (6 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: Ethan Chen <ethan84@andestech.com>
The documentation for the -icount option incorrectly describes the behavior
of the sleep suboption. Based on the actual implementation and system
behavior, the effects of sleep=on and sleep=off were inadvertently reversed.
This commit updates the description to reflect their intended functionality.
Cc: qemu-stable@nongnu.org
Fixes: fa647905e6ba ("qemu-options.hx: Fix minor issues in icount documentation")
Signed-off-by: Ethan Chen <ethan84@andestech.com>
Message-id: 20250606095728.3672832-1-ethan84@andestech.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
qemu-options.hx | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 7eb8e02b4b9..1f862b19a67 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4936,13 +4936,13 @@ SRST
with actual performance.
When the virtual cpu is sleeping, the virtual time will advance at
- default speed unless ``sleep=on`` is specified. With
- ``sleep=on``, the virtual time will jump to the next timer
+ default speed unless ``sleep=off`` is specified. With
+ ``sleep=off``, the virtual time will jump to the next timer
deadline instantly whenever the virtual cpu goes to sleep mode and
will not advance if no timer is enabled. This behavior gives
deterministic execution times from the guest point of view.
- The default if icount is enabled is ``sleep=off``.
- ``sleep=on`` cannot be used together with either ``shift=auto``
+ The default if icount is enabled is ``sleep=on``.
+ ``sleep=off`` cannot be used together with either ``shift=auto``
or ``align=on``.
``align=on`` will activate the delay algorithm which will try to
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 4/9] target/arm: Define raw write for PMU CLR registers
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
` (2 preceding siblings ...)
2025-06-16 14:06 ` [PULL 3/9] qemu-options.hx: Fix reversed description of icount sleep behavior Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 5/9] docs/interop: convert qed_spec.txt to reStructuredText format Peter Maydell
` (5 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Raw writes to PMCNTENCLR and PMCNTENCLR_EL0 incorrectly used their
default write function, which clears written bits instead of writes the
raw value.
PMINTENCLR and PMINTENCLR_EL1 are similar registers, but they instead
had ARM_CP_NO_RAW. Commit 7a0e58fa6487 ("target-arm: Split NO_MIGRATE
into ALIAS and NO_RAW") sugguests ARM_CP_ALIAS should be used instead of
ARM_CP_NO_RAW in such a case:
> We currently mark ARM coprocessor/system register definitions with
> the flag ARM_CP_NO_MIGRATE for two different reasons:
> 1) register is an alias on to state that's also visible via
> some other register, and that other register is the one
> responsible for migrating the state
> 2) register is not actually state at all (for instance the TLB
> or cache maintenance operation "registers") and it makes no
> sense to attempt to migrate it or otherwise access the raw state
>
> This works fine for identifying which registers should be ignored
> when performing migration, but we also use the same functions for
> synchronizing system register state between QEMU and the kernel
> when using KVM. In this case we don't want to try to sync state
> into registers in category 2, but we do want to sync into registers
> in category 1, because the kernel might have picked a different
> one of the aliases as its choice for which one to expose for
> migration.
These registers fall in category 1 (ARM_CP_ALIAS), not category 2
(ARM_CP_NO_RAW).
ARM_CP_NO_RAW also has another undesired side effect that hides
registers from GDB.
Properly set raw write functions and drop the ARM_CP_NO_RAW flag from
PMINTENCLR and PMINTENCLR_EL1; this fixes GDB/KVM state synchronization
of PMCNTENCLR and PMCNTENCLR_EL0, and exposes all these four registers
to GDB.
It is not necessary to add ARM_CP_ALIAS to these registers because the
flag is already set.
Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-id: 20250531-clr-v3-1-377f9bf1746d@rsg.ci.i.u-tokyo.ac.jp
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
target/arm/helper.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 76312102879..889d3088079 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1904,7 +1904,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
.fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmcnten),
.accessfn = pmreg_access,
.fgt = FGT_PMCNTEN,
- .writefn = pmcntenclr_write,
+ .writefn = pmcntenclr_write, .raw_writefn = raw_write,
.type = ARM_CP_ALIAS | ARM_CP_IO },
{ .name = "PMCNTENCLR_EL0", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 3, .crn = 9, .crm = 12, .opc2 = 2,
@@ -1912,7 +1912,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
.fgt = FGT_PMCNTEN,
.type = ARM_CP_ALIAS | ARM_CP_IO,
.fieldoffset = offsetof(CPUARMState, cp15.c9_pmcnten),
- .writefn = pmcntenclr_write },
+ .writefn = pmcntenclr_write, .raw_writefn = raw_write },
{ .name = "PMOVSR", .cp = 15, .crn = 9, .crm = 12, .opc1 = 0, .opc2 = 3,
.access = PL0_RW, .type = ARM_CP_IO,
.fieldoffset = offsetoflow32(CPUARMState, cp15.c9_pmovsr),
@@ -2029,16 +2029,16 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
{ .name = "PMINTENCLR", .cp = 15, .crn = 9, .crm = 14, .opc1 = 0, .opc2 = 2,
.access = PL1_RW, .accessfn = access_tpm,
.fgt = FGT_PMINTEN,
- .type = ARM_CP_ALIAS | ARM_CP_IO | ARM_CP_NO_RAW,
+ .type = ARM_CP_ALIAS | ARM_CP_IO,
.fieldoffset = offsetof(CPUARMState, cp15.c9_pminten),
- .writefn = pmintenclr_write, },
+ .writefn = pmintenclr_write, .raw_writefn = raw_write },
{ .name = "PMINTENCLR_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 9, .crm = 14, .opc2 = 2,
.access = PL1_RW, .accessfn = access_tpm,
.fgt = FGT_PMINTEN,
- .type = ARM_CP_ALIAS | ARM_CP_IO | ARM_CP_NO_RAW,
+ .type = ARM_CP_ALIAS | ARM_CP_IO,
.fieldoffset = offsetof(CPUARMState, cp15.c9_pminten),
- .writefn = pmintenclr_write },
+ .writefn = pmintenclr_write, .raw_writefn = raw_write },
{ .name = "CCSIDR", .state = ARM_CP_STATE_BOTH,
.opc0 = 3, .crn = 0, .crm = 0, .opc1 = 1, .opc2 = 0,
.access = PL1_R,
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 5/9] docs/interop: convert qed_spec.txt to reStructuredText format
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
` (3 preceding siblings ...)
2025-06-16 14:06 ` [PULL 4/9] target/arm: Define raw write for PMU CLR registers Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 6/9] hw/arm: make cpu targeted by arm_load_kernel the primary CPU Peter Maydell
` (4 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: Souleymane Conte <conte.souleymane@gmail.com>
Convert the qed_spec.txt file to reStructuredText and
include it in the manual.
buglink: https://gitlab.com/qemu-project/qemu/-/issues/527
Signed-off-by: Souleymane Conte <conte.souleymane@gmail.com>
Message-id: 20250609135124.45078-1-conte.souleymane@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: adjusted position of doc in the table of contents;
bulked up commit message; added file to MAINTAINERS section
for QED; made 'Consistency checking' a higher level section;
fixed one preexisting grammar nit (s/by from/from/)]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
MAINTAINERS | 1 +
docs/interop/index.rst | 1 +
docs/interop/qed_spec.rst | 219 ++++++++++++++++++++++++++++++++++++++
docs/interop/qed_spec.txt | 138 ------------------------
4 files changed, 221 insertions(+), 138 deletions(-)
create mode 100644 docs/interop/qed_spec.rst
delete mode 100644 docs/interop/qed_spec.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 84cfef835eb..94c40761278 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4117,6 +4117,7 @@ M: Stefan Hajnoczi <stefanha@redhat.com>
L: qemu-block@nongnu.org
S: Supported
F: block/qed.c
+F: docs/interop/qed_spec.rst
raw
M: Kevin Wolf <kwolf@redhat.com>
diff --git a/docs/interop/index.rst b/docs/interop/index.rst
index 4b951ae4162..972f3e49ce9 100644
--- a/docs/interop/index.rst
+++ b/docs/interop/index.rst
@@ -18,6 +18,7 @@ are useful for making QEMU interoperate with other software.
parallels
prl-xml
qcow2
+ qed_spec
pr-helper
qmp-spec
qemu-ga
diff --git a/docs/interop/qed_spec.rst b/docs/interop/qed_spec.rst
new file mode 100644
index 00000000000..cd6c7d90051
--- /dev/null
+++ b/docs/interop/qed_spec.rst
@@ -0,0 +1,219 @@
+===================================
+QED Image File Format Specification
+===================================
+
+The file format looks like this::
+
+ +----------+----------+----------+-----+
+ | cluster0 | cluster1 | cluster2 | ... |
+ +----------+----------+----------+-----+
+
+The first cluster begins with the ``header``. The header contains information
+about where regular clusters start; this allows the header to be extensible and
+store extra information about the image file. A regular cluster may be
+a ``data cluster``, an ``L2``, or an ``L1 table``. L1 and L2 tables are composed
+of one or more contiguous clusters.
+
+Normally the file size will be a multiple of the cluster size. If the file size
+is not a multiple, extra information after the last cluster may not be preserved
+if data is written. Legitimate extra information should use space between the header
+and the first regular cluster.
+
+All fields are little-endian.
+
+Header
+------
+
+::
+
+ Header {
+ uint32_t magic; /* QED\0 */
+
+ uint32_t cluster_size; /* in bytes */
+ uint32_t table_size; /* for L1 and L2 tables, in clusters */
+ uint32_t header_size; /* in clusters */
+
+ uint64_t features; /* format feature bits */
+ uint64_t compat_features; /* compat feature bits */
+ uint64_t autoclear_features; /* self-resetting feature bits */
+
+ uint64_t l1_table_offset; /* in bytes */
+ uint64_t image_size; /* total logical image size, in bytes */
+
+ /* if (features & QED_F_BACKING_FILE) */
+ uint32_t backing_filename_offset; /* in bytes from start of header */
+ uint32_t backing_filename_size; /* in bytes */
+ }
+
+Field descriptions:
+~~~~~~~~~~~~~~~~~~~
+
+- ``cluster_size`` must be a power of 2 in range [2^12, 2^26].
+- ``table_size`` must be a power of 2 in range [1, 16].
+- ``header_size`` is the number of clusters used by the header and any additional
+ information stored before regular clusters.
+- ``features``, ``compat_features``, and ``autoclear_features`` are file format
+ extension bitmaps. They work as follows:
+
+ - An image with unknown ``features`` bits enabled must not be opened. File format
+ changes that are not backwards-compatible must use ``features`` bits.
+ - An image with unknown ``compat_features`` bits enabled can be opened safely.
+ The unknown features are simply ignored and represent backwards-compatible
+ changes to the file format.
+ - An image with unknown ``autoclear_features`` bits enable can be opened safely
+ after clearing the unknown bits. This allows for backwards-compatible changes
+ to the file format which degrade gracefully and can be re-enabled again by a
+ new program later.
+- ``l1_table_offset`` is the offset of the first byte of the L1 table in the image
+ file and must be a multiple of ``cluster_size``.
+- ``image_size`` is the block device size seen by the guest and must be a multiple
+ of 512 bytes.
+- ``backing_filename_offset`` and ``backing_filename_size`` describe a string in
+ (byte offset, byte size) form. It is not NUL-terminated and has no alignment constraints.
+ The string must be stored within the first ``header_size`` clusters. The backing filename
+ may be an absolute path or relative to the image file.
+
+Feature bits:
+~~~~~~~~~~~~~
+
+- ``QED_F_BACKING_FILE = 0x01``. The image uses a backing file.
+- ``QED_F_NEED_CHECK = 0x02``. The image needs a consistency check before use.
+- ``QED_F_BACKING_FORMAT_NO_PROBE = 0x04``. The backing file is a raw disk image
+ and no file format autodetection should be attempted. This should be used to
+ ensure that raw backing files are never detected as an image format if they happen
+ to contain magic constants.
+
+There are currently no defined ``compat_features`` or ``autoclear_features`` bits.
+
+Fields predicated on a feature bit are only used when that feature is set.
+The fields always take up header space, regardless of whether or not the feature
+bit is set.
+
+Tables
+------
+
+Tables provide the translation from logical offsets in the block device to cluster
+offsets in the file.
+
+::
+
+ #define TABLE_NOFFSETS (table_size * cluster_size / sizeof(uint64_t))
+
+ Table {
+ uint64_t offsets[TABLE_NOFFSETS];
+ }
+
+The tables are organized as follows::
+
+ +----------+
+ | L1 table |
+ +----------+
+ ,------' | '------.
+ +----------+ | +----------+
+ | L2 table | ... | L2 table |
+ +----------+ +----------+
+ ,------' | '------.
+ +----------+ | +----------+
+ | Data | ... | Data |
+ +----------+ +----------+
+
+A table is made up of one or more contiguous clusters. The ``table_size`` header
+field determines table size for an image file. For example, ``cluster_size=64 KB``
+and ``table_size=4`` results in 256 KB tables.
+
+The logical image size must be less than or equal to the maximum possible size of
+clusters rooted by the L1 table:
+
+.. code::
+
+ header.image_size <= TABLE_NOFFSETS * TABLE_NOFFSETS * header.cluster_size
+
+L1, L2, and data cluster offsets must be aligned to ``header.cluster_size``.
+The following offsets have special meanings:
+
+L2 table offsets
+~~~~~~~~~~~~~~~~
+
+- 0 - unallocated. The L2 table is not yet allocated.
+
+Data cluster offsets
+~~~~~~~~~~~~~~~~~~~~
+
+- 0 - unallocated. The data cluster is not yet allocated.
+- 1 - zero. The data cluster contents are all zeroes and no cluster is allocated.
+
+Future format extensions may wish to store per-offset information. The least
+significant 12 bits of an offset are reserved for this purpose and must be set
+to zero. Image files with ``cluster_size`` > 2^12 will have more unused bits
+which should also be zeroed.
+
+Unallocated L2 tables and data clusters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Reads to an unallocated area of the image file access the backing file. If there
+is no backing file, then zeroes are produced. The backing file may be smaller
+than the image file and reads of unallocated areas beyond the end of the backing
+file produce zeroes.
+
+Writes to an unallocated area cause a new data clusters to be allocated, and a new
+L2 table if that is also unallocated. The new data cluster is populated with data
+from the backing file (or zeroes if no backing file) and the data being written.
+
+Zero data clusters
+~~~~~~~~~~~~~~~~~~
+
+Zero data clusters are a space-efficient way of storing zeroed regions of the image.
+
+Reads to a zero data cluster produce zeroes.
+
+.. note::
+ The difference between an unallocated and a zero data cluster is that zero data
+ clusters stop the reading of contents from the backing file.
+
+Writes to a zero data cluster cause a new data cluster to be allocated. The new
+data cluster is populated with zeroes and the data being written.
+
+Logical offset translation
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Logical offsets are translated into cluster offsets as follows::
+
+ table_bits table_bits cluster_bits
+ <--------> <--------> <--------------->
+ +----------+----------+-----------------+
+ | L1 index | L2 index | byte offset |
+ +----------+----------+-----------------+
+
+ Structure of a logical offset
+
+ offset_mask = ~(cluster_size - 1) # mask for the image file byte offset
+
+ def logical_to_cluster_offset(l1_index, l2_index, byte_offset):
+ l2_offset = l1_table[l1_index]
+ l2_table = load_table(l2_offset)
+ cluster_offset = l2_table[l2_index] & offset_mask
+ return cluster_offset + byte_offset
+
+Consistency checking
+--------------------
+
+This section is informational and included to provide background on the use
+of the ``QED_F_NEED_CHECK features`` bit.
+
+The ``QED_F_NEED_CHECK`` bit is used to mark an image as dirty before starting
+an operation that could leave the image in an inconsistent state if interrupted
+by a crash or power failure. A dirty image must be checked on open because its
+metadata may not be consistent.
+
+Consistency check includes the following invariants:
+
+- Each cluster is referenced once and only once. It is an inconsistency to have
+ a cluster referenced more than once by L1 or L2 tables. A cluster has been leaked
+ if it has no references.
+- Offsets must be within the image file size and must be ``cluster_size`` aligned.
+- Table offsets must at least ``table_size`` * ``cluster_size`` bytes from the end
+ of the image file so that there is space for the entire table.
+
+The consistency check process starts from ``l1_table_offset`` and scans all L2 tables.
+After the check completes with no other errors besides leaks, the ``QED_F_NEED_CHECK``
+bit can be cleared and the image can be accessed.
diff --git a/docs/interop/qed_spec.txt b/docs/interop/qed_spec.txt
deleted file mode 100644
index 7982e058b2c..00000000000
--- a/docs/interop/qed_spec.txt
+++ /dev/null
@@ -1,138 +0,0 @@
-=Specification=
-
-The file format looks like this:
-
- +----------+----------+----------+-----+
- | cluster0 | cluster1 | cluster2 | ... |
- +----------+----------+----------+-----+
-
-The first cluster begins with the '''header'''. The header contains information about where regular clusters start; this allows the header to be extensible and store extra information about the image file. A regular cluster may be a '''data cluster''', an '''L2''', or an '''L1 table'''. L1 and L2 tables are composed of one or more contiguous clusters.
-
-Normally the file size will be a multiple of the cluster size. If the file size is not a multiple, extra information after the last cluster may not be preserved if data is written. Legitimate extra information should use space between the header and the first regular cluster.
-
-All fields are little-endian.
-
-==Header==
- Header {
- uint32_t magic; /* QED\0 */
-
- uint32_t cluster_size; /* in bytes */
- uint32_t table_size; /* for L1 and L2 tables, in clusters */
- uint32_t header_size; /* in clusters */
-
- uint64_t features; /* format feature bits */
- uint64_t compat_features; /* compat feature bits */
- uint64_t autoclear_features; /* self-resetting feature bits */
-
- uint64_t l1_table_offset; /* in bytes */
- uint64_t image_size; /* total logical image size, in bytes */
-
- /* if (features & QED_F_BACKING_FILE) */
- uint32_t backing_filename_offset; /* in bytes from start of header */
- uint32_t backing_filename_size; /* in bytes */
- }
-
-Field descriptions:
-* ''cluster_size'' must be a power of 2 in range [2^12, 2^26].
-* ''table_size'' must be a power of 2 in range [1, 16].
-* ''header_size'' is the number of clusters used by the header and any additional information stored before regular clusters.
-* ''features'', ''compat_features'', and ''autoclear_features'' are file format extension bitmaps. They work as follows:
-** An image with unknown ''features'' bits enabled must not be opened. File format changes that are not backwards-compatible must use ''features'' bits.
-** An image with unknown ''compat_features'' bits enabled can be opened safely. The unknown features are simply ignored and represent backwards-compatible changes to the file format.
-** An image with unknown ''autoclear_features'' bits enable can be opened safely after clearing the unknown bits. This allows for backwards-compatible changes to the file format which degrade gracefully and can be re-enabled again by a new program later.
-* ''l1_table_offset'' is the offset of the first byte of the L1 table in the image file and must be a multiple of ''cluster_size''.
-* ''image_size'' is the block device size seen by the guest and must be a multiple of 512 bytes.
-* ''backing_filename_offset'' and ''backing_filename_size'' describe a string in (byte offset, byte size) form. It is not NUL-terminated and has no alignment constraints. The string must be stored within the first ''header_size'' clusters. The backing filename may be an absolute path or relative to the image file.
-
-Feature bits:
-* QED_F_BACKING_FILE = 0x01. The image uses a backing file.
-* QED_F_NEED_CHECK = 0x02. The image needs a consistency check before use.
-* QED_F_BACKING_FORMAT_NO_PROBE = 0x04. The backing file is a raw disk image and no file format autodetection should be attempted. This should be used to ensure that raw backing files are never detected as an image format if they happen to contain magic constants.
-
-There are currently no defined ''compat_features'' or ''autoclear_features'' bits.
-
-Fields predicated on a feature bit are only used when that feature is set. The fields always take up header space, regardless of whether or not the feature bit is set.
-
-==Tables==
-
-Tables provide the translation from logical offsets in the block device to cluster offsets in the file.
-
- #define TABLE_NOFFSETS (table_size * cluster_size / sizeof(uint64_t))
-
- Table {
- uint64_t offsets[TABLE_NOFFSETS];
- }
-
-The tables are organized as follows:
-
- +----------+
- | L1 table |
- +----------+
- ,------' | '------.
- +----------+ | +----------+
- | L2 table | ... | L2 table |
- +----------+ +----------+
- ,------' | '------.
- +----------+ | +----------+
- | Data | ... | Data |
- +----------+ +----------+
-
-A table is made up of one or more contiguous clusters. The table_size header field determines table size for an image file. For example, cluster_size=64 KB and table_size=4 results in 256 KB tables.
-
-The logical image size must be less than or equal to the maximum possible size of clusters rooted by the L1 table:
- header.image_size <= TABLE_NOFFSETS * TABLE_NOFFSETS * header.cluster_size
-
-L1, L2, and data cluster offsets must be aligned to header.cluster_size. The following offsets have special meanings:
-
-===L2 table offsets===
-* 0 - unallocated. The L2 table is not yet allocated.
-
-===Data cluster offsets===
-* 0 - unallocated. The data cluster is not yet allocated.
-* 1 - zero. The data cluster contents are all zeroes and no cluster is allocated.
-
-Future format extensions may wish to store per-offset information. The least significant 12 bits of an offset are reserved for this purpose and must be set to zero. Image files with cluster_size > 2^12 will have more unused bits which should also be zeroed.
-
-===Unallocated L2 tables and data clusters===
-Reads to an unallocated area of the image file access the backing file. If there is no backing file, then zeroes are produced. The backing file may be smaller than the image file and reads of unallocated areas beyond the end of the backing file produce zeroes.
-
-Writes to an unallocated area cause a new data clusters to be allocated, and a new L2 table if that is also unallocated. The new data cluster is populated with data from the backing file (or zeroes if no backing file) and the data being written.
-
-===Zero data clusters===
-Zero data clusters are a space-efficient way of storing zeroed regions of the image.
-
-Reads to a zero data cluster produce zeroes. Note that the difference between an unallocated and a zero data cluster is that zero data clusters stop the reading of contents from the backing file.
-
-Writes to a zero data cluster cause a new data cluster to be allocated. The new data cluster is populated with zeroes and the data being written.
-
-===Logical offset translation===
-Logical offsets are translated into cluster offsets as follows:
-
- table_bits table_bits cluster_bits
- <--------> <--------> <--------------->
- +----------+----------+-----------------+
- | L1 index | L2 index | byte offset |
- +----------+----------+-----------------+
-
- Structure of a logical offset
-
- offset_mask = ~(cluster_size - 1) # mask for the image file byte offset
-
- def logical_to_cluster_offset(l1_index, l2_index, byte_offset):
- l2_offset = l1_table[l1_index]
- l2_table = load_table(l2_offset)
- cluster_offset = l2_table[l2_index] & offset_mask
- return cluster_offset + byte_offset
-
-==Consistency checking==
-
-This section is informational and included to provide background on the use of the QED_F_NEED_CHECK ''features'' bit.
-
-The QED_F_NEED_CHECK bit is used to mark an image as dirty before starting an operation that could leave the image in an inconsistent state if interrupted by a crash or power failure. A dirty image must be checked on open because its metadata may not be consistent.
-
-Consistency check includes the following invariants:
-# Each cluster is referenced once and only once. It is an inconsistency to have a cluster referenced more than once by L1 or L2 tables. A cluster has been leaked if it has no references.
-# Offsets must be within the image file size and must be ''cluster_size'' aligned.
-# Table offsets must at least ''table_size'' * ''cluster_size'' bytes from the end of the image file so that there is space for the entire table.
-
-The consistency check process starts by from ''l1_table_offset'' and scans all L2 tables. After the check completes with no other errors besides leaks, the QED_F_NEED_CHECK bit can be cleared and the image can be accessed.
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 6/9] hw/arm: make cpu targeted by arm_load_kernel the primary CPU.
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
` (4 preceding siblings ...)
2025-06-16 14:06 ` [PULL 5/9] docs/interop: convert qed_spec.txt to reStructuredText format Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 7/9] hw/intc/arm_gic: introduce a first-cpu-index property Peter Maydell
` (3 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: Clément Chigot <chigot@adacore.com>
Currently, arm booting processus assumes that the first_cpu is the CPU
that will boot: `arm_load_kernel` is powering off all but the `first_cpu`;
`do_cpu_reset` is setting the loader address only for this `first_cpu`.
For most of the boards, this isn't an issue as the kernel is loaded and
booted on the first CPU anyway. However, for zynqmp, the option
"boot-cpu" allows to choose any CPUs.
Create a new arm_boot_info entry `primary_cpu` recording which CPU will
be boot first. This one is set when `arm_boot_kernel` is called.
Signed-off-by: Clément Chigot <chigot@adacore.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20250526085523.809003-2-chigot@adacore.com
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
include/hw/arm/boot.h | 3 +++
hw/arm/boot.c | 15 +++++++--------
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/hw/arm/boot.h b/include/hw/arm/boot.h
index b12bf61ca81..a2e22bda8a5 100644
--- a/include/hw/arm/boot.h
+++ b/include/hw/arm/boot.h
@@ -132,6 +132,9 @@ struct arm_boot_info {
bool secure_board_setup;
arm_endianness endianness;
+
+ /* CPU having load the kernel and that should be the first to boot. */
+ ARMCPU *primary_cpu;
};
/**
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 79afb51b8a5..3c93d879857 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -744,7 +744,7 @@ static void do_cpu_reset(void *opaque)
} else {
if (arm_feature(env, ARM_FEATURE_EL3) &&
(info->secure_boot ||
- (info->secure_board_setup && cs == first_cpu))) {
+ (info->secure_board_setup && cpu == info->primary_cpu))) {
/* Start this CPU in Secure SVC */
target_el = 3;
}
@@ -752,7 +752,7 @@ static void do_cpu_reset(void *opaque)
arm_emulate_firmware_reset(cs, target_el);
- if (cs == first_cpu) {
+ if (cpu == info->primary_cpu) {
AddressSpace *as = arm_boot_address_space(cpu, info);
cpu_set_pc(cs, info->loader_start);
@@ -1239,6 +1239,9 @@ void arm_load_kernel(ARMCPU *cpu, MachineState *ms, struct arm_boot_info *info)
info->dtb_filename = ms->dtb;
info->dtb_limit = 0;
+ /* We assume the CPU passed as argument is the primary CPU. */
+ info->primary_cpu = cpu;
+
/* Load the kernel. */
if (!info->kernel_filename || info->firmware_loaded) {
arm_setup_firmware_boot(cpu, info);
@@ -1288,12 +1291,8 @@ void arm_load_kernel(ARMCPU *cpu, MachineState *ms, struct arm_boot_info *info)
object_property_set_int(cpuobj, "psci-conduit", info->psci_conduit,
&error_abort);
- /*
- * Secondary CPUs start in PSCI powered-down state. Like the
- * code in do_cpu_reset(), we assume first_cpu is the primary
- * CPU.
- */
- if (cs != first_cpu) {
+ /* Secondary CPUs start in PSCI powered-down state. */
+ if (ARM_CPU(cs) != info->primary_cpu) {
object_property_set_bool(cpuobj, "start-powered-off", true,
&error_abort);
}
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 7/9] hw/intc/arm_gic: introduce a first-cpu-index property
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
` (5 preceding siblings ...)
2025-06-16 14:06 ` [PULL 6/9] hw/arm: make cpu targeted by arm_load_kernel the primary CPU Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 8/9] hw/arm/mps2: Configure the AN500 CPU with 16 MPU regions Peter Maydell
` (2 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: Frederic Konrad <konrad.frederic@yahoo.fr>
This introduces a first-cpu-index property to the arm-gic, as some SOCs
could have two separate GIC (ie: the zynqmp).
Signed-off-by: Clément Chigot <chigot@adacore.com>
Message-id: 20250526085523.809003-3-chigot@adacore.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: slightly expanded comment documenting GIC property]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
include/hw/intc/arm_gic.h | 3 +++
include/hw/intc/arm_gic_common.h | 2 ++
hw/intc/arm_gic.c | 2 +-
hw/intc/arm_gic_common.c | 1 +
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/hw/intc/arm_gic.h b/include/hw/intc/arm_gic.h
index 48f6a51a70a..be923f7ed88 100644
--- a/include/hw/intc/arm_gic.h
+++ b/include/hw/intc/arm_gic.h
@@ -27,6 +27,9 @@
* implement the security extensions
* + QOM property "has-virtualization-extensions": set true if the GIC should
* implement the virtualization extensions
+ * + QOM property "first-cpu-index": index of the first cpu attached to the
+ * GIC (default 0). The CPUs connected to the GIC are assumed to be
+ * first-cpu-index, first-cpu-index + 1, ... first-cpu-index + num-cpu - 1.
* + unnamed GPIO inputs: (where P is number of SPIs, i.e. num-irq - 32)
* [0..P-1] SPIs
* [P..P+31] PPIs for CPU 0
diff --git a/include/hw/intc/arm_gic_common.h b/include/hw/intc/arm_gic_common.h
index 97fea4102d3..93a3cc2bf81 100644
--- a/include/hw/intc/arm_gic_common.h
+++ b/include/hw/intc/arm_gic_common.h
@@ -129,6 +129,8 @@ struct GICState {
uint32_t num_lrs;
uint32_t num_cpu;
+ /* cpu_index of the first CPU, attached to this GIC. */
+ uint32_t first_cpu_index;
MemoryRegion iomem; /* Distributor */
/* This is just so we can have an opaque pointer which identifies
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index d18bef40fcc..899f1333633 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -59,7 +59,7 @@ static const uint8_t gic_id_gicv2[] = {
static inline int gic_get_current_cpu(GICState *s)
{
if (!qtest_enabled() && s->num_cpu > 1) {
- return current_cpu->cpu_index;
+ return current_cpu->cpu_index - s->first_cpu_index;
}
return 0;
}
diff --git a/hw/intc/arm_gic_common.c b/hw/intc/arm_gic_common.c
index 0f0c48d89ab..ed5be056452 100644
--- a/hw/intc/arm_gic_common.c
+++ b/hw/intc/arm_gic_common.c
@@ -350,6 +350,7 @@ static void arm_gic_common_linux_init(ARMLinuxBootIf *obj,
static const Property arm_gic_common_properties[] = {
DEFINE_PROP_UINT32("num-cpu", GICState, num_cpu, 1),
+ DEFINE_PROP_UINT32("first-cpu-index", GICState, first_cpu_index, 0),
DEFINE_PROP_UINT32("num-irq", GICState, num_irq, 32),
/* Revision can be 1 or 2 for GIC architecture specification
* versions 1 or 2, or 0 to indicate the legacy 11MPCore GIC.
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 8/9] hw/arm/mps2: Configure the AN500 CPU with 16 MPU regions
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
` (6 preceding siblings ...)
2025-06-16 14:06 ` [PULL 7/9] hw/intc/arm_gic: introduce a first-cpu-index property Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-16 14:06 ` [PULL 9/9] linux-user/arm: Fix return value of SYS_cacheflush Peter Maydell
2025-06-17 13:10 ` [PULL 0/9] target-arm queue Stefan Hajnoczi
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
The AN500 application note documents that it configures the Cortex-M7
CPU to have 16 MPU regions. We weren't doing this in our emulation,
so the CPU had only the default 8 MPU regions. Set the mpu-ns-regions
property to 16 for this board.
This bug doesn't affect any of the other board types we model in
this source file, because they all use either the Cortex-M3 or
Cortex-M4. Those CPUs do not have an RTL configurable number of
MPU regions, and always provide 8 regions if the MPU is built in.
Cc: qemu-stable@nongnu.org
Reported-by: Corentin GENDRE <cocotroupe20@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20250605141801.1083266-1-peter.maydell@linaro.org
---
hw/arm/mps2.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/hw/arm/mps2.c b/hw/arm/mps2.c
index 58efb41e6db..bd378e360b0 100644
--- a/hw/arm/mps2.c
+++ b/hw/arm/mps2.c
@@ -224,7 +224,11 @@ static void mps2_common_init(MachineState *machine)
switch (mmc->fpga_type) {
case FPGA_AN385:
case FPGA_AN386:
+ qdev_prop_set_uint32(armv7m, "num-irq", 32);
+ break;
case FPGA_AN500:
+ /* The AN500 configures its Cortex-M7 with 16 MPU regions */
+ qdev_prop_set_uint32(armv7m, "mpu-ns-regions", 16);
qdev_prop_set_uint32(armv7m, "num-irq", 32);
break;
case FPGA_AN511:
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PULL 9/9] linux-user/arm: Fix return value of SYS_cacheflush
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
` (7 preceding siblings ...)
2025-06-16 14:06 ` [PULL 8/9] hw/arm/mps2: Configure the AN500 CPU with 16 MPU regions Peter Maydell
@ 2025-06-16 14:06 ` Peter Maydell
2025-06-17 13:10 ` [PULL 0/9] target-arm queue Stefan Hajnoczi
9 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2025-06-16 14:06 UTC (permalink / raw)
To: qemu-devel
From: J. Neuschäfer <j.neuschaefer@gmx.net>
Although the emulated cacheflush syscall does nothing, it still needs to
return zero to indicate success.
Cc: qemu-stable@nongnu.org
Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net>
Message-id: 20250613-cache-v1-1-ee9f4a9ba81b@gmx.net
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
linux-user/arm/cpu_loop.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/linux-user/arm/cpu_loop.c b/linux-user/arm/cpu_loop.c
index e8417d04069..33f63951a95 100644
--- a/linux-user/arm/cpu_loop.c
+++ b/linux-user/arm/cpu_loop.c
@@ -363,6 +363,7 @@ void cpu_loop(CPUARMState *env)
switch (n) {
case ARM_NR_cacheflush:
/* nop */
+ env->regs[0] = 0;
break;
case ARM_NR_set_tls:
cpu_set_tls(env, env->regs[0]);
--
2.43.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PULL 0/9] target-arm queue
2025-06-16 14:06 [PULL 0/9] target-arm queue Peter Maydell
` (8 preceding siblings ...)
2025-06-16 14:06 ` [PULL 9/9] linux-user/arm: Fix return value of SYS_cacheflush Peter Maydell
@ 2025-06-17 13:10 ` Stefan Hajnoczi
9 siblings, 0 replies; 22+ messages in thread
From: Stefan Hajnoczi @ 2025-06-17 13:10 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 116 bytes --]
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/10.1 for any user-visible changes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread