summary refs log tree commit diff stats
path: root/scripts/tracetool/backend/syslog.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-05-28qapi: make s390x specific CPU commands unconditionally availableDaniel P. Berrangé8-15/+35
This removes the TARGET_S390X and CONFIG_KVM conditions from the CPU commands that are conceptually specific to s390x. Top level stubs are provided to cope with non-s390x targets, or builds without KVM. The removal of CONFIG_KVM is justified by the fact there is no conceptual difference between running 'qemu-system-s390x -accel tcg' on a build with and without KVM built-in, so apps only using TCG can't rely on the CONFIG_KVM in the schema. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-11-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: make most CPU commands unconditionally availableDaniel P. Berrangé14-406/+437
This removes the TARGET_* conditions from all the CPU commands that are conceptually target independent. Top level stubs are provided to cope with targets which do not currently implement all of the commands. Adjust the doc comments accordingly. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-10-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: Make CpuModelExpansionInfo::deprecated-props optional and genericPhilippe Mathieu-Daudé1-4/+3
We'd like to have some unified QAPI schema. Having a structure field conditional to a target being built in is not very practical. While @deprecated-props is only used by s390x target, it is generic enough and could be used by other targets (assuming we expand CpuModelExpansionType enum values). Let's always include this field, regardless of the target, but make it optional. This is not a compatibility break only because the field remains present always on S390x. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-9-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: remove the misc-target.json fileDaniel P. Berrangé5-7/+0
This file is now empty and can thus be removed. Observe the pre-existing bug with s390-skeys.c and target/i386/monitor.c both including qapi-commands-misc-target.h despite not requiring it. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-8-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: make Xen event commands unconditionally availableDaniel P. Berrangé6-125/+125
This removes the TARGET_I386 condition from the Xen event channel commands, moving them to the recently introduced misc-i386.json QAPI file, given they are inherantly i386 specific commands. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-7-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: make SGX commands unconditionally availableDaniel P. Berrangé6-81/+97
This removes the TARGET_I386 condition from the SGX confidential virtualization commands, moving them to the recently introduced misc-i386.json QAPI file, given they are inherantly i386 specific commands. Observe a pre-existing bug that the "SGXEPCSection" struct lacked a TARGET_I386 condition, despite its only usage being behind a TARGET_I386 condition. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-6-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: expose query-gic-capability command unconditionallyDaniel P. Berrangé7-45/+65
This removes the TARGET_ARM condition from the query-gic-capability command. This requires providing a QMP command stub for non-ARM targets. This in turn requires moving the command out of misc-target.json, since that will trigger symbol poisoning errors when built from target independent code. Following the earlier precedent, this creates a misc-arm.json file to hold this ARM specific command. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-5-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: make SEV commands unconditionally availableDaniel P. Berrangé6-324/+316
This removes the TARGET_I386 condition from the SEV confidential virtualization commands, moving them to the recently introduced misc-i386.json QAPI file, given they are inherantly i386 specific commands. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-4-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-28qapi: expand docs for SEV commandsDaniel P. Berrangé1-7/+43
This gives some more context about the behaviour of the commands in unsupported guest configuration or platform scenarios. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-3-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Tweak query-sev doc, turn error descriptions into Errors sections, delate a stray #, normalize whitespace, wrap lines]
2025-05-28qapi: expose rtc-reset-reinjection command unconditionallyDaniel P. Berrangé7-18/+40
This removes the TARGET_I386 condition from the rtc-reset-reinjection command. This requires providing a QMP command stub for non-i386 target. This in turn requires moving the command out of misc-target.json, since that will trigger symbol poisoning errors when built from target independent code. Rather than putting the command into misc.json, it is proposed to create misc-$TARGET.json files to hold commands whose impl is conceptually only applicable to a single target. This gives an obvious docs hint to consumers that the command is only useful in relation a specific target, while misc.json is for commands applicable to 2 or more targets. The current impl of qmp_rtc_reset_reinject() is a no-op if the i386 RTC is disabled in Kconfig, or if the running machine type lack any RTC device. The stub impl for non-i386 targets retains this no-op behaviour. However, it is now reporting an Error mentioning this command is not available for current target. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20250522190542.588267-2-pierrick.bouvier@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2025-05-25docs: Remove ast2700fc from Aspeed family boardsSteven Lee1-1/+1
The ast2700fc machine is now covered in the dedicated ast2700-evb section. Listing it in the general Aspeed board family list is redundant. Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250523093144.991408-7-steven_lee@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/arm/fby35: Map BMC memory into system memorySteven Lee1-0/+1
Add the BMC memory region as a subregion of system_memory so that modules relying on system memory can operate correctly. Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250523093144.991408-6-steven_lee@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/arm/aspeed_ast27x0-fc: Map ca35 memory into system memorySteven Lee1-0/+1
Map the CA35 memory region as a subregion of system_memory to ensure a valid FlatView. This prevents failures in APIs that rely on the global memory view, such as rom_check_and_register_reset(). Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250523093144.991408-5-steven_lee@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/arm/aspeed_ast27x0: Fix unimplemented region overlap with vbootromSteven Lee1-2/+2
The unimplemented memory region overlaps with the VBootROM address range, causing incorrect memory layout. This patch adjusts the size and start address of the unimplemented region to avoid collision. The IO memory region (ASPEED_DEV_IOMEM) is now moved to 0x20000 to reserve space for VBootROM at 0x0. Although the memory range 0x20000 - 0x10000000 is undefined in the datasheet and should not be required, further testing shows OP-TEE or U-Boot may access 0x400000 during early boot. Removing the unimplemented region causes firmware hangs. To prevent unexpected accesses, retain the region as a safeguard. Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250523093144.991408-4-steven_lee@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/arm/aspeed_ast2700-fc: Reduce ca35 ram size to align with ast2700a1Steven Lee1-1/+1
Reduce ca35 ram size from 2GiB to 1GiB to align with ast2700a1-evb, where the ram-container is defined as 1GiB in its class. Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250523093144.991408-3-steven_lee@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/arm/aspeed_ast2700-fc: Add network supportSteven Lee1-0/+7
This patch adds network support to the ast2700fc machine by initializing the NIC device in the ca35. Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250523093144.991408-2-steven_lee@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/arm/aspeed_ast27x0: Fix RAM size detection failure on BE hostsJamin Lin1-4/+6
On big-endian hosts, the aspeed_ram_capacity_write() function previously passed the address of a 64-bit "data" variable directly to address_space_write(), assuming host and guest endianness matched. However, the data is expected to be written in little-endian format to DRAM. On big-endian hosts, this led to incorrect data being written into DRAM, which caused the guest firmware to misdetect the DRAM size. As a result, U-Boot fails to boot and hangs. - Replaces the "address_space_write()" call with "address_space_stl_le()", which performs an explicit 32-bit little-endian write. - Updating the MemoryRegionOps to restrict access to exactly 4 bytes using .valid.{min,max}_access_size = 4 and .impl.min_access_size = 4. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Fixes: 7436db1 ("aspeed/soc: fix incorrect dram size for AST2700") Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250522023305.2486536-4-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/intc/aspeed Fix coding styleJamin Lin1-2/+4
Fix coding style issues from checkpatch.pl. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250522023305.2486536-3-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/intc/aspeed: Set impl.min_access_size to 4Jamin Lin1-0/+6
This patch explicitly sets ".impl.min_access_size = 4" to match the declared ".valid.min_access_size = 4", enforcing stricter access size checking and preventing inconsistent partial accesses to the interrupt controller registers. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250522023305.2486536-2-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Add tests for AST2700Jamin Lin2-0/+100
The HACE models in AST2600 and AST2700 are nearly identical. Based on the AST2600 test cases, new tests have been added for AST2700. Implemented test functions for SHA-256, SHA-384, SHA-512, and MD5. Added scatter-gather and accumulation test variants. For AST2700, the HACE controller base address starts at "0x12070000", and the DRAM start address is "0x4_00000000". Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-29-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Support to validate 64-bit hmac key buffer addressesJamin Lin3-0/+20
Added "key" and "key_hi" fields to "AspeedMasks" for 64-bit addresses test. Updated "aspeed_test_addresses" to validate "HACE_HASH_KEY_BUFF" and "HACE_HASH_KEY_BUFF_HI". Ensured correct masking of 64-bit addresses by checking both lower and upper 32-bit registers. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-28-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Support to test upper 32 bits of digest and source addressesJamin Lin2-1/+16
Added "src_hi" and "dest_hi" fields to "AspeedMasks" for 64-bit addresses test. Updated "aspeed_test_addresses" to validate "HACE_HASH_SRC_HI" and "HACE_HASH_DIGEST_HI". Ensured correct masking of 64-bit addresses by checking both lower and upper 32-bit registers. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-27-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Support 64-bit source and digest addresses for AST2700Jamin Lin2-0/+5
Added "HACE_HASH_SRC_HI" and "HACE_HASH_DIGEST_HI", "HACE_HASH_KEY_BUFF_HI" registers to store upper 32 bits. Updated "write_regs" to handle 64-bit source and digest addresses. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-26-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Update source data and digest data type to 64-bitJamin Lin2-46/+46
Currently, the hash data source and digest result buffer addresses are set to 32-bit. However, the AST2700 CPU is a 64-bit Cortex-A35 architecture, and its DRAM base address is also 64-bit. To support AST2700, update the hash data source address and digest result buffer address to use 64-bit addressing. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-25-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Add tests for AST1030Jamin Lin1-0/+76
The HACE model in AST2600 and AST1030 is identical. Referencing the AST2600 test cases, new tests have been created for AST1030. Implemented test functions for SHA-256, SHA-384, SHA-512, and MD5. Added scatter-gather and accumulation test variants. For AST1030, the HACE controller base address starts at "0x7e6d0000", and the SDRAM start address is "0x0". Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-24-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Add SHA-384 tests for AST2600Jamin Lin1-0/+18
Introduced "test_sha384_ast2600" to validate SHA-384 hashing. Added "test_sha384_sg_ast2600" for scatter-gather SHA-384 verification. Implemented "test_sha384_accum_ast2600" to test SHA-384 accumulation. Registered new test cases in "main" to ensure execution. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-23-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Add SHA-384 test cases for ASPEED HACE modelJamin Lin2-3/+171
Introduced SHA-384 test functions to verify hashing operations. Extended support for scatter-gather ("_sg") and accumulation ("_accum") tests. Updated test result vectors for SHA-384 validation. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-22-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Adjust test address range for AST1030 due to SRAM limitationsJamin Lin1-15/+15
The digest_addr is set to "src_addr + 0x1000000", where src_addr is the DRAM base address. However, the value 0x1000000 (16MB) is too large because the AST1030 does not support DRAM, and its SRAM size is only 768KB. A range size of 0x10000 (64KB) is sufficient for HACE test cases, as the test vector size does not exceed 64KB. Updates: 1. Direct Access Mode Update digest_addr to "src_addr + 0x10000" in the following functions: aspeed_test_md5 aspeed_test_sha256 aspeed_test_sha512 2. Scatter-Gather (SG) Mode Update source address for different SG buffer addresses in the following functions: src_addr1 = src_addr + 0x10000 src_addr2 = src_addr + 0x20000 src_addr3 = src_addr + 0x30000 digest_addr = src_addr + 0x40000 aspeed_test_sha256_sg aspeed_test_sha512_sg 3. ACC Mode Update Update the SG List start address: src_addr + 0x10000 Update the SG List buffer size to 0x30000 (192KB). buffer_addr = src_addr + 0x10000 digest_addr = src_addr + 0x40000 Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-21-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest/hace: Specify explicit array sizes for test vectors and hash resultsJamin Lin1-13/+13
To enhance code readability and prevent potential buffer overflows or unintended size assumptions, this commit updates all fixed-size array declarations to use explicit array sizes. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-20-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25test/qtest: Introduce a new aspeed-hace-utils.c to place common testcasesJamin Lin4-495/+547
The test cases for the ASPEED HACE model were originally placed in aspeed_hace-test.c. However, this test file only supports ARM32. To enable compatibility with all ASPEED SoCs, including the AST2700, which uses the AArch64 architecture, this update introduces a new source file, aspeed-hace-utils.c. All common APIs and test cases have been moved from aspeed_hace-test.c to aspeed-hace-utils.c to facilitate reuse across different ASPEED SoCs. As a result, these test cases can now be reused for AST2700 and future ASPEED SoC testing. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-19-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25tests/qtest: Reorder aspeed test listJamin Lin1-5/+5
Reordered the aspeed test list to keep the alphabetical order. No functional changes in test behavior. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-18-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Support to dump plaintext and digest for better debuggingJamin Lin2-0/+47
1. Added "hace_hexdump()" to dump a contiguous buffer using qemu_hexdump. 2. Added "hace_iov_hexdump()" to flatten and dump scatter-gather source vectors. 3. Introduced a new trace event: "aspeed_hace_hexdump". Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-17-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Add trace-events for better debuggingJamin Lin2-0/+17
Introduced "trace_aspeed_hace_hash_addr", "trace_aspeed_hace_hash_sg", "trace_aspeed_hace_read", "trace_aspeed_hace_hash_execute_acc_mode", and "trace_aspeed_hace_write" trace events. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-16-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Support DMA 64 bits dram addressJamin Lin2-1/+17
According to the AST2700 design, the data source address is 64-bit, with R_HASH_SRC_HI storing bits [63:32] and R_HASH_SRC storing bits [31:0]. Similarly, the digest address is 64-bit, with R_HASH_DEST_HI storing bits [63:32] and R_HASH_DEST storing bits [31:0]. To maintain compatibility with older SoCs such as the AST2600, the AST2700 HW automatically set bit 34 of the 64-bit sg_addr. As a result, the firmware only needs to provide a 32-bit sg_addr containing bits [31:0]. This is sufficient for the AST2700, as it uses a DRAM offset rather than a DRAM address. Introduce a has_dma64 class attribute and set it to true for the AST2700. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-15-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Add support for source, digest, key buffer 64 bit addressesJamin Lin2-1/+33
According to the AST2700 design, the data source address is 64-bit, with R_HASH_SRC_HI storing bits [63:32] and R_HASH_SRC storing bits [31:0]. Similarly, the digest address is 64-bit, with R_HASH_DIGEST_HI storing bits [63:32] and R_HASH_DIGEST storing bits [31:0]. The HMAC key buffer address is also 64-bit, with R_HASH_KEY_BUFF_HI storing bits [63:32] and R_HASH_KEY_BUFF storing bits [31:0]. The AST2700 supports a maximum DRAM size of 8 GB, with a DRAM addressable range from 0x0_0000_0000 to 0x1_FFFF_FFFF. Since this range fits within 34 bits, only bits [33:0] are needed to store the DRAM offset. To optimize address storage, the high physical address bits [1:0] of the source, digest and key buffer addresses are stored as dram_offset bits [33:32]. To achieve this, a src_hi_mask with a mask value of 0x3 is introduced, ensuring that src_addr_hi consists of bits [1:0]. The final src_addr is computed as (src_addr_hi[1:0] << 32) | src_addr[31:0], representing the DRAM offset within bits [33:0]. Similarly, a dest_hi_mask with a mask value of 0x3 is introduced to ensure that dest_addr_hi consists of bits [1:0]. The final dest_addr is calculated as (dest_addr_hi[1:0] << 32) | dest_addr[31:0], representing the DRAM offset within bits [33:0]. Additionally, a key_hi_mask with a mask value of 0x3 is introduced to ensure that key_buf_addr_hi consists of bits [1:0]. The final key_buf_addr is determined as (key_buf_addr_hi[1:0] << 32) | key_buf_addr[31:0], representing the DRAM offset within bits [33:0]. This approach eliminates the need to reduce the high part of the DRAM physical address for DMA operations. Previously, this was calculated as (high physical address bits [7:0] - 4), since the DRAM start address is 0x4_00000000, making the high part address [7:0] - 4. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-14-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Move register size to instance class and dynamically ↵Jamin Lin2-19/+22
allocate regs Dynamically allocate the register array by removing the hardcoded ASPEED_HACE_NR_REGS macro. To support different register sizes across SoC variants, introduce a new "nr_regs" class attribute and replace the static "regs" array with dynamically allocated memory. Add a new "aspeed_hace_unrealize" function to properly free the allocated "regs" memory during device cleanup. Remove the bounds checking in the MMIO read/write handlers since the MemoryRegion size now matches the (register array size << 2). This commit updates the VMState fields accordingly. The VMState version was already bumped in a previous patch of this series, so no further version change is needed. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-13-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Support accumulative mode for direct access modeJamin Lin1-3/+21
Enable accumulative mode for direct access mode operations. In direct access mode, only a single source buffer is used, so the "iovec" count is set to 1. If "acc_mode" is enabled: 1. Accumulate "total_req_len" with the current request length ("plen"). 2. Check for padding and determine whether this is the final request. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-12-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Rename R_HASH_DEST to R_HASH_DIGEST and introduce ↵Jamin Lin1-6/+19
64-bit hash digest address helper Renaming R_HASH_DEST to R_HASH_DIGEST for better semantic clarity. The AST2700 CPU, based on the Cortex-A35, features a 64-bit DRAM address space. To prepare for future AST2700 support, this change introduces a new helper function hash_get_digest_addr() to encapsulate digest address extraction logic and improve code readability. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-11-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Introduce 64-bit hash source address helper functionJamin Lin1-7/+17
The AST2700 CPU, based on the Cortex-A35, is a 64-bit processor, and its DRAM address space is also 64-bit. To support future AST2700 updates, the source hash buffer address data type is being updated to 64-bit. Introduces the "hash_get_source_addr()" helper function to extract the source hash buffer address. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-10-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Extract accumulation-mode hash execution into helper ↵Jamin Lin1-33/+41
function To improve code readability and maintainability of do_hash_operation(), this commit introduces a new helper function: hash_execute_acc_mode(). This function encapsulates the full flow for accumulation mode, including context initialization, update, conditional finalization, and digest writeback with I/O vector unmapping. No functional changes are introduced. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-9-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Extract non-accumulation hash execution into helper ↵Jamin Lin1-8/+24
function To improve code readability and maintainability of do_hash_operation(), this commit introduces a new helper function: hash_execute_non_acc_mode(). The helper encapsulate the hashing logic for non-accumulation mode. No functional changes are introduced. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-8-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Extract digest write and iov unmap into helper functionJamin Lin1-12/+21
To improve code readability and maintainability of do_hash_operation(), this commit introduces a new helper function: hash_write_digest_and_unmap_iov(). The helper consolidates the final digest writeback and subsequent unmapping of the I/O vectors into a single routine. No functional changes are introduced. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-7-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Extract SG-mode hash buffer setup into helper functionJamin Lin1-48/+63
To improve code readability and maintainability of do_hash_operation(), this commit introduces a new helper function: hash_prepare_sg_iov(). This function handles scatter-gather (SG) mode setup, including SG list parsing, address mapping, and optional accumulation mode support with padding detection. No functional changes are introduced. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-6-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Extract direct mode hash buffer setup into helper functionJamin Lin1-10/+32
To improve code readability and maintainability of do_hash_operation(), this commit introduces a new helper function: hash_prepare_direct_iov(). This function encapsulates the logic for setting up the I/O vector (iov) in direct mode (non-scatter-gather). No functional changes are introduced. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-5-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Ensure HASH_IRQ is always set to prevent firmware hangJamin Lin1-9/+9
Currently, if the program encounters an unsupported algorithm, it does not set the HASH_IRQ bit in the status register and send an interrupt to indicate command completion. As a result, the FW gets stuck waiting for a completion signal from the HACE module. Additionally, in do_hash_operation, if an error occurs within the conditional statement, the HASH_IRQ bit is not set in the status register. This causes the firmware to continuously send HASH commands, as it is unaware that the HACE model has completed processing the command. To fix this, the HASH_IRQ bit in the status register must always be set to ensure that the firmware receives an interrupt from the HACE module, preventing it from getting stuck or repeatedly sending HASH commands. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Fixes: c5475b3 ("hw: Model ASPEED's Hash and Crypto Engine") Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-4-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Improve readability and consistency in variable namingJamin Lin1-34/+33
Currently, users define multiple local variables within different if-statements. To improve readability and maintain consistency in variable naming, rename the variables accordingly. Introduced "sg_addr" to clearly indicate the scatter-gather mode buffer address. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-3-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25hw/misc/aspeed_hace: Remove unused code for better readabilityJamin Lin2-39/+2
In the previous design of the hash framework, accumulative hashing was not supported. To work around this limitation, commit 5cd7d85 introduced an iov_cache array to store all the hash data from firmware. Once the ASPEED HACE model collected all the data, it passed the iov_cache to the hash API to calculate the final digest. However, with commit e3c0752, the hash framework now supports accumulative hashing. This allows us to refactor the ASPEED HACE model, removing redundant logic and simplifying the implementation for better readability and maintainability. As a result, the iov_count variable is no longer needed—it was previously used to track how many cached entries were used for hashing. To maintain VMSTATE compatibility after removing this field, the VMSTATE_VERSION is bumped to 2 This cleanup follows significant changes in commit 4c1d0af4a28d, making the model more readable. - Deleted "iov_cache" and "iov_count" from "AspeedHACEState". - Removed "reconstruct_iov" function and related logic. - Simplified "do_hash_operation" by eliminating redundant checks. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250515081008.583578-2-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25tests/qtest/aspeed_smc-test: Fix memory leaksJamin Lin1-0/+5
Link: https://patchwork.kernel.org/project/qemu-devel/patch/20250509175047.26066-1-farosas@suse.de/ Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250513080806.1005996-1-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25tests/qtest/ast2700-smc-test: Fix leakFabiano Rosas1-0/+1
ASAN spotted a leak of the memory used to hold the tmp_path: Direct leak of 35 byte(s) in 1 object(s) allocated from: #0 0x55e29aa96da9 in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 #1 0x7fe0cfb26518 in g_malloc ../glib/gmem.c:106 #2 0x7fe0cfb4146e in g_strconcat ../glib/gstrfuncs.c:629 #3 0x7fe0cfb0a78f in g_get_tmp_name ../glib/gfileutils.c:1742 #4 0x7fe0cfb0b00b in g_file_open_tmp ../glib/gfileutils.c:1802 #5 0x55e29ab53961 in test_ast2700_evb ../tests/qtest/ast2700-smc-test.c:20:10 #6 0x55e29ab53803 in main ../tests/qtest/ast2700-smc-test.c:65:5 #7 0x7fe0cf7bd24c in __libc_start_main ../csu/libc-start.c:308 #8 0x55e29a9f7759 in _start ../sysdeps/x86_64/start.S:120 Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Message-ID: <20250509175047.26066-1-farosas@suse.de> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-05-25audio: Reset rate control when adding bytesAkihiko Odaki2-6/+9
Commit 90320051ea99 ("spiceaudio: add a pcm_ops buffer_get_free function") caused to emit messages saying "Resetting rate control" frequently when the guest generates no frames. audio_rate_peek_bytes() resets the rate control when frames < 0 || frames > 65536 where frames is the rate-limited number of frames. Resetting when frames < 0 is sensible as the number simply doesn't make sense. There is a problem when frames > 65536. It implies the guest stopped generating frames for a while so it makes sense to reset the rate control when the guest resumed generating frames. However, the commit mentioned earlier broke this assumption by letting spiceaudio call audio_rate_peek_bytes() whether the guest is generating frames or not. Reset the rate control in audio_rate_add_bytes(), which is called only when actually adding frames, according to the previous call to audio_rate_peek_bytes() to avoid frequent rate control resets even when the guest generates no frame. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20250317-rate-v1-1-da9df062747c@daynix.com>