Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 8 commits
- 7 files changed
- 6 contributors
Commits on Jul 19, 2023
-
docs/system/target-riscv.rst: tidy CPU firmware section
This is how the content of the "RISC-V CPU firmware" section is displayed after the html is generated: "When using the sifive_u or virt machine there are three different firmware boot options: 1. -bios default - This is the default behaviour if no -bios option is included. (...) 3. -bios <file> - Tells QEMU to load the specified file as the firmware." It's all in the same paragraph, in a numbered list, and no special formatting for the options. Tidy it a bit by adding line breaks between items and its description. Remove the numbered list. And apply formatting for the options cited in the middle of the text. Cc: qemu-trivial@nongnu.org Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230712143728.383528-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
-
riscv/disas: Fix disas output of upper immediates
The GNU assembler produces the following output for instructions with upper immediates: 00002597 auipc a1,0x2 000024b7 lui s1,0x2 6409 lui s0,0x2 # c.lui The immediate operands of upper immediates are not shifted. However, the QEMU disassembler prints them shifted: 00002597 auipc a1,8192 000024b7 lui s1,8192 6409 lui s0,8192 # c.lui The current implementation extracts the immediate bits and shifts the by 12, so the internal representation of the immediate is the actual immediate. However, the immediates are later printed using rv_fmt_rd_imm or rv_fmt_rd_offset, which don't undo the shift. Let's fix this by using specific output formats for instructions with upper immediates, that take care of the shift. Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230711075051.1531007-1-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> -
target/riscv/cpu.c: check priv_ver before auto-enable zca/zcd/zcf
Commit bd30559 made changes in how we're checking and disabling extensions based on env->priv_ver. One of the changes was to move the extension disablement code to the end of realize(), being able to disable extensions after we've auto-enabled some of them. An unfortunate side effect of this change started to happen with CPUs that has an older priv version, like sifive-u54. Starting on commit 2288a5c we're auto-enabling zca, zcd and zcf if RVC is enabled, but these extensions are priv version 1.12.0. When running a cpu that has an older priv ver (like sifive-u54) the user is spammed with warnings like these: qemu-system-riscv64: warning: disabling zca extension for hart 0x0000000000000000 because privilege spec version does not match qemu-system-riscv64: warning: disabling zcd extension for hart 0x0000000000000000 because privilege spec version does not match The warnings are part of the code that disables the extension, but in this case we're throwing user warnings for stuff that we enabled on our own, without user intervention. Users are left wondering what they did wrong. A quick 8.1 fix for this nuisance is to check the CPU priv spec before auto-enabling zca/zcd/zcf. A more appropriate fix will include a more robust framework that will account for both priv_ver and user choice when auto-enabling/disabling extensions, but for 8.1 we'll make it do with this simple check. It's also worth noticing that this is the only case where we're auto-enabling extensions based on a criteria (in this case RVC) that doesn't match the priv spec of the extensions we're enabling. There's no need for more 8.1 band-aids. Cc: Conor Dooley <conor@kernel.org> Fixes: 2288a5c ("target/riscv: add cfg properties for Zc* extension") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Tested-by: Conor Dooley <conor.dooley@microchip.com> Message-Id: <20230717154141.60898-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
-
hw/riscv: Fix typo field in error_report
"smp.cpus" means the number of online CPUs and "smp.max_cpus" means the total number of CPUs. riscv_numa_get_default_cpu_node_id() checks "smp.cpus" and the "available CPUs" description in the next error message also indicates online CPUs. So report "smp.cpus" in error_report() instand of "smp.max_cpus". Since "smp.cpus" is "unsigned int", use "%u". Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230718080712.503333-1-zhao1.liu@linux.intel.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
-
target/riscv: Fix LMUL check to use VLEN
The previous check was failing with: VLEN=128 ELEN = 64 SEW = 16 and LMUL = 1/8 which is a valid combination. Fix the check to allow valid combinations when VLEN is a multiple of ELEN. From the specification: "In general, the requirement is to support LMUL ≥ SEWMIN/ELEN, where SEWMIN is the narrowest supported SEW value and ELEN is the widest supported SEW value. In the standard extensions, SEWMIN=8. For standard vector extensions with ELEN=32, fractional LMULs of 1/2 and 1/4 must be supported. For standard vector extensions with ELEN=64, fractional LMULs of 1/2, 1/4, and 1/8 must be supported." Elsewhere in the specification it makes clear that VLEN>=ELEN. From inspection this new check allows: VLEN=ELEN=64 1/2, 1/4, 1/8 for SEW >=8 VLEN=ELEN=32 1/2, 1/4 for SEW >=8 Fixes: d9b7609 ("target/riscv: rvv-1.0: configure instructions") Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Message-Id: <20230718131316.12283-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
-
hw/nvme: fix endianness issue for shadow doorbells
In commit 2fda072 ("hw/nvme: fix missing endian conversions for doorbell buffers"), we fixed shadow doorbells for big-endian guests running on little endian hosts. But I did not fix little-endian guests on big-endian hosts. Fix this. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1765 Fixes: 3f7fe8d ("hw/nvme: Implement shadow doorbell buffer support") Cc: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Cédric Le Goater <clg@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
-
Merge tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu…
… into staging hw/nvme fixes * fix shadow doorbell endian issue # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmS3kkAACgkQTeGvMW1P # DenG1ggArIHi1dQQBIG1ubzHx/C+93cybpKwT73/5wfO7BT8CCh1v+qrH/6SsYUT # 5O7y1MaCLDV4ocf5dRQseXFK0tpjo7EqDnr25UhcSunQ+d2Tn7MAIuubQOFD+Axh # 5gIwOEJbKqw9apJgnVWnInTBd//ManOgh6OyC1uJ+DEJE7ISJzLlJeWaBekiWpAA # hNL1zsR5+eTcwnewDRmMs4FlKBlSfgcNgNYnz8tfpnW0DzXKuiY4ITnk6kX9eMAM # kDlbjFjlgoTPZ8IsYcyhVCJMcH8jqY/LuZcaF7XHHsdX7fa5p17C6rR1hxVyDs+E # rydOtWetQDhXlyakE+Jp2RB3HLcSmg== # =j1TL # -----END PGP SIGNATURE----- # gpg: Signature made Wed 19 Jul 2023 08:35:28 BST # gpg: using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9 # gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [full] # gpg: aka "Klaus Jensen <k.jensen@samsung.com>" [full] # Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838 # Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9 * tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu: hw/nvme: fix endianness issue for shadow doorbells Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
-
Merge tag 'pull-riscv-to-apply-20230719-1' of https://github.com/alis…
…tair23/qemu into staging Fourth RISC-V PR for 8.1 * Fix LMUL check to use VLEN * Fix typo field in NUMA error_report * check priv_ver before auto-enable zca/zcd/zcf * Fix disas output of upper immediates * tidy CPU firmware section # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmS3akMACgkQr3yVEwxT # gBPQ/BAArrieEkrRco3tIQJFZqTLfII28M0cYdwN+gjMAkL6RlauCh5yKkc+gsGy # bhhpr0AE+EzrjKfJgdyMQe2ZH08WEpoAfJHAmLTSm2ktgIlnDAjyJtVksZ3FSwfG # MRK3v0CChyOav3EfDZzK9jcaXeaSSfjCIG8JW3enoZxf2TnpoXlsCIQdRTnMw7Um # C73BWoOGOfixFehywHBnkkAPo/nkQPofELrRKNTlefAIsH1RcgYw+s3IgCIuYxJN # zCjM1y6ye1aiaQhKcNJiLoiP4Eq2R6vUuL8RKWkXqTP3QBZUqKMPnRVgI+W0qRAj # 9DS+l37zMdxytovQ4gmIqnENT8ty9bholOtWM8nI54subJBplQhkRednG3RBFYjH # hqbsakcHfE1lyyNI7WoBpO8UMtnOad6eBNmMOM48VduSdNuBZN3ksoRVomnJTlCY # nq1ZdteywHEZ3uBqk3k/4yzKH+jLj0McPz5FswxsMIGScVjd6H8rMYmM95r1He4k # YTJ8GwnOTBs1tFxOz5DaM3BVfq5hrzB0SbpDHMOdQHNXnqkyfvSd/QWeXfnY09Ux # kbNvSpzjn7wWRSP7s4KMcTmas4oGtPS2dheREB/gmoC1ubrfuhbzduDNXJt+omuC # GDcn9cpouyE/Vp/358PuEe1gW9GFMH0CbYBJ66P0hI/76iPfwLY= # =MOsI # -----END PGP SIGNATURE----- # gpg: Signature made Wed 19 Jul 2023 05:44:51 BST # gpg: using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6AE9 02B6 A7CA 877D 6D65 9296 AF7C 9513 0C53 8013 * tag 'pull-riscv-to-apply-20230719-1' of https://github.com/alistair23/qemu: target/riscv: Fix LMUL check to use VLEN hw/riscv: Fix typo field in error_report target/riscv/cpu.c: check priv_ver before auto-enable zca/zcd/zcf riscv/disas: Fix disas output of upper immediates docs/system/target-riscv.rst: tidy CPU firmware section Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 7a0adc3e05c2...76e6a2ca9e3b