summary refs log tree commit diff stats
path: root/docs/sphinx/qapidoc.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-01-11target/s390x: Fix LAE setting a wrong access registerIlya Leoshkevich1-1/+2
LAE should set the access register corresponding to the first operand, instead, it always modifies access register 1. Co-developed-by: Ido Plat <Ido.Plat@ibm.com> Cc: qemu-stable@nongnu.org Fixes: a1c7610a6879 ("target-s390x: implement LAY and LAEY instructions") Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20240111092328.929421-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11scripts/checkpatch: Support codespell checkingZhao Liu1-20/+105
Add two spelling check options (--codespell and --codespellfile) to enhance spelling check through dictionary, which copied the Linux kernel's implementation in checkpatch.pl. This check uses the dictionary at "/usr/share/codespell/dictionary.txt" by default, if there is no dictionary specified under this path, it will look for the dictionary of python3's codespell (This requires user to add python3's path in environment variable $PATH, and to install codespell by "pip install codespell"). Tested-by: Yongwei Ma <yongwei.ma@intel.com> Tested-by: Samuel Tardieu <sam@rfc1149.net> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240105083848.267192-1-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11hw/s390x/ccw: Replace dirname() with g_path_get_dirname()Zhao Liu1-1/+3
As commit 3e015d815b3f ("use g_path_get_basename instead of basename") said, g_path_get_dirname() should be preferred over dirname() since the former is a portable utility function that has the advantage of not modifying the string argument. Replace dirname() with g_path_get_dirname(). Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20231221171921.57784-3-zhao1.liu@linux.intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11hw/s390x/ccw: Replace basename() with g_path_get_basename()Zhao Liu1-2/+3
g_path_get_basename() is a portable utility function that has the advantage of not modifying the string argument, so it should be preferred over basename(). And also to avoid potential compile breakage with the Musl C library similar to [1], replace basename() with g_path_get_basename(). [1]: https://lore.kernel.org/all/20231212010228.2701544-1-raj.khem@gmail.com/ Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20231221171921.57784-2-zhao1.liu@linux.intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11target/s390x/kvm/pv: Provide some more useful information if decryption failsThomas Huth5-12/+30
It's a common scenario to copy guest images from one host to another to run the guest on the other machine. This (of course) does not work with "secure execution" guests since they are encrypted with one certain host key. However, if you still (accidentally) do it, you only get a very user-unfriendly error message that looks like this: qemu-system-s390x: KVM PV command 2 (KVM_PV_SET_SEC_PARMS) failed: header rc 108 rrc 5 IOCTL rc: -22 Let's provide at least a somewhat nicer hint to the users so that they are able to figure out what might have gone wrong. Buglink: https://issues.redhat.com/browse/RHEL-18212 Message-ID: <20240110142916.850605-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11gitlab: fix s390x tag for avocado-system-centosNicholas Piggin1-1/+1
The 390x tag should be s390x. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-ID: <20240107170119.82222-2-npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11tests/qtest/virtio-ccw: Fix device presence checkingSamuel Tardieu1-1/+1
An apparent copy-paste error tests for the presence of the virtio-rng-ccw device in order to perform tests on the virtio-scsi-ccw device. Signed-off-by: Samuel Tardieu <sam@rfc1149.net> Message-ID: <20240106130121.1244993-1-sam@rfc1149.net> Fixes: 65331bf5d1 ("tests/qtest: Check for virtio-ccw devices before using them") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11qtest: ensure netdev-socket tests have non-overlapping namesDaniel P. Berrangé1-1/+1
When naming glib tests if the name of one test is a substring of the name of another test, it is not possible to use the '-p /the/name' option to run a single test. Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240104162942.211458-7-berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11net: handle QIOTask completion to report useful error messageDaniel P. Berrangé1-5/+10
The network stream backend uses the async QIO socket APIs for listening and connecting sockets. It does not check the task object completion status, however, instead just looking at whether the socket FD is -1 or not. By checking the task completion, we can set a useful error message for users instead of the non-actionable "connection error" string. eg so users will see: (qemu) info network net: index=0,type=stream,error: Failed to connect to '/foo.unix': No such file or directory Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240104162942.211458-6-berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11net: add explicit info about connecting/listening stateDaniel P. Berrangé2-6/+9
When running 'info network', if the stream backend is still in the process of connecting, or waiting for an incoming connection, no information is displayed. There is also no way to distinguish whether the server is still in the process of setting up the listener socket, or whether it is ready to accept incoming client connections. This leads to a race condition in the netdev-socket qtest which launches a server process followed by a client process. Under high load conditions it is possible for the client to attempt to connect before the server is accepting clients. For the scenarios which do not set the 'reconnect' option, this opens up a race which can lead to the test scenario failing to reach the expected state. Now that 'info network' can distinguish between initialization phase and the listening phase, the netdev-socket qtest will correctly synchronize, such that the client QEMU is not spawned until the server is ready. This should solve the non-deterministic failures seen with the netdev-socket qtest. Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240104162942.211458-5-berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11Revert "tests/qtest/netdev-socket: Raise connection timeout to 120 seconds"Daniel P. Berrangé1-1/+1
This reverts commit 0daaf2761f6d268ffaa2d01d450e202e127452b1. The test was not timing out because of slow execution. It was timing out due to a race condition leading to the client QEMU attempting (and fatally failing) to connect before the server QEMU was listening. Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240104162942.211458-4-berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11Revert "osdep: add getloadavg"Daniel P. Berrangé2-11/+0
This reverts commit dc864d3a3777424187280e50c9bfb84dced54f12. This functionality is not required after the previous revert Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240104162942.211458-3-berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11Revert "netdev: set timeout depending on loadavg"Daniel P. Berrangé1-27/+1
This reverts commit cadfc7293977ecadc2d6c48d7cffc553ed2f85f1. The test was not timing out because of slow execution. It was timing out due to a race condition leading to the client QEMU attempting (and fatally failing) to connect before the server QEMU was listening. Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240104162942.211458-2-berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11qtest: use correct boolean type for failover propertyDaniel P. Berrangé1-18/+18
QMP device_add does not historically validate the parameter types. At some point it will likely change to enforce correct types, to match behaviour of -device. The failover property is expected to be a boolean in JSON. Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240103123005.2400437-1-berrange@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-11q800: move dp8393x_prom memory region to Q800MachineStateMark Cave-Ayland2-4/+4
There is no need to dynamically allocate the memory region from the heap. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20231227210212.245106-1-mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-10target/riscv: Ensure mideleg is set correctly on resetAlistair Francis1-0/+8
Bits 10, 6, 2 and 12 of mideleg are read only 1 when the Hypervisor is enabled. We currently only set them on accesses to mideleg, but they aren't correctly set on reset. Let's ensure they are always the correct value. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1617 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240108001328.280222-4-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Don't adjust vscause for exceptionsAlistair Francis1-2/+2
We have been incorrectly adjusting both the interrupt and exception cause when using the hypervisor extension and trapping to VS-mode. This patch changes the conditional to ensure we only adjust the cause for interrupts and not exceptions. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1708 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240108001328.280222-3-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Assert that the CSR numbers will be correctAlistair Francis1-1/+4
The CSRs will always be between either CSR_MHPMCOUNTER3 and CSR_MHPMCOUNTER31 or CSR_MHPMCOUNTER3H and CSR_MHPMCOUNTER31H. So although ctr_index can't be negative, Coverity doesn't know this and it isn't obvious to human readers either. Let's add an assert to ensure that Coverity knows the values will be within range. To simplify the code let's also change the RV32 adjustment. Fixes: Coverity CID 1523910 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240108001328.280222-2-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: pmp: Ignore writes when RW=01 and MML=0Ivan Klokov1-1/+1
This patch changes behavior on writing RW=01 to pmpcfg with MML=0. RWX filed is form of collective WARL with the combination of pmpcfg.RW=01 remains reserved for future standard use. According to definition of WARL writing the CSR has no other side effect. But current implementation change architectural state and change system behavior. After writing we will get unreadable-unwriteble region regardless on the previous state. On the other side WARL said that we should read legal value and nothing says about what we should write. Current behavior change system state regardless of whether we read this register or not. Fixes: ac66f2f0 ("target/riscv: pmp: Ignore writes when RW=01") Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231220153205.11072-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10roms/opensbi: Upgrade from v1.3.1 to v1.4Bin Meng3-0/+0
Upgrade OpenSBI from v1.3.1 to v1.4 and the pre-built bios images. The v1.4 release includes the following commits: 1a398d9 lib: sbi: Add Zicntr as a HART ISA extension 669089c lib: sbi: Add Zihpm as a HART ISA extension 72b9c8f lib: sbi: Alphabetically sort HART ISA extensions 5359fc6 lib: sbi: Rename hart_pmu_get_allowed_bits() function 976895c lib: sbi: Fix Priv spec version for [m|s]counteren and mcountinhibit CSRs 6053917 lib: sbi: Fix how print gets flags 35ef182 lib: sbi: print not fill '0' when left-aligned 40dac06 lib: sbi: Add '+' flags for print 458fa74 lib: sbi: Add ' ' '\'' flags for print 05cbb6e lib: sbi: implifying the parameters of printi fe08281 lib: sbi: print add 'o' type c6ee5ae lib: sbi: Fix printi 3b6fcdd lib: sbi: Simplify prints cc89fa7 lib: sbi: Fix printc ff43168 lib: sbi: Fix timing of clearing tbuf a73982d lib: sbi: Fix missing '\0' when buffer szie equal 1 ea6533a lib: utils/gpio: Fix RV32 compile error for designware GPIO driver c3b98c6 include: sbi: Add macro definitions for mseccfg CSR 1c099c4 lib: sbi: Add functions to manipulate PMP entries 6c202c5 include: sbi: Add Smepmp specific access flags for PMP entries cbcfc7b lib: sbi: Add smepmp in hart extensions d72f5f1 lib: utils: Add detection of Smepmp from ISA string in FDT 4a42a23 lib: sbi: Grant SU R/W/X permissions to whole memory f3fdd04 lib: sbi: Change the order of PMP initialization 5dd8db5 lib: sbi: Add support for Smepmp 6e44ef6 lib: sbi: Add functions to map/unmap shared memory 0ad8660 lib: sbi: Map/Unmap debug console shared memory buffers 057eb10 lib: utils/gpio: Fix RV32 compile error for designware GPIO driver 0e2111e libfdt: fix SPDX license identifiers e05a9cf lib: sbi: Update system suspend to spec 5e20d25 include: sbi: fix CSR define of mseccfg 44c5151 include: sbi_utils: Remove driver pointer from struct i2c_adapter 14a35b0 lib: utils/regmap: Add generic regmap access library 8e97275 lib: utils/regmap: Add simple FDT based regmap framework f21d8f7 lib: utils/regmap: Add simple FDT based syscon regmap driver 4a344a9 lib: utils/reset: Add syscon based reboot and poweroff c2e6027 lib: utils/reset: Remove SiFive Test reset driver f536e0b gitignore: allow gitignore to ignore most dot file c744ed7 lib: sbi_pmu: Enable noncontigous hpm event and counters 6259b2e lib: utils/fdt: Fix fdt_parse_isa_extensions() implementation f46a564 lib: sbi: Fix typo for finding fixed event counter 94197a8 fw_base.S: Fix assembler error with clang 16+ c104c60 lib: sbi: Add support for smcntrpmf 7aabeee Makefile: Fix grep warning e7e73aa platform: generic: allwinner: correct mhpmevent count ee1f83c lib: sbi_pmu: remove mhpm_count field in hart feature a9cffd6 firmware: payload: test: Change to SBI v2.0 DBCN ecalls b20bd47 lib: sbi: improve the definition of SBI_IPI_EVENT_MAX 664692f lib: sbi_pmu: ensure update hpm counter before starting counting c9a296d platform: generic: allwinner: fix OF process for T-HEAD c9xx pmu 901d3d7 lib: sbi_pmu: keep overflow interrupt of stopped hpm counter disabled cacfba3 platform: Allow platforms to specify the size of tlb fifo 5bd9694 lib: sbi: alloc tlb fifo by sbi_malloc 130e65d lib: sbi: Implement SET_FS_DIRTY() to make sure the mstatus FS dirty is set d1e4dff lib: sbi: Introduce HART index in sbi_scratch e6125c3 lib: sbi: Remove sbi_platform_hart_index/invalid() functions 296e70d lib: sbi: Extend sbi_hartmask to support both hartid and hartindex e632cd7 lib: sbi: Use sbi_scratch_last_hartindex() in remote TLB managment 78c667b lib: sbi: Prefer hartindex over hartid in IPI framework 22d6ff8 lib: sbi: Remove sbi_scratch_last_hartid() macro 112daa2 lib: sbi: Maximize the use of HART index in sbi_domain 9560fb3 include: sbi: Remove sbi_hartmask_for_each_hart() macro b8fb96e include: sbi_domain: Fix permission test macros bff27c1 lib: sbi: Factor-out Smepmp configuration as separate function 5240d31 lib: sbi: Don't clear mseccfg.MML bit in sbi_hart_smepmp_configure() 2b51a9d lib: sbi: Fix pmp_flags for Smepmp read-only shared region 73aea28 lib: sbi: Populate M-only Smepmp entries before setting mseccfg.MML e8bc162 lib: utils/serial: Add shared regions for serial drivers b7e9d34 lib: utils/regmap: Mark syscon region as shared read-write 3669153 platform: generic: thead: fix stale TLB entries for th1520/sg2042 de525ac firmware: Remove ALIGN in .rela.dyn in linker script 2a6d725 firmware: Remove handling of R_RISCV_{32,64} 6ed125a Makefile: Add --exclude-libs ALL to avoid .dynsym e21901d doc: Fix fw_payload.md a125423 lib: utils/serial: Ensure proper allocation of PMP entries for uart8250 d36709f lib: utils: timer/ipi: Update memregion flags for PLMT and PLICSW 8197c2f lib: sbi: fix sbi_domain_get_assigned_hartmask() 9da30f6 lib: utils/fdt: simplify dt_parse_isa_extensions 942aca2 lib: utils: Simplify SET_ISA_EXT_MAP() f831b93 lib: sbi_pmu: check for index overflows d891cae gpio/starfive: redundant readl() call e8114c6 docs: platform: update platform_requirements.md 3632f2b lib: sbi: Add support for mconfigptr ec0559e lib: sbi_misaligned_ldst: Fix handling of C.SWSP and C.SDSP cbdd869 include: sbi: Change spec version to 2.0 5d0ed1b lib: sbi: simplify sanitize_domain() c1a6987 platform: generic: thead: move to thead c9xx header to vendor specific postion 8e941e7 platform: generic: thead: separate implement of T-HEAD c9xx pmu 492d9b1 platform: generic: thead: separate implement of T-HEAD c9xx errata 3e21b96 platform: generic: thead: initialize PMU by default in thead generic platform a140a4e lib: sbi: Correctly limit flushes to a single ASID/VMID 88ae718 platform: generic: thead: improve tlb flush errata 52fd64b platform: Uses hart count as the default size of tlb info 07f2ccd lib: utils/serial: Optimize semihosting_putc implementation fccdf41 firmware: fw_base.S: Fix boot hart status synchronization d1e0f7f utils/reset: Remove fdt_reset_thead 896d2c9 lib: utils/timer: Allow ACLINT MTIMER driver to setup quirks accafb1 lib: utils/timer: mtimer: add separate T-Head C9xx CLINT mtimer compatible 98bc25f lib: utils/ipi: mswi: add separate T-Head C9xx CLINT mswi compatible 5b2f55d lib: sbi: separate the swap operation of domain region 3b03cdd lib: sbi: Add regions merging when sanitizing domain region 2bfdb9e platform: generic: Add Sophgo sg2042 platform support 280f7ae include: sbi: macros for mseccfg.sseed and .useed efcac33 lib: sbi: Add Zkr in hart extensions 6e5b0cf lib: sbi: enable seed access in S-mode 6602e11 lib: sbi: change sbi_hart_features.extensions as an array 3aaed4f lib: sbi: Make console_puts/console_putc interchangeable dc0bb19 lib: utils/serial: remove semihosting_putc 16bb930 lib: sbi: Fix PMP granularity handling in sbi_hart_map_saddr() 574b9c8 lib: sbi_pmu: avoid buffer overflow 791704c lib: utils/irqchip: Avoid redundant writes to APLIC CLRIE register f520256 lib: sbi: Allow relaxed MMIO writes in device ipi_send() callback b70d628 lib: sbi: Allow relaxed MMIO writes in device ipi_clear() callback bd74931 lib: ipi: Adjust Andes PLICSW to single-bit-per-hart scheme 291403f sbi: sbi_pmu: Improve sbi_pmu_init() error handling 090fa99 lib: sbi: Add XAndesPMU in hart extensions a48f2cf sbi: sbi_pmu: Add hw_counter_filter_mode() to pmu device 51ec60c platform: include: andes45: Add PMU related CSR defines effd89a platform: generic: Introduce pmu_init() platform override 1b9e743 platform: andes: Add Andes custom PMU support 2e50c24 platform: andes: Enable Andes PMU for AE350 535c661 platform: rzfive: Enable Andes PMU for RZ/Five 0b3262e lib: utils: fdt_fixup: Allow preserving PMU properties 009ae4e platform: andes: Factor out is_andes() helper 0308f93 lib: utils: fdt_pmu: Make the fdt_pmu_evt_select table global variable e19d419 lib: utils: fdt_pmu: Do not iterate over the fdt_pmu_evt_select table d162009 docs: pmu: Add Andes PMU node example 6b9a849 lib: sbi: Remove xchg/cmpxchg implemented via lr/sc 11bf49b lib: sbi: Fix __atomic_op_bit_ord and comments 8839869 lib: sbi: Replace __atomic_op_bit_ord with __atomic intrinsics 07419ec lib: sbi: Prevent redundant sbi_ipi_process 93da66b lib: sbi_hart: Store PMP granularity as log base 2 ee72517 lib: sbi_pmu: Add PMU snapshot definitions 11a0ba5 lib: sbi_pmu: Fix the counter info function 0696810 firmware: fix section types a25fc74 lib: sbi_hsm: Put the resume_pending hart in the interruptible hart mask 87aa306 platform: recalculate heap size to support new tlb entry number a2e254e lib: sbi: skip wait_for_coldboot when coolboot done 6112d58 lib: utils/fdt: Allow to use reg-names when parsing ACLINT 35cba92 lib: sbi_tlb: Check tlb_range_flush_limit only once per request a894187 lib: sbi_ipi: Do not ignore errors from sbi_ipi_send() 446fa65 lib: sbi_ipi: Process self-IPIs in sbi_ipi_send() 2707250 lib: sbi_ipi: Drop unnecessary ipi_process check 925ce14 lib: sbi: Simplify the initialization of root_hmask in sbi_domain_init 2c8be56 lib: sbi: Improve the code of privilege mode and extensions detection 056fe6f lib: sbi: Refactor the code for enable extensions in menvfg CSR 776770d lib: sbi: Using one array to define the name of extensions 3daac8f lib: sbi: Detect extensions from the ISA string in DT 416ceb3 lib: sbi_tlb: Reduce size of struct sbi_tlb_info 80169b2 platform: generic: Fine tune fw_platform_calculate_heap_size() cdebae2 lib: utils/irqchip: Add shared MMIO region for PLIC in root domain 3284bea lib: sbi: Allow ecall handlers to directly update register state 5a57e8c lib: sbi: Remove the SBI_ETRAP error code 2b80b92 lib: sbi: Do not enter OpenSBI with mseccfg.MML == 1 63e09ad lib: sbi: Fix shift bug in sbi_system_reset ba29293 lib: utils/timer: mtimer: only use regname for aclint bbd065d lib: sbi: Detect Zicntr extension only based on traps a2b255b include: Bump-up version to 1.4 Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20240102151153.133896-1-bmeng@tinylab.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10docs/system/riscv: sifive_u: Update S-mode U-Boot image build instructionsBin Meng1-21/+12
Currently, the documentation outlines the process for building the S-mode U-Boot image using `make menuconfig` and manual actions within the menuconfig UI. However, this approach is fragile due to Kconfig options potentially changing across different releases. For example, CONFIG_OF_PRIOR_STAGE has been replaced by CONFIG_BOARD since v2022.01 release, and CONFIG_TEXT_BASE has been moved to the 'General setup' menu from the 'Boot options' menu in v2024.01 release. This update aims to make the S-mode U-Boot image build instructions future-proof. It leverages the 'config' script provided in the U-Boot source tree to edit the .config file, followed by a `make olddefconfig`. Validated with U-Boot v2024.01 release. Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240104071523.273702-1-bmeng@tinylab.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: add RVV and Vector CSR regsDaniel Henrique Barboza1-0/+74
Add support for RVV and Vector CSR KVM regs vstart, vl and vtype. Support for vregs[] requires KVM side changes and an extra reg (vlenb) and will be added later. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218204321.75757-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: do PR_RISCV_V_SET_CONTROL during realize()Daniel Henrique Barboza1-0/+29
Linux RISC-V vector documentation (Document/arch/riscv/vector.rst) mandates a prctl() in order to allow an userspace thread to use the Vector extension from the host. This is something to be done in realize() time, after init(), when we already decided whether we're using RVV or not. We don't have a realize() callback for KVM yet, so add kvm_cpu_realize() and enable RVV for the thread via PR_RISCV_V_SET_CONTROL. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218204321.75757-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10linux-headers: riscv: add ptrace.hDaniel Henrique Barboza2-0/+135
KVM vector support for RISC-V requires the linux-header ptrace.h. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218204321.75757-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10linux-headers: Update to Linux v6.7-rc5Daniel Henrique Barboza29-27/+498
We'll add a new RISC-V linux-header file, but first let's update all headers. Headers for 'asm-loongarch' were added in this update. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218204321.75757-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm.c: remove group setting of KVM AIA if the machine only has ↵Yong-Xuan Wang1-14/+17
1 socket The emulated AIA within the Linux kernel restores the HART index of the IMSICs according to the configured AIA settings. During this process, the group setting is used only when the machine partitions harts into groups. It's unnecessary to set the group configuration if the machine has only one socket, as its address space might not contain the group shift. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231218090543.22353-2-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add rva22s64 cpuDaniel Henrique Barboza2-0/+9
Add a new profile CPU 'rva22s64' to work as an alias of -cpu rv64i,rva22s64 Like the existing rva22u64 CPU already does with the RVA22U64 profile. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-27-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add RVA22S64 profileDaniel Henrique Barboza1-0/+32
The RVA22S64 profile consists of the following: - all mandatory extensions of RVA22U64; - priv spec v1.12.0; - satp mode sv39; - Ssccptr, a cache related named feature that we're assuming always enable since we don't implement a cache; - Other named features already implemented: Sstvecd, Sstvala, Sscounterenw; - the new Svade named feature that was recently added. Most of the work is already done, so this patch is enough to implement the profile. After this patch, the 'rva22s64' user flag alone can be used with the rva64i CPU to boot Linux: -cpu rv64i,rva22s64=true This is the /proc/cpuinfo with this profile enabled: # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicbop_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zfhmin_zca_zcd_zba_zbb_zbs_zkt_svinval_svpbmt mmu : sv39 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-26-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add 'parent' in profile descriptionDaniel Henrique Barboza3-1/+15
Certain S-mode profiles, like RVA22S64 and RVA23S64, mandate all the mandatory extensions of their respective U-mode profiles. RVA22S64 includes all mandatory extensions of RVA22U64, and the same happens with RVA23 profiles. Add a 'parent' field to allow profiles to enable other profiles. This will allow us to describe S-mode profiles by specifying their parent U-mode profile, then adding just the S-mode specific extensions. We're naming the field 'parent' to consider the possibility of other uses (e.g. a s-mode profile including a previous s-mode profile) in the future. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-25-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add satp_mode profile supportDaniel Henrique Barboza3-0/+42
'satp_mode' is a requirement for supervisor profiles like RVA22S64. User-mode/application profiles like RVA22U64 doesn't care. Add 'satp_mode' to the profile description. If a profile requires it, set it during cpu_set_profile(). We'll also check it during finalize() to validate if the running config implements the profile. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-24-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/cpu.c: add riscv_cpu_is_32bit()Daniel Henrique Barboza2-1/+7
Next patch will need to retrieve if a given RISCVCPU is 32 or 64 bit. The existing helper riscv_is_32bit() (hw/riscv/boot.c) will always check the first CPU of a given hart array, not any given CPU. Create a helper to retrieve the info for any given CPU, not the first CPU of the hart array. The helper is using the same 32 bit check that riscv_cpu_satp_mode_finalize() was doing. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-23-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/cpu.c: finalize satp_mode earlierDaniel Henrique Barboza1-8/+8
Profiles will need to validate satp_mode during their own finalize methods. This will occur inside riscv_tcg_cpu_finalize_features() for TCG. Given that satp_mode does not have any pre-req from the accelerator finalize() method, it's safe to finalize it earlier. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-22-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add priv ver restriction to profilesDaniel Henrique Barboza3-0/+34
Some profiles, like RVA22S64, has a priv_spec requirement. Make this requirement explicit for all profiles. We'll validate this requirement finalize() time and, in case the user chooses an incompatible priv_spec while activating a profile, a warning will be shown. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: implement svadeDaniel Henrique Barboza3-0/+7
'svade' is a RVA22S64 profile requirement, a profile we're going to add shortly. It is a named feature (i.e. not a formal extension, not defined in riscv,isa DT at this moment) defined in [1] as: "Page-fault exceptions are raised when a page is accessed when A bit is clear, or written when D bit is clear.". As far as the spec goes, 'svade' is one of the two distinct modes of handling PTE_A and PTE_D. The other way, i.e. update PTE_A/PTE_D when they're cleared, is defined by the 'svadu' extension. Checking cpu_helper.c, get_physical_address(), we can verify that QEMU is compliant with that: we will update PTE_A/PTE_D if 'svadu' is enabled, or throw a page-fault exception if 'svadu' isn't enabled. So, as far as we're concerned, 'svade' translates to 'svadu must be disabled'. We'll implement it like 'zic64b': an internal flag that profiles can enable. The flag will not be exposed to users. [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add 'rva22u64' CPUDaniel Henrique Barboza3-0/+27
This CPU was suggested by Alistair [1] and others during the profile design discussions. It consists of the bare 'rv64i' CPU with rva22u64 enabled by default, like an alias of '-cpu rv64i,rva22u64=true'. Users now have an even easier way of consuming this user-mode profile by doing '-cpu rva22u64'. Extensions can be enabled/disabled at will on top of it. We can boot Linux with this "user-mode" CPU by doing: -cpu rva22u64,sv39=true,s=true,zifencei=true [1] https://lore.kernel.org/qemu-riscv/CAKmqyKP7xzZ9Sx=-Lbx2Ob0qCfB7Z+JO944FQ2TQ+49mqo0q_Q@mail.gmail.com/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10riscv-qmp-cmds.c: add profile flags in cpu-model-expansionDaniel Henrique Barboza1-0/+14
Expose all profile flags for all CPUs when executing query-cpu-model-expansion. This will allow callers to quickly determine if a certain profile is implemented by a given CPU. This includes vendor CPUs - the fact that they don't have profile user flags doesn't mean that they don't implement the profile. After this change it's possible to quickly determine if our stock CPUs implement the existing rva22u64 profile. Here's a few examples: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp tcp:localhost:1234,server,wait=off $ ./scripts/qmp/qmp-shell localhost:1234 Welcome to the QMP low-level shell! Connected to QEMU 8.1.50 - As expected, the 'max' CPU implements the rva22u64 profile. (QEMU) query-cpu-model-expansion type=full model={"name":"max"} {"return": {"model": {"name": "rv64", "props": {... "rva22u64": true, ...}}}} - rv64 is missing "zba", "zbb", "zbs", "zkt" and "zfhmin": query-cpu-model-expansion type=full model={"name":"rv64"} {"return": {"model": {"name": "rv64", "props": {... "rva22u64": false, ...}}}} query-cpu-model-expansion type=full model={"name":"rv64", "props":{"zba":true,"zbb":true,"zbs":true,"zkt":true,"zfhmin":true}} {"return": {"model": {"name": "rv64", "props": {... "rva22u64": true, ...}}}} We have no vendor CPUs that supports rva22u64 (veyron-v1 is the closest - it is missing just 'zkt'). In short, aside from the 'max' CPU, we have no CPUs that supports rva22u64 by default. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: validate profiles during finalizeDaniel Henrique Barboza1-0/+69
Enabling a profile and then disabling some of its mandatory extensions is a valid use. It can be useful for debugging and testing. But the common expected use of enabling a profile is to enable all its mandatory extensions. Add an user warning when mandatory extensions from an enabled profile are disabled in the command line. We're also going to disable the profile flag in this case since the profile must include all the mandatory extensions. This flag can be exposed by QMP to indicate the actual profile state after the CPU is realized. After this patch, this will throw warnings: -cpu rv64,rva22u64=true,zihintpause=false,zicbom=false,zicboz=false qemu-system-riscv64: warning: Profile rva22u64 mandates disabled extension zihintpause qemu-system-riscv64: warning: Profile rva22u64 mandates disabled extension zicbom qemu-system-riscv64: warning: Profile rva22u64 mandates disabled extension zicboz Note that the following will NOT throw warnings because the profile is being enabled last, hence all its mandatory extensions will be enabled: -cpu rv64,zihintpause=false,zicbom=false,zicboz=false,rva22u64=true Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-17-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: honor user choice for G MISA bitsDaniel Henrique Barboza1-25/+48
RVG behaves like a profile: a single flag enables a set of bits. Right now we're considering user choice when handling RVG and zicsr/zifencei and ignoring user choice on MISA bits. We'll add user warnings for profiles when the user disables its mandatory extensions in the next patch. We'll do the same thing with RVG now to keep consistency between RVG and profile handling. First and foremost, create a new RVG only helper to avoid clogging riscv_cpu_validate_set_extensions(). We do not want to annoy users with RVG warnings like we did in the past (see 9b9741c38f), thus we'll only warn if RVG was user set and the user disabled a RVG extension in the command line. For every RVG MISA bit (IMAFD), zicsr and zifencei, the logic then becomes: - if enabled, do nothing; - if disabled and not user set, enable it; - if disabled and user set, throw a warning that it's a RVG mandatory extension. This same logic will be used for profiles in the next patch. Note that this is a behavior change, where we would error out if the user disabled either zicsr or zifencei. As long as users are explicitly disabling things in the command line we'll let them have a go at it, at least in this step. We'll error out later in the validation if needed. Other notable changes from the previous RVG code: - use riscv_cpu_write_misa_bit() instead of manually updating both env->misa_ext and env->misa_ext_mask; - set zicsr and zifencei directly. We're already checking if they were user set and priv version will never fail for these extensions, making cpu_cfg_ext_auto_update() redundant. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-16-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: add hash table insert helpersDaniel Henrique Barboza1-12/+16
Previous patches added several g_hash_table_insert() patterns. Add two helpers, one for each user hash, to make the code cleaner. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: handle profile MISA bitsDaniel Henrique Barboza1-0/+21
The profile support is handling multi-letter extensions only. Let's add support for MISA bits as well. We'll go through every known MISA bit. If the profile doesn't declare the bit as mandatory, ignore it. Otherwise, set the bit in env->misa_ext and env->misa_ext_mask. Now that we're setting profile MISA bits, one can use the rv64i CPU to boot Linux using the following options: -cpu rv64i,rva22u64=true,rv39=true,s=true,zifencei=true In the near future, when rva22s64 (where, 's', 'zifencei' and sv39 are mandatory), is implemented, rv64i will be able to boot Linux loading rva22s64 and no additional flags. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: add riscv_cpu_write_misa_bit()Daniel Henrique Barboza1-14/+18
We have two instances of the setting/clearing a MISA bit from env->misa_ext and env->misa_ext_mask pattern. And the next patch will end up adding one more. Create a helper to avoid code repetition. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: add MISA user options hashDaniel Henrique Barboza1-1/+14
We already track user choice for multi-letter extensions because we needed to honor user choice when enabling/disabling extensions during realize(). We refrained from adding the same mechanism for MISA extensions since we didn't need it. Profile support requires tne need to check for user choice for MISA extensions, so let's add the corresponding hash now. It works like the existing multi-letter hash (multi_ext_user_opts) but tracking MISA bits options in the cpu_set_misa_ext_cfg() callback. Note that we can't re-use the same hash from multi-letter extensions because that hash uses cpu->cfg offsets as keys, while for MISA extensions we're using MISA bits as keys. After adding the user hash in cpu_set_misa_ext_cfg(), setting default values with object_property_set_bool() in add_misa_properties() will end up marking the user choice hash with them. Set the default value manually to avoid it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: add user flag for profile supportDaniel Henrique Barboza1-0/+80
The TCG emulation implements all the extensions described in the RVA22U64 profile, both mandatory and optional. The mandatory extensions will be enabled via the profile flag. We'll leave the optional extensions to be enabled by hand. Given that this is the first profile we're implementing in TCG we'll need some ground work first: - all profiles declared in riscv_profiles[] will be exposed to users. TCG is the main accelerator we're considering when adding profile support in QEMU, so for now it's safe to assume that all profiles in riscv_profiles[] will be relevant to TCG; - we'll not support user profile settings for vendor CPUs. The flags will still be exposed but users won't be able to change them; - profile support, albeit available for all non-vendor CPUs, will be based on top of the new 'rv64i' CPU. Setting a profile to 'true' means enable all mandatory extensions of this profile, setting it to 'false' will disable all mandatory profile extensions of the CPU, which will obliterate preset defaults. This is not a problem for a bare CPU like rv64i but it can allow for silly scenarios when using other CPUs. E.g. an user can do "-cpu rv64,rva22u64=false" and have a bunch of default rv64 extensions disabled. The recommended way of using profiles is the rv64i CPU, but users are free to experiment. For now we'll handle multi-letter extensions only. MISA extensions need additional steps that we'll take care later. At this point we can boot a Linux buildroot using rva22u64 using the following options: -cpu rv64i,rva22u64=true,sv39=true,g=true,c=true,s=true Note that being an usermode/application profile we still need to explicitly set 's=true' to enable Supervisor mode to boot Linux. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: add 'rva22u64' flag as unavailableDaniel Henrique Barboza1-1/+6
KVM does not have the means to support enabling the rva22u64 profile. The main reasons are: - we're missing support for some mandatory rva22u64 extensions in the KVM module; - we can't make promises about enabling a profile since it all depends on host support in the end. We'll revisit this decision in the future if needed. For now mark the 'rva22u64' profile as unavailable when running a KVM CPU: $ qemu-system-riscv64 -machine virt,accel=kvm -cpu rv64,rva22u64=true qemu-system-riscv64: can't apply global rv64-riscv-cpu.rva22u64=true: 'rva22u64' is not available with KVM Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add rva22u64 profile definitionDaniel Henrique Barboza2-0/+44
The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10riscv-qmp-cmds.c: expose named features in cpu_model_expansionDaniel Henrique Barboza1-5/+25
Named features (zic64b the sole example at this moment) aren't expose to users, thus we need another way to expose them. Go through each named feature, get its boolean value, do the needed conversions (bool to qbool, qbool to QObject) and add it to output dict. Another adjustment is needed: named features are evaluated during finalize(), so riscv_cpu_finalize_features() needs to be mandatory regardless of whether we have an input dict or not. Otherwise zic64b will always return 'false', which is incorrect: the default values of cache blocksizes ([cbom/cbop/cboz]_blocksize) are set to 64, satisfying the conditions for zic64b. Here's an API usage example after this patch: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp tcp:localhost:1234,server,wait=off $ ./scripts/qmp/qmp-shell localhost:1234 Welcome to the QMP low-level shell! Connected to QEMU 8.1.50 (QEMU) query-cpu-model-expansion type=full model={"name":"rv64"} {"return": {"model": {"name": "rv64", "props": {... "zic64b": true, ...}}}} zic64b is set to 'true', as expected, since all cache sizes are 64 bytes by default. If we change one of the cache blocksizes, zic64b is returned as 'false': (QEMU) query-cpu-model-expansion type=full model={"name":"rv64","props":{"cbom_blocksize":128}} {"return": {"model": {"name": "rv64", "props": {... "zic64b": false, ...}}}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: add 'zic64b' supportDaniel Henrique Barboza4-0/+34
zic64b is defined in the RVA22U64 profile [1] as a named feature for "Cache blocks must be 64 bytes in size, naturally aligned in the address space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64 profile mandates this feature, meaning that applications using this profile expects 64 bytes cache blocks. To make the upcoming RVA22U64 implementation complete, we'll zic64b as a 'named feature', not a regular extension. This means that: - it won't be exposed to users; - it won't be written in riscv,isa. This will be extended to other named extensions in the future, so we're creating some common boilerplate for them as well. zic64b is default to 'true' since we're already using 64 bytes blocks. If any cache block size (cbo{m,p,z}_blocksize) is changed to something different than 64, zic64b is set to 'false'. Our profile implementation will then be able to check the current state of zic64b and take the appropriate action (e.g. throw a warning). [1] https://github.com/riscv/riscv-profiles/releases/download/v1.0/profiles.pdf Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add zicbop extension flagDaniel Henrique Barboza3-0/+10
QEMU already implements zicbom (Cache Block Management Operations) and zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for what would be the instructions for zicbop (Cache Block Prefetch Operations), which are now no-ops. The RVA22U64 profile mandates zicbop, which means that applications that run with this profile might expect zicbop to be present in the riscv,isa DT and might behave badly if it's absent. Adding zicbop as an extension will make our future RVA22U64 implementation more in line with what userspace expects and, if/when cache block prefetch operations became relevant to QEMU, we already have the extension flag to turn then on/off as needed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add rv64i CPUDaniel Henrique Barboza2-0/+48
We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: update priv_ver on user_set extensionsDaniel Henrique Barboza1-0/+32
We'll add a new bare CPU type that won't have any default priv_ver. This means that the CPU will default to priv_ver = 0, i.e. 1.10.0. At the same we'll allow these CPUs to enable extensions at will, but then, if the extension has a priv_ver newer than 1.10, we'll end up disabling it. Users will then need to manually set priv_ver to something other than 1.10 to enable the extensions they want, which is not ideal. Change the setter() of extensions to allow user enabled extensions to bump the priv_ver of the CPU. This will make it convenient for users to enable extensions for CPUs that doesn't set a default priv_ver. This change does not affect any existing CPU: vendor CPUs does not allow extensions to be enabled, and generic CPUs are already set to priv_ver LATEST. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>