Don't embed ibreak exception generation into TB and don't invalidate TB
on ibreak address change. Add CPUBreakpoint pointers to xtensa
CPUArchState, use cpu_breakpoint_insert/cpu_breakpoint_remove_by_ref to
manage ibreak breakpoints and provide TCGCPUOps::debug_check_breakpoint
callback that recognizes valid instruction breakpoints.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20231130171920.3798954-2-jcmvbkbc@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
'tcg_cflags' is specific to TCG.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20231130075958.21285-1-philmd@linaro.org>
There were some regressions introduced with Qemu v8.2 on the hppa/hppa64
target, e.g.:
- 32-bit HP-UX crashes on B160L (32-bit) machine
- NetBSD boot failure due to power button in page zero
- NetBSD FPU detection failure
- OpenBSD 7.4 boot failure
This patch series fixes those known regressions and additionally:
- allows usage of the max. 3840MB of memory (instead of 3GB),
- adds support for the qemu --nodefaults option (to debug other devices)
This patch set will not fix those known (non-regression) bugs:
- HP-UX and NetBSD still fail to boot on the new 64-bit C3700 machine
- Linux kernel will still fail to boot on C3700 as long as kernel modules are used.
Changes v2->v3:
- Added comment about Figures H-10 and H-11 in the parisc2.0 spec
in patch which calculate PDC address translation if PSW.W=0
- Introduce and use hppa_set_ior_and_isr()
- Use drive_get_max_bus(IF_SCSI), nd_table[] and serial_hd() to check
if default devices should be created
- Added Tested-by and Reviewed-by tags
Changes v1->v2:
- fix OpenBSD boot with SeaBIOS v15 instead of v14
- commit message enhancements suggested by BALATON Zoltan
- use uint64_t for ram_max in patch #1
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZaImPQAKCRD3ErUQojoP
X2C5AP9fbIkCni45JU6KC6OmFsCbAReRQCPwLO+MzR8/us2ywgD+PsGxSBk8ASxM
nqtv3J9JC3i+XSnbtwLV+qChnO+IXwc=
=FAMY
-----END PGP SIGNATURE-----
Merge tag 'hppa-fixes-8.2-pull-request' of https://github.com/hdeller/qemu-hppa into staging
target/hppa qemu v8.2 regression fixes
There were some regressions introduced with Qemu v8.2 on the hppa/hppa64
target, e.g.:
- 32-bit HP-UX crashes on B160L (32-bit) machine
- NetBSD boot failure due to power button in page zero
- NetBSD FPU detection failure
- OpenBSD 7.4 boot failure
This patch series fixes those known regressions and additionally:
- allows usage of the max. 3840MB of memory (instead of 3GB),
- adds support for the qemu --nodefaults option (to debug other devices)
This patch set will not fix those known (non-regression) bugs:
- HP-UX and NetBSD still fail to boot on the new 64-bit C3700 machine
- Linux kernel will still fail to boot on C3700 as long as kernel modules are used.
Changes v2->v3:
- Added comment about Figures H-10 and H-11 in the parisc2.0 spec
in patch which calculate PDC address translation if PSW.W=0
- Introduce and use hppa_set_ior_and_isr()
- Use drive_get_max_bus(IF_SCSI), nd_table[] and serial_hd() to check
if default devices should be created
- Added Tested-by and Reviewed-by tags
Changes v1->v2:
- fix OpenBSD boot with SeaBIOS v15 instead of v14
- commit message enhancements suggested by BALATON Zoltan
- use uint64_t for ram_max in patch #1
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZaImPQAKCRD3ErUQojoP
# X2C5AP9fbIkCni45JU6KC6OmFsCbAReRQCPwLO+MzR8/us2ywgD+PsGxSBk8ASxM
# nqtv3J9JC3i+XSnbtwLV+qChnO+IXwc=
# =FAMY
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 13 Jan 2024 05:57:17 GMT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'hppa-fixes-8.2-pull-request' of https://github.com/hdeller/qemu-hppa:
target/hppa: Update SeaBIOS-hppa to version 15
target/hppa: Fix IOR and ISR on error in probe
target/hppa: Fix IOR and ISR on unaligned access trap
target/hppa: Export function hppa_set_ior_and_isr()
target/hppa: Avoid accessing %gr0 when raising exception
hw/hppa: Move software power button address back into PDC
target/hppa: Fix PDC address translation on PA2.0 with PSW.W=0
hw/pci-host/astro: Add missing astro & elroy registers for NetBSD
hw/hppa/machine: Disable default devices with --nodefaults option
hw/hppa/machine: Allow up to 3840 MB total memory
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In arm_pamax(), we need to cope with the virt board calling this
function on a CPU object which has been inited but not realize.
We used to do propagation of feature-flag implications (such as
"V7VE implies LPAE") at realize, so we have some code in arm_pamax()
which manually checks for both V7VE and LPAE feature flags.
In commit b8f7959f28 we moved the feature propagation for
almost all features from realize to post-init. That means that
now when the virt board calls arm_pamax(), the feature propagation
has been done. So we can drop the manual propagation handling
and check only for the feature we actually care about, which
is ARM_FEATURE_LPAE.
Retain the comment that the virt board is calling this function
with a not completely realized CPU object, because that is a
potential beartrap for later changes which is worth calling out.
(Note that b8f7959f28 actually fixed a bug in the arm_pamax()
handling: arm_pamax() was missing a check for ARM_FEATURE_V8, so it
incorrectly thought that the qemu-system-arm 'max' CPU did not have
LPAE and turned off 'highmem' support in the virt board. Following
b8f7959f28 qemu-system-arm 'max' is treated the same as
'cortex-a15' and other v7 LPAE CPUs, because the generic feature
propagation code does correctly propagate V8 -> V7VE -> LPAE.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20240109143804.1118307-1-peter.maydell@linaro.org
Put correct values (depending on CPU arch) into IOR and ISR on fault.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Put correct values (depending on CPU arch) into IOR and ISR on fault.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Move functionality to set IOR and ISR on fault into own
function. This will be used by follow-up patches.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
The value of unwind_breg may reference register %r0, but we need to avoid
accessing gr0 directly and use the value 0 instead.
At runtime I've seen unwind_breg being zero with the Linux kernel when
rfi is used to jump to smp_callin().
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Bruno Haible <bruno@clisp.org>
Fix the address translation for PDC space on PA2.0 if PSW.W=0.
Basically, for any address in the 32-bit PDC range from 0xf0000000 to
0xf1000000 keep the lower 32-bits and just set the upper 32-bits to
0xfffffff0.
This mapping fixes the emulated power button in PDC space for 32- and
64-bit machines and is how the physical C3700 machine seems to map
PDC.
Figures H-10 and H-11 in the parisc2.0 spec [1] show that the 32-bit
region will be mapped somewhere into a higher and bigger 64-bit PDC
space. The start and end of this 64-bit space is defined by the
physical address bits. But the figures don't specifiy where exactly the
mapping will start inside that region. Tests on a real HP C3700
regarding the address of the power button indicate, that the lower
32-bits will stay the same though.
[1] https://parisc.wiki.kernel.org/images-parisc/7/73/Parisc2.0.pdf
Signed-off-by: Helge Deller <deller@gmx.de>
Tested-by: Bruno Haible <bruno@clisp.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
* Fix device presence checking in the virtio-ccw qtest
* Support codespell checking in checkpatch.pl
* Fix emulation of LAE s390x instruction
* Work around htags bug when environment is large
* Some other small clean-ups here and there
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmWgHlgRHHRodXRoQHJl
ZGhhdC5jb20ACgkQLtnXdP5wLbXAnBAAjQve/Jmfp9p8eQmswG7cl/a2TuJ59b9X
SFRja2PprV/Wp4kxxEJX4er9F2+rlMusNL62LBp/QjZi9u4lCvCmuB7sMa0wEkjr
BPPBrkxkAT+/8vhGpYg2GrxZv/UOLkycp3sjEp4v5yXWQw+OEBnkZZ+AuHddpnEr
NKMKss71uQmccvuzD5FMDfbJQcSBD/yGPyFfDrv1RKreYRlbkEDVlcVoZpfoMwQY
Pl167iDdmjVtsT+4wf8vHo5W/AYKDOjlV6AoujCnJVZnGx6BtDLiF/iNJ/VU1Ty5
cRxySPT64HG+cGrbRqz9IjDvs++WW5EQn1jPY8NO2XFz3sney6Cs/pLKjqJY9S7P
kfOXOBZG3zOI1kgd/CSR5b4szg4XvtTZaupczKiGOpYC9klf0oQNXGU5jXi3Csop
Q332oUgiPeNdOx/4tXobFX6RwVCqLRYZbHx9RRYSxWlqJJPAB74/n+RZsmOtsxuJ
RaiPKDmbVlslkUm78gIa5e6DMwDk2wmlkqa64W7VZxyqfQTRDPiPvfMGePkj6tmZ
h9vUsELwwORlHpZyL08n0fzs3aeIYwzPwhfr+5iQZIawIp4Zqo8i8Lic/WfIlok9
rmPIA0mjs1VtrUsroItw4NcY04xcVa7hkhz4EbkZROrfGamdkLuvbk2OKuOeoL0U
lpgtQL6jA7E=
=F/j2
-----END PGP SIGNATURE-----
Merge tag 'pull-request-2024-01-11' of https://gitlab.com/thuth/qemu into staging
* Fix non-deterministic failures of the 'netdev-socket' qtest
* Fix device presence checking in the virtio-ccw qtest
* Support codespell checking in checkpatch.pl
* Fix emulation of LAE s390x instruction
* Work around htags bug when environment is large
* Some other small clean-ups here and there
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmWgHlgRHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbXAnBAAjQve/Jmfp9p8eQmswG7cl/a2TuJ59b9X
# SFRja2PprV/Wp4kxxEJX4er9F2+rlMusNL62LBp/QjZi9u4lCvCmuB7sMa0wEkjr
# BPPBrkxkAT+/8vhGpYg2GrxZv/UOLkycp3sjEp4v5yXWQw+OEBnkZZ+AuHddpnEr
# NKMKss71uQmccvuzD5FMDfbJQcSBD/yGPyFfDrv1RKreYRlbkEDVlcVoZpfoMwQY
# Pl167iDdmjVtsT+4wf8vHo5W/AYKDOjlV6AoujCnJVZnGx6BtDLiF/iNJ/VU1Ty5
# cRxySPT64HG+cGrbRqz9IjDvs++WW5EQn1jPY8NO2XFz3sney6Cs/pLKjqJY9S7P
# kfOXOBZG3zOI1kgd/CSR5b4szg4XvtTZaupczKiGOpYC9klf0oQNXGU5jXi3Csop
# Q332oUgiPeNdOx/4tXobFX6RwVCqLRYZbHx9RRYSxWlqJJPAB74/n+RZsmOtsxuJ
# RaiPKDmbVlslkUm78gIa5e6DMwDk2wmlkqa64W7VZxyqfQTRDPiPvfMGePkj6tmZ
# h9vUsELwwORlHpZyL08n0fzs3aeIYwzPwhfr+5iQZIawIp4Zqo8i8Lic/WfIlok9
# rmPIA0mjs1VtrUsroItw4NcY04xcVa7hkhz4EbkZROrfGamdkLuvbk2OKuOeoL0U
# lpgtQL6jA7E=
# =F/j2
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 11 Jan 2024 16:59:04 GMT
# gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg: issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5
* tag 'pull-request-2024-01-11' of https://gitlab.com/thuth/qemu:
.gitlab-ci.d/buildtest.yml: Work around htags bug when environment is large
tests/tcg/s390x: Test LOAD ADDRESS EXTENDED
target/s390x: Fix LAE setting a wrong access register
scripts/checkpatch: Support codespell checking
hw/s390x/ccw: Replace dirname() with g_path_get_dirname()
hw/s390x/ccw: Replace basename() with g_path_get_basename()
target/s390x/kvm/pv: Provide some more useful information if decryption fails
gitlab: fix s390x tag for avocado-system-centos
tests/qtest/virtio-ccw: Fix device presence checking
qtest: ensure netdev-socket tests have non-overlapping names
net: handle QIOTask completion to report useful error message
net: add explicit info about connecting/listening state
Revert "tests/qtest/netdev-socket: Raise connection timeout to 120 seconds"
Revert "osdep: add getloadavg"
Revert "netdev: set timeout depending on loadavg"
qtest: use correct boolean type for failover property
q800: move dp8393x_prom memory region to Q800MachineState
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
-----BEGIN PGP SIGNATURE-----
iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCZZ/QKgAKCRBAov/yOSY+
34eqBADA48++Z9gETFNheLUHdYEaja2emn+gSaoHLFquyq/l53w8RfrUII+BzV1o
T7D8xjlVQldAYZzqQn2pQe2S7r4ggfeNmxGxwJbCTW9sooGMwBnU8+Ix3ruSet7K
gI+UHLU4oHk6jdrT384tux2EG+qUmlLN1c7j4G/z1OzKEwFv7Q==
=+Pi0
-----END PGP SIGNATURE-----
Merge tag 'pull-loongarch-20240111' of https://gitlab.com/gaosong/qemu into staging
pull-loongarch-20240111
# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCZZ/QKgAKCRBAov/yOSY+
# 34eqBADA48++Z9gETFNheLUHdYEaja2emn+gSaoHLFquyq/l53w8RfrUII+BzV1o
# T7D8xjlVQldAYZzqQn2pQe2S7r4ggfeNmxGxwJbCTW9sooGMwBnU8+Ix3ruSet7K
# gI+UHLU4oHk6jdrT384tux2EG+qUmlLN1c7j4G/z1OzKEwFv7Q==
# =+Pi0
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 11 Jan 2024 11:25:30 GMT
# gpg: using RSA key B8FF1DA0D2FDCB2DA09C6C2C40A2FFF239263EDF
# gpg: Good signature from "Song Gao <m17746591750@163.com>" [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: B8FF 1DA0 D2FD CB2D A09C 6C2C 40A2 FFF2 3926 3EDF
* tag 'pull-loongarch-20240111' of https://gitlab.com/gaosong/qemu:
hw/intc/loongarch_extioi: Add vmstate post_load support
hw/intc/loongarch_extioi: Add dynamic cpu number support
hw/loongarch/virt: Set iocsr address space per-board rather than percpu
hw/intc/loongarch_ipi: Use MemTxAttrs interface for ipi ops
target/loongarch: Add loongarch kvm into meson build
target/loongarch: Implement set vcpu intr for kvm
target/loongarch: Restrict TCG-specific code
target/loongarch: Implement kvm_arch_handle_exit
target/loongarch: Implement kvm_arch_init_vcpu
target/loongarch: Implement kvm_arch_init function
target/loongarch: Implement kvm get/set registers
target/loongarch: Supplement vcpu env initial when vcpu reset
target/loongarch: Define some kvm_arch interfaces
linux-headers: Synchronize linux headers from linux v6.7.0-rc8
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
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: a1c7610a68 ("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>
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>
LoongArch system has iocsr address space, most iocsr registers are
per-board, however some iocsr register spaces banked for percpu such
as ipi mailbox and extioi interrupt status. For banked iocsr space,
each cpu has the same iocsr space, but separate data.
This patch changes iocsr address space per-board rather percpu,
for iocsr registers specified for cpu, MemTxAttrs.requester_id
can be parsed for the cpu. With this patches, the total address space
on board will be simple, only iocsr address space and system memory,
rather than the number of cpu and system memory.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20231215100333.3933632-3-maobibo@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Add kvm.c into meson.build to compile it when kvm
is configed. Meanwhile in meson.build, we set the
kvm_targets to loongarch64-softmmu when the cpu is
loongarch. And fix the compiling error when config
is enable-kvm,disable-tcg.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240105075804.1228596-10-zhaotianrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Implement loongarch kvm set vcpu interrupt interface,
when a irq is set in vcpu, we use the KVM_INTERRUPT
ioctl to set intr into kvm.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20240105075804.1228596-9-zhaotianrui@loongson.cn>
[PMD: Split from bigger patch, part 2]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20240110094152.52138-2-philmd@linaro.org>
Signed-off-by: Song Gao <gaosong@loongson.cn>
In preparation of supporting KVM in the next commit.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20240105075804.1228596-9-zhaotianrui@loongson.cn>
[PMD: Split from bigger patch, part 1]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20240110094152.52138-1-philmd@linaro.org>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Implement kvm_arch_handle_exit for loongarch. In this
function, the KVM_EXIT_LOONGARCH_IOCSR is handled,
we read or write the iocsr address space by the addr,
length and is_write argument in kvm_run.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240105075804.1228596-8-zhaotianrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Implement kvm_arch_init_vcpu interface for loongarch,
in this function, we register VM change state handler.
And when VM state changes to running, the counter value
should be put into kvm to keep consistent with kvm,
and when state change to stop, counter value should be
refreshed from kvm.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240105075804.1228596-7-zhaotianrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Implement the kvm_arch_init of loongarch, in the function, the
KVM_CAP_MP_STATE cap is checked by kvm ioctl.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240105075804.1228596-6-zhaotianrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Implement kvm_arch_get/set_registers interfaces, many regs
can be get/set in the function, such as core regs, csr regs,
fpu regs, mp state, etc.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Change-Id: Ia8fc48fe08b1768853f7729e77d37cdf270031e4
Message-Id: <20240105075804.1228596-5-zhaotianrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Supplement vcpu env initial when vcpu reset, including
init vcpu CSR_CPUID,CSR_TID to cpu->cpu_index. The two
regs will be used in kvm_get/set_csr_ioctl.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240105075804.1228596-4-zhaotianrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Define some functions in target/loongarch/kvm/kvm.c,
such as kvm_arch_put_registers, kvm_arch_get_registers
and kvm_arch_handle_exit, etc. which are needed by
kvm/kvm-all.c. Now the most functions has no content
and they will be implemented in the next patches.
Signed-off-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: xianglai li <lixianglai@loongson.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-Id: <20240105075804.1228596-3-zhaotianrui@loongson.cn>
Signed-off-by: Song Gao <gaosong@loongson.cn>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
'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>
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>
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>
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>
'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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
