aboutsummaryrefslogtreecommitdiff
path: root/target/riscv
AgeCommit message (Collapse)Author
2023-11-07target/riscv: Add cfg property for Zvkt extensionMax Chou
Vector crypto spec defines the Zvkt extension that included all of the instructions of Zvbb & Zvbc extensions and some vector instructions. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: correct csr_ops[CSR_MSECCFG]Heinrich Schuchardt
The CSR register mseccfg is used by multiple extensions: Smepm and Zkr. Consider this when checking the existence of the register. Fixes: 77442380ecbe ("target/riscv: rvk: add CSR support for Zkr") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231030102105.19501-1-heinrich.schuchardt@canonical.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm: add zicsr, zifencei, zba, zbs, svnapotDaniel Henrique Barboza
These regs were added in Linux 6.6. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031205150.208405-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm: add zihpm regDaniel Henrique Barboza
Add zihpm support in the KVM driver now that QEMU supports it. This reg was added in Linux 6.6. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: add zihpm extension flag for TCGDaniel Henrique Barboza
zihpm is the Hardware Performance Counters extension described in chapter 12 of the unprivileged spec. It describes support for 29 unprivileged performance counters, hpmcounter3-hpmcounter31. As with zicntr, QEMU already implements zihpm before it was even an extension. zihpm is also part of the RVA22 profile, so add it to QEMU to complement the future profile implementation. Default it to 'true' for all existing CPUs since it was always present in the code. As for disabling it, there is already code in place in target/riscv/csr.c in all predicates for these counters (ctr() and mctr()) that disables them if cpu->cfg.pmu_num is zero. Thus, setting cpu->cfg.pmu_num to zero if 'zihpm=false' is enough to disable the extension. Set cpu->pmu_avail_ctrs mask to zero as well since this is also checked to verify if the counters exist. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm: add zicntr regDaniel Henrique Barboza
Add zicntr support in the KVM driver now that QEMU supports it. This reg was added in Linux 6.6. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: add zicntr extension flag for TCGDaniel Henrique Barboza
zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it in TCG way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the future profile implementation flag complete. Given than it represents an already existing feature, default it to 'true' for all CPUs. For TCG, we need a way to disable zicntr if the user wants to. This is done by restricting access to the CYCLE, TIME, and INSTRET counters via the 'ctr()' predicate when we're about to access them. Disabling zicntr happens via the command line or if its dependency, zicsr, happens to be disabled. We'll check for zicsr during realize() and, in case it's absent, disable zicntr. However, if the user was explicit about having zicntr support, error out instead of disabling it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: pmp: Ignore writes when RW=01Mayuresh Chitale
As per the Priv spec: "The R, W, and X fields form a collective WARL field for which the combinations with R=0 and W=1 are reserved." However currently such writes are not ignored as ought to be. The combinations with RW=01 are allowed only when the Smepmp extension is enabled and mseccfg.MML is set. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065705.1431868-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: pmp: Clear pmp/smepmp bits on resetMayuresh Chitale
As per the Priv and Smepmp specifications, certain bits such as the 'L' bit of pmp entries and mseccfg.MML can only be cleared upon reset and it is necessary to do so to allow 'M' mode firmware to correctly reinitialize the pmp/smpemp state across reboots. As required by the spec, also clear the 'A' field of pmp entries. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065644.1431798-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07Add epmp to extensions list and rename it to smepmpHimanshu Chauhan
Smepmp is a ratified extension which qemu refers to as epmp. Rename epmp to smepmp and add it to extension list so that it is added to the isa string. Signed-off-by: Himanshu Chauhan <hchauhan@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065546.1431579-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/riscv-qmp-cmds.c: check CPU accel in query-cpu-model-expansionDaniel Henrique Barboza
Use the recently added riscv_cpu_accelerator_compatible() to filter unavailable CPUs for a given accelerator. At this moment this is the case for a QEMU built with KVM and TCG support querying a binary running with TCG: qemu-system-riscv64 -S -M virt,accel=tcg -display none -qmp tcp:localhost:1234,server,wait=off ./qemu/scripts/qmp/qmp-shell localhost:1234 (QEMU) query-cpu-model-expansion type=full model={"name":"host"} {"error": {"class": "GenericError", "desc": "'host' CPU not available with tcg"}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: add riscv_cpu_accelerator_compatible()Daniel Henrique Barboza
Add an API to check if a given CPU is compatible with the current accelerator. This will allow query-cpu-model-expansion to work properly in conditions where QEMU supports both accelerators (TCG and KVM), QEMU is then launched using TCG, and the API requests information about a KVM only CPU (e.g. 'host' CPU). KVM doesn't have such restrictions and, at least in theory, all CPUs models should work with KVM. We will revisit this API in case we decide to restrict the amount of KVM CPUs we support. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: handle custom props in qmp_query_cpu_model_expansionDaniel Henrique Barboza
Callers can add 'props' when querying for a cpu model expansion to see if a given CPU model supports a certain criteria, and what's the resulting CPU object. If we have 'props' to handle, gather it in a QDict and use the new riscv_cpuobj_validate_qdict_in() helper to validate it. This helper will add the custom properties in the CPU object and validate it using riscv_cpu_finalize_features(). Users will be aware of validation errors if any occur, if not a CPU object with 'props' will be returned. Here's an example with the veyron-v1 vendor CPU. Disabling vendor CPU extensions is allowed, assuming the final config is valid. Disabling 'smstateen' is a valid expansion: (QEMU) query-cpu-model-expansion type=full model={"name":"veyron-v1","props":{"smstateen":false}} {"return": {"model": {"name": "veyron-v1", "props": {"zicond": false, ..., "smstateen": false, ...} But enabling extensions isn't allowed for vendor CPUs. E.g. enabling 'V' for the veyron-v1 CPU isn't allowed: (QEMU) query-cpu-model-expansion type=full model={"name":"veyron-v1","props":{"v":true}} {"error": {"class": "GenericError", "desc": "'veyron-v1' CPU does not allow enabling extensions"}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/tcg: add tcg_cpu_finalize_features()Daniel Henrique Barboza
The query-cpu-model-expansion API is capable of passing extra properties to a given CPU model and tell callers if this custom configuration is valid. The RISC-V version of the API is not quite there yet. The reason is the realize() flow in the TCG driver, where most of the validation is done in tcg_cpu_realizefn(). riscv_cpu_finalize_features() is then used to validate satp_mode for both TCG and KVM CPUs. Our ARM friends uses a concept of 'finalize_features()', a step done in the end of realize() where the CPU features are validated. We have a riscv_cpu_finalize_features() helper that, at this moment, is only validating satp_mode. Re-use this existing helper to do all CPU extension validation we required after at the end of realize(). Make it public to allow APIs to use it. At this moment only the TCG driver requires a realize() time validation, thus, to avoid adding accelerator specific helpers in the API, riscv_cpu_finalize_features() uses riscv_tcg_cpu_finalize_features() if we are running TCG. The API will then use riscv_cpu_finalize_features() regardless of the current accelerator. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07qapi,risc-v: add query-cpu-model-expansionDaniel Henrique Barboza
This API is used to inspect the characteristics of a given CPU model. It also allows users to validate a CPU model with a certain configuration, e.g. if "-cpu X,a=true,b=false" is a valid setup for a given QEMU binary. We'll start implementing the first part. The second requires more changes in RISC-V CPU boot flow. The implementation is inspired by the existing ARM query-cpu-model-expansion impl in target/arm/arm-qmp-cmds.c. We'll create a RISCVCPU object with the required model, fetch its existing properties, add a couple of relevant boolean options (pmp and mmu) and display it to users. Here's an usage example: ./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": {"zicond": false, "x-zvfh": false, "mmu": true, "x-zvfbfwma": false, "x-zvfbfmin": false, "xtheadbs": false, "xtheadbb": false, "xtheadba": false, "xtheadmemidx": false, "smstateen": false, "zfinx": false, "Zve64f": false, "Zve32f": false, "x-zvfhmin": false, "xventanacondops": false, "xtheadcondmov": false, "svpbmt": false, "zbs": true, "zbc": true, "zbb": true, "zba": true, "zicboz": true, "xtheadmac": false, "Zfh": false, "Zfa": true, "zbkx": false, "zbkc": false, "zbkb": false, "Zve64d": false, "x-zfbfmin": false, "zk": false, "x-epmp": false, "xtheadmempair": false, "zkt": false, "zks": false, "zkr": false, "zkn": false, "Zfhmin": false, "zksh": false, "zknh": false, "zkne": false, "zknd": false, "zhinx": false, "Zicsr": true, "sscofpmf": false, "Zihintntl": true, "sstc": true, "xtheadcmo": false, "x-zvbb": false, "zksed": false, "x-zvkned": false, "xtheadsync": false, "x-zvkg": false, "zhinxmin": false, "svadu": true, "xtheadfmv": false, "x-zvksed": false, "svnapot": false, "pmp": true, "x-zvknhb": false, "x-zvknha": false, "xtheadfmemidx": false, "x-zvksh": false, "zdinx": false, "zicbom": true, "Zihintpause": true, "svinval": false, "zcf": false, "zce": false, "zcd": false, "zcb": false, "zca": false, "x-ssaia": false, "x-smaia": false, "zmmul": false, "x-zvbc": false, "Zifencei": true, "zcmt": false, "zcmp": false, "Zawrs": true}}}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm/kvm-cpu.c: add missing property getters()Daniel Henrique Barboza
We got along without property getters in the KVM driver because we never needed them. But the incoming query-cpu-model-expansion API will use property getters and setters to retrieve the CPU characteristics. Add the missing getters for the KVM driver for both MISA and multi-letter extension properties. We're also adding an special getter for absent multi-letter properties that KVM doesn't implement that always return false. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add HS-mode virtual interrupt and IRQ filtering support.Rajnesh Kanwal
This change adds support for inserting virtual interrupts from HS-mode into VS-mode using hvien and hvip csrs. This also allows for IRQ filtering from HS-mode. Also, the spec doesn't mandate the interrupt to be actually supported in hardware. Which allows HS-mode to assert virtual interrupts to VS-mode that have no connection to any real interrupt events. This is defined as part of the AIA specification [0], "6.3.2 Virtual interrupts for VS level". [0]: https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231016111736.28721-7-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add M-mode virtual interrupt and IRQ filtering support.Rajnesh Kanwal
This change adds support for inserting virtual interrupts from M-mode into S-mode using mvien and mvip csrs. IRQ filtering is a use case of this change, i-e M-mode can stop delegating an interrupt to S-mode and instead enable it in MIE and receive those interrupts in M-mode and then selectively inject the interrupt using mvien and mvip. Also, the spec doesn't mandate the interrupt to be actually supported in hardware. Which allows M-mode to assert virtual interrupts to S-mode that have no connection to any real interrupt events. This is defined as part of the AIA specification [0], "5.3 Interrupt filtering and virtual interrupts for supervisor level". [0]: https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231016111736.28721-6-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Split interrupt logic from riscv_cpu_update_mip.Rajnesh Kanwal
This is to allow virtual interrupts to be inserted into S and VS modes. Given virtual interrupts will be maintained in separate mvip and hvip CSRs, riscv_cpu_update_mip will no longer be in the path and interrupts need to be triggered for these cases from rmw_hvip64 and rmw_mvip64 functions. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-5-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Set VS* bits to one in mideleg when H-Ext is enabledRajnesh Kanwal
With H-Ext supported, VS bits are all hardwired to one in MIDELEG denoting always delegated interrupts. This is being done in rmw_mideleg but given mideleg is used in other places when routing interrupts this change initializes it in riscv_cpu_realize to be on the safe side. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-4-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Check for async flag in case of RISCV_EXCP_SEMIHOST.Rajnesh Kanwal
RISCV_EXCP_SEMIHOST is set to 0x10, which can be a local interrupt id as well. This change moves RISCV_EXCP_SEMIHOST to switch case so that async flag check is performed before invoking semihosting logic. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-3-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Without H-mode mask all HS mode inturrupts in mie.Rajnesh Kanwal
Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-2-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: rename ext_icboz to ext_zicbozDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zicboz they're more likely to do 'grep -i zicboz' than 'grep -i icboz'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231012164604.398496-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: rename ext_icbom to ext_zicbomDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zicbom they're more likely to do 'grep -i zicbom' than 'grep -i icbom'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231012164604.398496-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: rename ext_icsr to ext_zicsrDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: rename ext_ifencei to ext_zifenceiDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-25kvm: require KVM_IRQFD for kernel irqchipPaolo Bonzini
KVM_IRQFD was introduced in Linux 2.6.32, and since then it has always been available on architectures that support an in-kernel interrupt controller. We can require it unconditionally. Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-12target/riscv: Fix vfwmaccbf16.vfMax Chou
The operator (fwmacc16) of vfwmaccbf16.vf helper function should be replaced by fwmaccbf16. Fixes: adf772b0f7 ("target/riscv: Add support for Zvfbfwma extension") Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231005095734.567575-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: deprecate capital 'Z' CPU propertiesDaniel Henrique Barboza
At this moment there are eleven CPU extension properties that starts with capital 'Z': Zifencei, Zicsr, Zihintntl, Zihintpause, Zawrs, Zfa, Zfh, Zfhmin, Zve32f, Zve64f and Zve64d. All other extensions are named with lower-case letters. We want all properties to be named with lower-case letters since it's consistent with the riscv-isa string that we create in the FDT. Having these 11 properties to be exceptions can be confusing. Deprecate all of them. Create their lower-case counterpart to be used as maintained CPU properties. When trying to use any deprecated property a warning message will be displayed, recommending users to switch to the lower-case variant: ./build/qemu-system-riscv64 -M virt -cpu rv64,Zifencei=true --nographic qemu-system-riscv64: warning: CPU property 'Zifencei' is deprecated. Please use 'zifencei' instead This will give users some time to change their scripts before we remove the capital 'Z' properties entirely. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231009112817.8896-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: Use env_archcpu for better performanceRichard W.M. Jones
RISCV_CPU(cs) uses a checked cast. When QOM cast debugging is enabled this adds about 5% total overhead when emulating RV64 on x86-64 host. Using a RISC-V guest with 16 vCPUs, 16 GB of guest RAM, virtio-blk disk. The guest has a copy of the qemu source tree. The test involves compiling the qemu source tree with 'make clean; time make -j16'. Before making this change the compile step took 449 & 447 seconds over two consecutive runs. After making this change: 428 & 421 seconds. The saving is over 5%. Thanks: Paolo Bonzini Thanks: Philippe Mathieu-Daudé Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231009124859.3373696-2-rjones@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/tcg: remove RVG warningDaniel Henrique Barboza
Vendor CPUs that set RVG are displaying user warnings about other extensions that RVG must enable, one warning per CPU. E.g.: $ ./build/qemu-system-riscv64 -smp 8 -M virt -cpu veyron-v1 -nographic qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei qemu-system-riscv64: warning: Setting G will also set IMAFD_Zicsr_Zifencei This happens because we decided a while ago that, for simplicity, vendor CPUs could set RVG instead of setting each G extension individually in their cpu_init(). Our warning isn't taking that into account, and we're bugging users with a warning that we're causing ourselves. In a closer look we conclude that this warning is not warranted in any other circumstance since we're just following the ISA [1], which states in chapter 24: "One goal of the RISC-V project is that it be used as a stable software development target. For this purpose, we define a combination of a base ISA (RV32I or RV64I) plus selected standard extensions (IMAFD, Zicsr, Zifencei) as a 'general-purpose' ISA, and we use the abbreviation G for the IMAFDZicsr Zifencei combination of instruction-set extensions." With this in mind, enabling IMAFD_Zicsr_Zifencei if the user explicitly enables 'G' is an expected behavior and the warning is unneeded. Any user caught by surprise should refer to the ISA. Remove the warning when handling RVG. [1] https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf Reported-by: Paul A. Clarke <pclarke@ventanamicro.com> Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231003122539.775932-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/kvm: support KVM_GET_REG_LISTDaniel Henrique Barboza
KVM for RISC-V started supporting KVM_GET_REG_LIST in Linux 6.6. It consists of a KVM ioctl() that retrieves a list of all available regs for get_one_reg/set_one_reg. Regs that aren't present in the list aren't supported in the host. This simplifies our lives when initing the KVM regs since we don't have to always attempt a KVM_GET_ONE_REG for all regs QEMU knows. We'll only attempt a get_one_reg() if we're sure the reg is supported, i.e. it was retrieved by KVM_GET_REG_LIST. Any error in get_one_reg() will then always considered fatal, instead of having to handle special error codes that might indicate a non-fatal failure. Start by moving the current kvm_riscv_init_multiext_cfg() logic into a new kvm_riscv_read_multiext_legacy() helper. We'll prioritize using KVM_GET_REG_LIST, so check if we have it available and, in case we don't, use the legacy() logic. Otherwise, retrieve the available reg list and use it to check if the host supports our known KVM regs, doing the usual get_one_reg() for the supported regs and setting cpu->cfg accordingly. 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: <20231003132148.797921-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/kvm: improve 'init_multiext_cfg' error msgDaniel Henrique Barboza
Our error message is returning the value of 'ret', which will be always -1 in case of error, and will not be that useful: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error -1 Improve the error message by outputting 'errno' instead of 'ret'. Use strerrorname_np() to output the error name instead of the error code. This will give us what we need to know right away: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error code: ENOENT Given that we're going to exit(1) in this condition instead of attempting to recover, remove the 'kvm_riscv_destroy_scratch_vcpu()' call. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231003132148.797921-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/tcg-cpu.c: add extension properties for all cpusDaniel Henrique Barboza
At this moment we do not expose extension properties for vendor CPUs because that would allow users to change them via command line. The drawback is that if we were to add an API that shows all CPU properties, e.g. qmp-query-cpu-model-expansion, we won't be able to show extensions state of vendor CPUs. We have the required machinery to create extension properties for vendor CPUs while not allowing users to enable extensions. Disabling existing extensions is allowed since it can be useful for debugging. Change the set() callback cpu_set_multi_ext_cfg() to allow enabling extensions only for generic CPUs. In cpu_add_multi_ext_prop() let's not set the default values for the properties if we're not dealing with generic CPUs, otherwise the values set in cpu_init() of vendor CPUs will be overwritten. And finally, in tcg_cpu_instance_init(), add cpu user properties for all CPUs. For the veyron-v1 CPU, we're now able to disable existing extensions like smstateen: $ ./build/qemu-system-riscv64 --nographic -M virt \ -cpu veyron-v1,smstateen=false But setting extensions that the CPU didn't set during cpu_init(), like V, is not allowed: $ ./build/qemu-system-riscv64 --nographic -M virt \ -cpu veyron-v1,v=true qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.v=true: 'veyron-v1' CPU does not allow enabling extensions Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230926183109.165878-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: add riscv_cpu_get_name()Daniel Henrique Barboza
We'll introduce generic errors that will output a CPU type name via its RISCVCPU pointer. Create a helper for that. Use the helper in tcg_cpu_realizefn() instead of hardcoding the 'host' CPU name. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230926183109.165878-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu: move priv spec functions to tcg-cpu.cDaniel Henrique Barboza
Priv spec validation is TCG specific. Move it to the TCG accel class. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230925175709.35696-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: export isa_edata_arr[]Daniel Henrique Barboza
This array will be read by the TCG accel class, allowing it to handle priv spec verifications on its own. The array will remain here in cpu.c because it's also used by the riscv,isa string function. To export it we'll finish it with an empty element since ARRAY_SIZE() won't work outside of cpu.c. Get rid of its ARRAY_SIZE() usage now to alleviate the changes for the next patch. 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: <20230925175709.35696-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/tcg: move riscv_cpu_add_misa_properties() to tcg-cpu.cDaniel Henrique Barboza
All code related to MISA TCG properties is also moved. At this point, all TCG properties handling is done in tcg-cpu.c, all KVM properties handling is done in kvm-cpu.c. 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: <20230925175709.35696-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: make misa_ext_cfgs[] 'const'Daniel Henrique Barboza
The array isn't marked as 'const' because we're initializing their elements in riscv_cpu_add_misa_properties(), 'name' and 'description' fields. In a closer look we can see that we're not using these 2 fields after creating the MISA properties. And we can create the properties by using riscv_get_misa_ext_name() and riscv_get_misa_ext_description() directly. Remove the 'name' and 'description' fields from RISCVCPUMisaExtConfig and make misa_ext_cfgs[] a const array. 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: <20230925175709.35696-17-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/tcg: introduce tcg_cpu_instance_init()Daniel Henrique Barboza
tcg_cpu_instance_init() will be the 'cpu_instance_init' impl for the TCG accelerator. It'll be called from within riscv_cpu_post_init(), via accel_cpu_instance_init(), similar to what happens with KVM. In fact, to preserve behavior, the implementation will be similar to what riscv_cpu_post_init() already does. In this patch we'll move riscv_cpu_add_user_properties() and riscv_init_max_cpu_extensions() and all their dependencies to tcg-cpu.c. All multi-extension properties code was moved. The 'multi_ext_user_opts' hash table was also moved to tcg-cpu.c since it's a TCG only structure, meaning that we won't have to worry about initializing a TCG hash table when running a KVM CPU anymore. riscv_cpu_add_user_properties() will remain in cpu.c for now due to how much code it requires to be moved at the same time. We'll do that in the next patch. 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: <20230925175709.35696-16-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: export set_misa()Daniel Henrique Barboza
We'll move riscv_init_max_cpu_extensions() to tcg-cpu.c in the next patch and set_misa() needs to be usable from there. Rename it to riscv_cpu_set_misa() and make it public. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/kvm: do not use riscv_cpu_add_misa_properties()Daniel Henrique Barboza
riscv_cpu_add_misa_properties() is being used to fill the missing KVM MISA properties but it is a TCG helper that was adapted to do so. We'll move it to tcg-cpu.c in the next patches, meaning that KVM needs to fill the remaining MISA properties on its own. Do not use riscv_cpu_add_misa_properties(). Let's create a new array with all available MISA bits we support that can be read by KVM. The array is zero terminate to allow us to iterate through it without knowing its size. Then, inside kvm_riscv_add_cpu_user_properties(), we'll create all KVM MISA properties as usual and then use this array to add any missing MISA properties with the riscv_cpu_add_kvm_unavail_prop() helper. Note that we're creating misa_bits[], and not using the existing 'riscv_single_letter_exts[]', because the latter is tuned for riscv,isa related functions and it doesn't have all MISA bits we support. Commit 0e2c377023 ("target/riscv: misa to ISA string conversion fix") has the full context. While we're at it, move both satp and the multi-letter extension properties to kvm_riscv_add_cpu_user_properties() as well. 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: <20230925175709.35696-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move KVM only files to kvm subdirDaniel Henrique Barboza
Move the files to a 'kvm' dir to promote more code separation between accelerators and making our lives easier supporting build options such as --disable-tcg. Rename kvm.c to kvm-cpu.c to keep it in line with its TCG counterpart. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: introduce KVM AccelCPUClassDaniel Henrique Barboza
Add a KVM accelerator class like we did with TCG. The difference is that, at least for now, we won't be using a realize() implementation for this accelerator. We'll start by assiging kvm_riscv_cpu_add_kvm_properties(), renamed to kvm_cpu_instance_init(), as a 'cpu_instance_init' implementation. Change riscv_cpu_post_init() to invoke accel_cpu_instance_init(), which will go through the 'cpu_instance_init' impl of the current acceleration (if available) and execute it. The end result is that the KVM initial setup, i.e. starting registers and adding its specific properties, will be done via this hook. Add a 'tcg_enabled()' condition in riscv_cpu_post_init() to avoid calling riscv_cpu_add_user_properties() when running KVM. We'll remove this condition when the TCG accel class get its own 'cpu_instance_init' implementation. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: remove kvm-stub.cDaniel Henrique Barboza
This file is not needed for some time now. Both kvm_riscv_reset_vcpu() and kvm_riscv_set_irq() have public declarations in kvm_riscv.h and are wrapped in 'if kvm_enabled()' blocks that the compiler will rip it out in non-KVM builds. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: make riscv_add_satp_mode_properties() publicDaniel Henrique Barboza
This function is used for both accelerators. Make it public, and call it from kvm_riscv_cpu_add_kvm_properties(). This will make it easier to split KVM specific code for the KVM accelerator class in the next patch. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move riscv_cpu_add_kvm_properties() to kvm.cDaniel Henrique Barboza
We'll introduce the KVM accelerator class with a 'cpu_instance_init' implementation that is going to be invoked during the common riscv_cpu_post_init() (via accel_cpu_instance_init()). This instance_init will execute KVM exclusive code that TCG doesn't care about, such as adding KVM specific properties, initing registers using a KVM scratch CPU and so on. The core of the forementioned cpu_instance_init impl is the current riscv_cpu_add_kvm_properties() that is being used by the common code via riscv_cpu_add_user_properties() in cpu.c. Move it to kvm.c, together will all the relevant artifacts, exporting and renaming it to kvm_riscv_cpu_add_kvm_properties() so cpu.c can keep using it for now. To make this work we'll need to export riscv_cpu_extensions, riscv_cpu_vendor_exts and riscv_cpu_experimental_exts from cpu.c as well. The TCG accelerator will also need to access those in the near future so this export will benefit us in the long run. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: mark extensions arrays as 'const'Daniel Henrique Barboza
We'll need to export these arrays to the accelerator classes in the next patches. Mark them as 'const' now because they should not be modified at runtime. Note that 'riscv_cpu_options' will also be exported, but can't be marked as 'const', because the properties are changed via qdev_property_add_static(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move 'host' CPU declaration to kvm.cDaniel Henrique Barboza
This CPU only exists if we're compiling with KVM so move it to the kvm specific file. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: add .instance_post_init()Daniel Henrique Barboza
All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU calls riscv_init_max_cpu_extensions(). Both can be moved to a common instance_post_init() callback, implemented in riscv_cpu_post_init(), called by all CPUs. The call order then becomes: riscv_cpu_init() -> cpu_init() of each CPU -> .instance_post_init() In the near future riscv_cpu_post_init() will call the init() function of the current accelerator, providing a hook for KVM and TCG accel classes to change the init() process of the CPU. 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: <20230925175709.35696-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>