Re: [RFC v2 2/2] hw/riscv: Add server platform reference machine
On Tue, Mar 12, 2024 at 09:52:21PM GMT, Fei Wu wrote: > The RISC-V Server Platform specification[1] defines a standardized set > of hardware and software capabilities, that portable system software, > such as OS and hypervisors can rely on being present in a RISC-V server > platform. > > A corresponding Qemu RISC-V server platform reference (rvsp-ref for > short) machine type is added to provide a environment for firmware/OS > development and testing. The main features included in rvsp-ref are: > > - Based on riscv virt machine type > - A new memory map as close as virt machine as possible > - A new virt CPU type rvsp-ref-cpu for server platform compliance > - AIA > - PCIe AHCI > - PCIe NIC We should rebase on the IOMMU series [1] and add an IOMMU to the platform, as it's required by the Server Soc spec (which is required by the server platform spec). [1] https://lore.kernel.org/qemu-devel/20240307160319.675044-1-dbarb...@ventanamicro.com/ Thanks, drew
Re: [RISC-V][tech-server-soc] [RFC v2 1/2] target/riscv: Add server platform reference cpu
On Tue, Mar 12, 2024 at 09:52:20PM GMT, Wu, Fei2 wrote: > The harts requirements of RISC-V server platform [1] require RVA23 ISA > profile support, plus Sv48, Svadu, H, Sscofmpf etc. This patch provides > a virt CPU type (rvsp-ref) as compliant as possible. We should add the RVA23 profile cpu type first, and then base a reference cpu type on that. But, I guess we should version the reference type, since we shouldn't expect the reference type to be bound to only RVA23 forever. Thanks, drew
Re: [PATCH v2 1/1] target/riscv/kvm.c: Fix the hart bit setting of AIA
On Wed, May 15, 2024 at 05:11:28PM GMT, Yong-Xuan Wang wrote:
> In AIA spec, each hart (or each hart within a group) has a unique hart
> number to locate the memory pages of interrupt files in the address
> space. The number of bits required to represent any hart number is equal
> to ceil(log2(hmax + 1)), where hmax is the largest hart number among
> groups.
>
> However, if the largest hart number among groups is a power of 2, QEMU
> will pass an inaccurate hart-index-bit setting to Linux. For example, when
> the guest OS has 4 harts, only ceil(log2(3 + 1)) = 2 bits are sufficient
> to represent 4 harts, but we passes 3 to Linux. The code needs to be
> updated to ensure accurate hart-index-bit settings.
>
> Additionally, a Linux patch[1] is necessary to correctly recover the hart
> index when the guest OS has only 1 hart, where the hart-index-bit is 0.
>
> [1]
> https://lore.kernel.org/lkml/20240415064905.25184-1-yongxuan.w...@sifive.com/t/
>
> Signed-off-by: Yong-Xuan Wang
> ---
> Changelog
> v2:
> - update commit message
> ---
> target/riscv/kvm/kvm-cpu.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 473416649fda..235e2cdaca1a 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -1777,7 +1777,14 @@ void kvm_riscv_aia_create(MachineState *machine,
> uint64_t group_shift,
> }
> }
>
> -hart_bits = find_last_bit(_hart_per_socket, BITS_PER_LONG) + 1;
> +
> +if (max_hart_per_socket > 1) {
> +max_hart_per_socket--;
> +hart_bits = find_last_bit(_hart_per_socket, BITS_PER_LONG) + 1;
> +} else {
> +hart_bits = 0;
> +}
> +
> ret = kvm_device_access(aia_fd, KVM_DEV_RISCV_AIA_GRP_CONFIG,
> KVM_DEV_RISCV_AIA_CONFIG_HART_BITS,
> _bits, true, NULL);
> --
> 2.17.1
>
Reviewed-by: Andrew Jones
Re: [PATCH v2 06/15] hw/riscv/virt.c: support for RISC-V IOMMU PCIDevice hotplug
On Wed, May 15, 2024 at 02:25:31PM GMT, Eric Cheng wrote:
> On 3/8/2024 12:03 AM, Daniel Henrique Barboza wrote:
> > From: Tomasz Jeznach
> >
> > Generate device tree entry for riscv-iommu PCI device, along with
> > mapping all PCI device identifiers to the single IOMMU device instance.
> >
> > Signed-off-by: Tomasz Jeznach
> > Signed-off-by: Daniel Henrique Barboza
> > ---
> > hw/riscv/virt.c | 33 -
> > 1 file changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index a094af97c3..67a8267747 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -32,6 +32,7 @@
> > #include "hw/core/sysbus-fdt.h"
> > #include "target/riscv/pmu.h"
> > #include "hw/riscv/riscv_hart.h"
> > +#include "hw/riscv/iommu.h"
> > #include "hw/riscv/virt.h"
> > #include "hw/riscv/boot.h"
> > #include "hw/riscv/numa.h"
> > @@ -1004,6 +1005,30 @@ static void create_fdt_virtio_iommu(RISCVVirtState
> > *s, uint16_t bdf)
> > bdf + 1, iommu_phandle, bdf + 1, 0x - bdf);
> > }
> > +static void create_fdt_iommu(RISCVVirtState *s, uint16_t bdf)
> > +{
> > +const char comp[] = "riscv,pci-iommu";
> > +void *fdt = MACHINE(s)->fdt;
> > +uint32_t iommu_phandle;
> > +g_autofree char *iommu_node = NULL;
> > +g_autofree char *pci_node = NULL;
> > +
> > +pci_node = g_strdup_printf("/soc/pci@%lx",
> > + (long) virt_memmap[VIRT_PCIE_ECAM].base);
> > +iommu_node = g_strdup_printf("%s/iommu@%x", pci_node, bdf);
> > +iommu_phandle = qemu_fdt_alloc_phandle(fdt);
> > +qemu_fdt_add_subnode(fdt, iommu_node);
> > +
> > +qemu_fdt_setprop(fdt, iommu_node, "compatible", comp, sizeof(comp));
> > +qemu_fdt_setprop_cell(fdt, iommu_node, "#iommu-cells", 1);
> > +qemu_fdt_setprop_cell(fdt, iommu_node, "phandle", iommu_phandle);
> > +qemu_fdt_setprop_cells(fdt, iommu_node, "reg",
> > + bdf << 8, 0, 0, 0, 0);
> > +qemu_fdt_setprop_cells(fdt, pci_node, "iommu-map",
> > + 0, iommu_phandle, 0, bdf,
> > + bdf + 1, iommu_phandle, bdf + 1, 0x - bdf);
> > +}
>
> Is it really necessary to add this iommu-pci device in riscv virt machine,
> rather than other 'physical' machine type? virt machine already has its
> virtio-iommu.
>
We need both, just as the Arm virt machine has both. virtio-iommu is for
guests, but the Arm and RISCV virt machines are both also used as hosts.
Thanks,
drew
Re: [PATCH v2 09/15] hw/riscv/riscv-iommu: add s-stage and g-stage support
On Fri, May 10, 2024 at 06:36:51PM GMT, Frank Chang wrote:
...
> > static int riscv_iommu_spa_fetch(RISCVIOMMUState *s, RISCVIOMMUContext
> > *ctx,
> > -IOMMUTLBEntry *iotlb)
> > +IOMMUTLBEntry *iotlb, bool gpa)
> > {
> > +dma_addr_t addr, base;
> > +uint64_t satp, gatp, pte;
> > +bool en_s, en_g;
> > +struct {
> > +unsigned char step;
> > +unsigned char levels;
> > +unsigned char ptidxbits;
> > +unsigned char ptesize;
> > +} sc[2];
> > +/* Translation stage phase */
> > +enum {
> > +S_STAGE = 0,
> > +G_STAGE = 1,
> > +} pass;
> > +
> > +satp = get_field(ctx->satp, RISCV_IOMMU_ATP_MODE_FIELD);
> > +gatp = get_field(ctx->gatp, RISCV_IOMMU_ATP_MODE_FIELD);
> > +
> > +en_s = satp != RISCV_IOMMU_DC_FSC_MODE_BARE && !gpa;
> > +en_g = gatp != RISCV_IOMMU_DC_IOHGATP_MODE_BARE;
> > +
> > /* Early check for MSI address match when IOVA == GPA */
> > -if (iotlb->perm & IOMMU_WO &&
> > +if (!en_s && (iotlb->perm & IOMMU_WO) &&
>
> I'm wondering do we need to check "en_s" for MSI writes?
>
> IOMMU spec Section 2.3.3. Process to translate addresses of MSIs says:
> "Determine if the address A is an access to a virtual interrupt file
> as specified in Section 2.1.3.6."
>
> and Section 2.1.3.6 says:
>
> "An incoming memory access made by a device is recognized as
> an access to a virtual interrupt file if the destination guest physical page
> matches the supplied address pattern in all bit positions that are zeros
> in the supplied address mask. In detail, a memory access to
> guest physical address A is recognized as an access to a virtual
> interrupt file’s
> memory-mapped page if:
> (A >> 12) & ~msi_addr_mask = (msi_addr_pattern & ~msi_addr_mask)"
>
> Is checking the address pattern sufficient enough to determine
> the address is an MSI to a virtual interrupt file?
>
I think so. In fact, I've removed that en_s check on our internal build in
order to get things working for my irqbypass work, as we can do device
assignment with VFIO with only S-stage enabled.
Thanks,
drew
Re: [PATCH 1/3] target/riscv: Save counter values during countinhibit update
On Thu, May 09, 2024 at 01:26:56PM GMT, Atish Kumar Patra wrote:
> On Thu, May 2, 2024 at 5:39 AM Andrew Jones wrote:
> >
> > On Tue, Apr 30, 2024 at 03:00:45PM GMT, Daniel Henrique Barboza wrote:
> > >
> > >
> > > On 4/29/24 16:28, Atish Patra wrote:
> > > > Currently, if a counter monitoring cycle/instret is stopped via
> > > > mcountinhibit we just update the state while the value is saved
> > > > during the next read. This is not accurate as the read may happen
> > > > many cycles after the counter is stopped. Ideally, the read should
> > > > return the value saved when the counter is stopped.
> > > >
> > > > Thus, save the value of the counter during the inhibit update
> > > > operation and return that value during the read if corresponding bit
> > > > in mcountihibit is set.
> > > >
> > > > Signed-off-by: Atish Patra
> > > > ---
> > > > target/riscv/cpu.h | 1 -
> > > > target/riscv/csr.c | 32
> > > > target/riscv/machine.c | 1 -
> > > > 3 files changed, 20 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > > > index 3b1a02b9449a..09bbf7ce9880 100644
> > > > --- a/target/riscv/cpu.h
> > > > +++ b/target/riscv/cpu.h
> > > > @@ -153,7 +153,6 @@ typedef struct PMUCTRState {
> > > > target_ulong mhpmcounter_prev;
> > > > /* Snapshort value of a counter in RV32 */
> > > > target_ulong mhpmcounterh_prev;
> > > > -bool started;
> > > > /* Value beyond UINT32_MAX/UINT64_MAX before overflow interrupt
> > > > trigger */
> > > > target_ulong irq_overflow_left;
> > > > } PMUCTRState;
> > > > diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> > > > index 726096444fae..68ca31aff47d 100644
> > > > --- a/target/riscv/csr.c
> > > > +++ b/target/riscv/csr.c
> > > > @@ -929,17 +929,11 @@ static RISCVException
> > > > riscv_pmu_read_ctr(CPURISCVState *env, target_ulong *val,
> > > > if (get_field(env->mcountinhibit, BIT(ctr_idx))) {
> > > > /*
> > > > - * Counter should not increment if inhibit bit is set. We
> > > > can't really
> > > > - * stop the icount counting. Just return the counter value
> > > > written by
> > > > - * the supervisor to indicate that counter was not incremented.
> > > > + * Counter should not increment if inhibit bit is set. Just
> > > > return the
> > > > + * current counter value.
> > > >*/
> > > > -if (!counter->started) {
> > > > -*val = ctr_val;
> > > > -return RISCV_EXCP_NONE;
> > > > -} else {
> > > > -/* Mark that the counter has been stopped */
> > > > -counter->started = false;
> > > > -}
> > > > + *val = ctr_val;
> > > > + return RISCV_EXCP_NONE;
> > > > }
> > > > /*
> > > > @@ -1973,9 +1967,23 @@ static RISCVException
> > > > write_mcountinhibit(CPURISCVState *env, int csrno,
> > > > /* Check if any other counter is also monitoring
> > > > cycles/instructions */
> > > > for (cidx = 0; cidx < RV_MAX_MHPMCOUNTERS; cidx++) {
> > > > -if (!get_field(env->mcountinhibit, BIT(cidx))) {
> > > > counter = >pmu_ctrs[cidx];
> > > > -counter->started = true;
> > > > +if (get_field(env->mcountinhibit, BIT(cidx)) && (val &
> > > > BIT(cidx))) {
> > > > + /*
> > > > + * Update the counter value for cycle/instret as we can't
> > > > stop the
> > > > + * host ticks. But we should show the current value at
> > > > this moment.
> > > > + */
> > > > +if (riscv_pmu_ctr_monitor_cycles(env, cidx) ||
> > > > +riscv_pmu_ctr_monitor_instructions(env, cidx)) {
> > > > +counter->mhpmcounter_val = get_ticks(false) -
> > > > + counter->mhpmcounter_prev +
> > > > +
Re: [PATCH] target/riscv: Remove experimental prefix from "B" extension
On Thu, May 09, 2024 at 02:23:42PM GMT, Daniel Henrique Barboza wrote:
>
>
> On 5/8/24 08:22, Andrew Jones wrote:
> > On Tue, May 07, 2024 at 11:27:21AM GMT, Rob Bradford wrote:
> > > This extension has now been ratified:
> > > https://jira.riscv.org/browse/RVS-2006 so the "x-" prefix can be
> > > removed.
> > >
> > > Signed-off-by: Rob Bradford
> > > ---
> > > target/riscv/cpu.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > > index eb1a2e7d6d..861d9f4350 100644
> > > --- a/target/riscv/cpu.c
> > > +++ b/target/riscv/cpu.c
> > > @@ -1396,7 +1396,7 @@ static const MISAExtInfo misa_ext_info_arr[] = {
> > > MISA_EXT_INFO(RVJ, "x-j", "Dynamic translated languages"),
> > > MISA_EXT_INFO(RVV, "v", "Vector operations"),
> > > MISA_EXT_INFO(RVG, "g", "General purpose (IMAFD_Zicsr_Zifencei)"),
> > > -MISA_EXT_INFO(RVB, "x-b", "Bit manipulation (Zba_Zbb_Zbs)")
> > > +MISA_EXT_INFO(RVB, "b", "Bit manipulation (Zba_Zbb_Zbs)")
> > > };
> > > static void riscv_cpu_validate_misa_mxl(RISCVCPUClass *mcc)
> > > --
> > > 2.44.0
> > >
> > >
> >
> > Reviewed-by: Andrew Jones
> >
> > I think we should also either change the false to true for RVB in
> > misa_ext_cfgs[] or at least ensure RVB is set for the 'max' cpu
> > type in riscv_init_max_cpu_extensions().
>
> I prefer if we keep misa_ext_cfgs[] as is. Changing the defaults in this array
> will also change the defaults for rv64. IMO we should enable RVB manually in
> riscv_init_max_cpu_extensions().
>
> We already have some precedence for it: RVV is enabled in 'max' while is
> default
> 'false' for rv64.
But do we care if rv64 gets B? rv64 doesn't have any particular set of
extensions, afaik. And B seems like it should be generally adopted enough
to be in a "general" cpu type like rv64. Anyway, either way works for me
as long as 'max' gets B one way or another.
Thanks,
drew
Re: [PATCH] target/riscv: Remove experimental prefix from "B" extension
On Tue, May 07, 2024 at 11:27:21AM GMT, Rob Bradford wrote:
> This extension has now been ratified:
> https://jira.riscv.org/browse/RVS-2006 so the "x-" prefix can be
> removed.
>
> Signed-off-by: Rob Bradford
> ---
> target/riscv/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index eb1a2e7d6d..861d9f4350 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1396,7 +1396,7 @@ static const MISAExtInfo misa_ext_info_arr[] = {
> MISA_EXT_INFO(RVJ, "x-j", "Dynamic translated languages"),
> MISA_EXT_INFO(RVV, "v", "Vector operations"),
> MISA_EXT_INFO(RVG, "g", "General purpose (IMAFD_Zicsr_Zifencei)"),
> -MISA_EXT_INFO(RVB, "x-b", "Bit manipulation (Zba_Zbb_Zbs)")
> +MISA_EXT_INFO(RVB, "b", "Bit manipulation (Zba_Zbb_Zbs)")
> };
>
> static void riscv_cpu_validate_misa_mxl(RISCVCPUClass *mcc)
> --
> 2.44.0
>
>
Reviewed-by: Andrew Jones
I think we should also either change the false to true for RVB in
misa_ext_cfgs[] or at least ensure RVB is set for the 'max' cpu
type in riscv_init_max_cpu_extensions().
Thanks,
drew
Re: [PATCH v6] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Fri, May 03, 2024 at 01:39:32PM GMT, Aleksei Filippov wrote:
>
>
> On 25.04.2024 12:21, Andrew Jones wrote:
> > On Mon, Apr 22, 2024 at 02:31:36PM +0200, Andrew Jones wrote:
> > > On Mon, Apr 22, 2024 at 02:42:54PM +0300, Alexei Filippov wrote:
> > > > kvm_riscv_handle_sbi() may return not supported return code to not
> > > > trigger qemu abort with vendor-specific sbi.
> > > >
> > > > Add new error path to provide proper error in case of
> > > > qemu_chr_fe_read_all() may not return sizeof(ch).
> > >
> > > I think something more along the lines of what I wrote in my previous
> > > reply will help clarify this more. Here's what I wrote
> > >
> > > """
> > > Exactly zero just means we failed to read input, which can happen, so
> > > telling the SBI caller we failed to read, but telling the caller of this
> > > function that we successfully emulated the SBI call, is correct. However,
> > > anything else, other than sizeof(ch), means something unexpected happened,
> > > so we should indeed return an error from this function.
> > > """
> > >
> > > Thanks,
> > > drew
> > >
> > > >
> > > > Added SBI related return code's defines.
> > > >
> > > > Signed-off-by: Alexei Filippov
> > > > ---
> > > > Changes since v4-5:
> > > > -Added new error path in case of qemu_chr_fe_read_all()
> > > > may not
> > > > return sizeof(ch).
> > > > -Added more comments in commit message.
> > > > target/riscv/kvm/kvm-cpu.c | 10 ++
> > > > target/riscv/sbi_ecall_interface.h | 12
> > > > 2 files changed, 18 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> > > > index f9dbc18a76..5bb7b74d03 100644
> > > > --- a/target/riscv/kvm/kvm-cpu.c
> > > > +++ b/target/riscv/kvm/kvm-cpu.c
> > > > @@ -1173,16 +1173,18 @@ static int kvm_riscv_handle_sbi(CPUState *cs,
> > > > struct kvm_run *run)
> > > > ret = qemu_chr_fe_read_all(serial_hd(0)->be, , sizeof(ch));
> > > > if (ret == sizeof(ch)) {
> > > > run->riscv_sbi.ret[0] = ch;
> > > > +ret = 0;
> > > > +} else if (ret == 0) {
> > > > +run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
> >
> > I'd prefer we still explicitly assign ret[0] to -1 here since that's what
> > the spec explicitly says.
> >
> > Thanks,
> > drew
>
> Can you please explain it a little bit more, cz I believe SBI_ERR_FAILURE is
> -1 anyway. Defines was added at first place just to came along with Linux
> kernel SBI related defines.
Legacy SBI calls like SBI_EXT_0_1_CONSOLE_GETCHAR don't return a struct
sbiret, they only return a function-specific long. The spec says for
Getchar that it returns "...the byte on success, or -1 for failure."
So we should explicitly set failure to -1, especially since
SBI_ERR_FAILURE isn't defined for legacy SBI calls.
Thanks,
drew
> --
> Sincerely,
> Aleksei Filippov
>
> > > > } else {
> > > > -run->riscv_sbi.ret[0] = -1;
> > > > +ret = -1;
> > > > }
> > > > -ret = 0;
> > > > break;
> > > > default:
> > > > qemu_log_mask(LOG_UNIMP,
> > > > - "%s: un-handled SBI EXIT, specific reasons is
> > > > %lu\n",
> > > > + "%s: Unhandled SBI exit with extension-id %lu\n"
> > > > __func__, run->riscv_sbi.extension_id);
> > > > -ret = -1;
> > > > +run->riscv_sbi.ret[0] = SBI_ERR_NOT_SUPPORTED;
> > > > break;
> > > > }
> > > > return ret;
> > > > diff --git a/target/riscv/sbi_ecall_interface.h
> > > > b/target/riscv/sbi_ecall_interface.h
> > > > index 43899d08f6..a2e21d9b8c 100644
> > > > --- a/target/riscv/sbi_ecall_interface.h
> > > > +++ b/target/riscv/sbi_ecall_interface.h
> > > > @@ -69,4 +69,16 @@
> > > > #define SBI_EXT_VENDOR_END 0x09FF
> > > > /* clang-format on */
> > > > +/* SBI return error codes */
> > > > +#define SBI_SUCCESS 0
> > > > +#define SBI_ERR_FAILURE -1
> > > > +#define SBI_ERR_NOT_SUPPORTED -2
> > > > +#define SBI_ERR_INVALID_PARAM -3
> > > > +#define SBI_ERR_DENIED -4
> > > > +#define SBI_ERR_INVALID_ADDRESS -5
> > > > +#define SBI_ERR_ALREADY_AVAILABLE -6
> > > > +#define SBI_ERR_ALREADY_STARTED -7
> > > > +#define SBI_ERR_ALREADY_STOPPED -8
> > > > +#define SBI_ERR_NO_SHMEM-9
> > > > +
> > > > #endif
> > > > --
> > > > 2.34.1
> > > >
Re: [PATCH 1/3] target/riscv: Save counter values during countinhibit update
On Tue, Apr 30, 2024 at 03:00:45PM GMT, Daniel Henrique Barboza wrote:
>
>
> On 4/29/24 16:28, Atish Patra wrote:
> > Currently, if a counter monitoring cycle/instret is stopped via
> > mcountinhibit we just update the state while the value is saved
> > during the next read. This is not accurate as the read may happen
> > many cycles after the counter is stopped. Ideally, the read should
> > return the value saved when the counter is stopped.
> >
> > Thus, save the value of the counter during the inhibit update
> > operation and return that value during the read if corresponding bit
> > in mcountihibit is set.
> >
> > Signed-off-by: Atish Patra
> > ---
> > target/riscv/cpu.h | 1 -
> > target/riscv/csr.c | 32
> > target/riscv/machine.c | 1 -
> > 3 files changed, 20 insertions(+), 14 deletions(-)
> >
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index 3b1a02b9449a..09bbf7ce9880 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -153,7 +153,6 @@ typedef struct PMUCTRState {
> > target_ulong mhpmcounter_prev;
> > /* Snapshort value of a counter in RV32 */
> > target_ulong mhpmcounterh_prev;
> > -bool started;
> > /* Value beyond UINT32_MAX/UINT64_MAX before overflow interrupt
> > trigger */
> > target_ulong irq_overflow_left;
> > } PMUCTRState;
> > diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> > index 726096444fae..68ca31aff47d 100644
> > --- a/target/riscv/csr.c
> > +++ b/target/riscv/csr.c
> > @@ -929,17 +929,11 @@ static RISCVException
> > riscv_pmu_read_ctr(CPURISCVState *env, target_ulong *val,
> > if (get_field(env->mcountinhibit, BIT(ctr_idx))) {
> > /*
> > - * Counter should not increment if inhibit bit is set. We can't
> > really
> > - * stop the icount counting. Just return the counter value written
> > by
> > - * the supervisor to indicate that counter was not incremented.
> > + * Counter should not increment if inhibit bit is set. Just return
> > the
> > + * current counter value.
> >*/
> > -if (!counter->started) {
> > -*val = ctr_val;
> > -return RISCV_EXCP_NONE;
> > -} else {
> > -/* Mark that the counter has been stopped */
> > -counter->started = false;
> > -}
> > + *val = ctr_val;
> > + return RISCV_EXCP_NONE;
> > }
> > /*
> > @@ -1973,9 +1967,23 @@ static RISCVException
> > write_mcountinhibit(CPURISCVState *env, int csrno,
> > /* Check if any other counter is also monitoring cycles/instructions
> > */
> > for (cidx = 0; cidx < RV_MAX_MHPMCOUNTERS; cidx++) {
> > -if (!get_field(env->mcountinhibit, BIT(cidx))) {
> > counter = >pmu_ctrs[cidx];
> > -counter->started = true;
> > +if (get_field(env->mcountinhibit, BIT(cidx)) && (val & BIT(cidx)))
> > {
> > + /*
> > + * Update the counter value for cycle/instret as we can't stop
> > the
> > + * host ticks. But we should show the current value at this
> > moment.
> > + */
> > +if (riscv_pmu_ctr_monitor_cycles(env, cidx) ||
> > +riscv_pmu_ctr_monitor_instructions(env, cidx)) {
> > +counter->mhpmcounter_val = get_ticks(false) -
> > + counter->mhpmcounter_prev +
> > + counter->mhpmcounter_val;
> > +if (riscv_cpu_mxl(env) == MXL_RV32) {
> > +counter->mhpmcounterh_val = get_ticks(false) -
> > +counter->mhpmcounterh_prev
> > +
> > +counter->mhpmcounterh_val;
> > + }
> > +}
> > }
> > }
> > diff --git a/target/riscv/machine.c b/target/riscv/machine.c
> > index 76f2150f78b5..3e0f2dd2ce2a 100644
> > --- a/target/riscv/machine.c
> > +++ b/target/riscv/machine.c
> > @@ -328,7 +328,6 @@ static const VMStateDescription vmstate_pmu_ctr_state =
> > {
> > VMSTATE_UINTTL(mhpmcounterh_val, PMUCTRState),
> > VMSTATE_UINTTL(mhpmcounter_prev, PMUCTRState),
> > VMSTATE_UINTTL(mhpmcounterh_prev, PMUCTRState),
> > -VMSTATE_BOOL(started, PMUCTRState),
>
> Unfortunately we can't remove fields from the VMStateDescription without
> breaking
> migration backward compatibility. Older QEMUs will attempt to read a field
> that
> doesn't exist and migration will fail.
>
> I'm assuming that we care about backward compat. If we're not up to this
> point yet
> then we can just bump the version_id of vmstate_pmu_ctr_state and be done
> with it.
> This is fine to do unless someone jumps in and complains that we broke a
> migration
> case for the 'virt' board. Granted, we don't have versioned boards yet so I'm
> unsure
> if someone would
Re: [PATCH v2 1/1] target/riscv/kvm: fix timebase-frequency when using KVM acceleration
On April 27, 2024 9:24:04 AM GMT+02:00, Michael Tokarev wrote: >27.04.2024 09:59, Michael Tokarev wrote: >> 27.04.2024 09:23, Andrew Jones wrote: >... >>> It's possible to cross-compile qemu, so it'd be good to add that to the CI >>> for riscv until we can add native compiling. >> >> Yes, definitely. Qemu is already being cross-compiled on all "other" >> architectures during CI. But it is also being *run*, not just compiled. >> And this is what's broken on riscv64 for almost a year now, and this >> job has been disabled. Instead, the *run* part of this job needs to >> be disabled, but *build* part should be kept. > >Aha. I was wrong. And I was there before too, for sure, - just forgot >about it. In order to be cross-compiled, the cross-build environment >needs to have target -dev libraries, not only the cross-compiler. >And this is where debian riscv64 port is failing. > >So no, it is not currently possible to cross-compile qemu at least >on debian without building whole cross-environment with all libraries >and other necessary stuff. > >I'll try to use debian riscv64 porterbox to at least verify the new >set of patches we'll pick here to fix this breakage, at least compiles >on riscv64 :) I wrote instructions [2] for how to cross-compile without a full environment/container once. It might be better for quick, local testing. [2] https://lore.kernel.org/qemu-riscv/20230726120706.335340-2-ajo...@ventanamicro.com/ > >> 10f86d1b845087d1 isn't sufficient, since it relies on 450bd6618fda3d >> "target/riscv/kvm: change KVM_REG_RISCV_FP_D to u64". In the same series >> there also was 49c211ffca00fdf7c "target/riscv/kvm: change KVM_REG_RISCV_FP_F >> to u32" - is it also needed? > >49c211ffca00fdf7c is also needed. So it's 3 so far, still not compile- >tested. Anything else? Those 3, the first of the series [1], are good. Not sure why it's still not compiling. [1] https://lists.gnu.org/archive/html/qemu-devel/2023-12/msg01132.html drew
Re: [PATCH v2 1/1] target/riscv/kvm: fix timebase-frequency when using KVM acceleration
On April 27, 2024 1:44:42 AM GMT+02:00, Michael Tokarev wrote:
>14.03.2024 09:15, Yong-Xuan Wang:
>> The timebase-frequency of guest OS should be the same with host
>> machine. The timebase-frequency value in DTS should be got from
>> hypervisor when using KVM acceleration.
>
>This change ended up in stable-8.2 (v8.2.3). Interestingly, this thing
>compiled not even once, or else it would be obvious it fails to compile.
>Somehow I was too used to CI, forgetting that we don't have riscv *host*
>in CI (and I don't have one locally either). So 8.2.3 is broken on
>riscv64 *host*.
It's possible to cross-compile qemu, so it'd be good to add that to the CI for
riscv until we can add native compiling.
>
>In 8.2, KVM_RISCV_GET_TIMER macro accepts 4 arguments, because it does
>not have 10f86d1b845087d1 "target/riscv/kvm: change timer regs size to u64".
>
>What do you think, should I revert this change for stable-8.2, or pick
>10f86d1b845087d1 too, or change this commit (fix timebase-frequency) to
>provide the missing argument for this macro?
Changing the timer regs to u64 is an rv32 fix, so it's reasonable to also pick
it up. I suggest we keep this patch one way or another, though.
Thanks,
drew
>
>Thanks,
>
>/mjt
>
>
>> Reviewed-by: Andrew Jones
>> Signed-off-by: Yong-Xuan Wang
>>
>> ---
>> Changelog
>> v2:
>> - update the function definition
>> - restructure if-else statement
>> ---
>> hw/riscv/virt.c | 2 ++
>> target/riscv/kvm/kvm-cpu.c | 9 +
>> target/riscv/kvm/kvm_riscv.h | 1 +
>> 3 files changed, 12 insertions(+)
>>
>> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
>> index a094af97c32a..533b17799581 100644
>> --- a/hw/riscv/virt.c
>> +++ b/hw/riscv/virt.c
>> @@ -711,6 +711,8 @@ static void create_fdt_sockets(RISCVVirtState *s, const
>> MemMapEntry *memmap,
>> qemu_fdt_add_subnode(ms->fdt, "/cpus");
>> qemu_fdt_setprop_cell(ms->fdt, "/cpus", "timebase-frequency",
>> + kvm_enabled() ?
>> + kvm_riscv_get_timebase_frequency(first_cpu) :
>> RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ);
>> qemu_fdt_setprop_cell(ms->fdt, "/cpus", "#size-cells", 0x0);
>> qemu_fdt_setprop_cell(ms->fdt, "/cpus", "#address-cells", 0x1);
>> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
>> index c7afdb1e81b7..bbb115eaa867 100644
>> --- a/target/riscv/kvm/kvm-cpu.c
>> +++ b/target/riscv/kvm/kvm-cpu.c
>> @@ -739,6 +739,15 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
>> env->kvm_timer_dirty = false;
>> }
>> +uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs)
>> +{
>> +uint64_t reg;
>> +
>> +KVM_RISCV_GET_TIMER(cs, frequency, reg);
>> +
>> +return reg;
>> +}
>> +
>> static int kvm_riscv_get_regs_vector(CPUState *cs)
>> {
>> RISCVCPU *cpu = RISCV_CPU(cs);
>> diff --git a/target/riscv/kvm/kvm_riscv.h b/target/riscv/kvm/kvm_riscv.h
>> index 4bd98fddc776..58518988681d 100644
>> --- a/target/riscv/kvm/kvm_riscv.h
>> +++ b/target/riscv/kvm/kvm_riscv.h
>> @@ -28,5 +28,6 @@ void kvm_riscv_aia_create(MachineState *machine, uint64_t
>> group_shift,
>> void riscv_kvm_aplic_request(void *opaque, int irq, int level);
>> int kvm_riscv_sync_mpstate_to_kvm(RISCVCPU *cpu, int state);
>> void riscv_kvm_cpu_finalize_features(RISCVCPU *cpu, Error **errp);
>> +uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs);
>> #endif
>
Re: [PATCH] target/riscv/kvm: implement SBI debug console (DBCN) calls
On Thu, Apr 25, 2024 at 12:50:12PM GMT, Daniel Henrique Barboza wrote: > SBI defines a Debug Console extension "DBCN" that will, in time, replace > the legacy console putchar and getchar SBI extensions. > > The appeal of the DBCN extension is that it allows multiple bytes to be > read/written in the SBI console in a single SBI call. > > As far as KVM goes, the DBCN calls are forwarded by an in-kernel KVM > module to userspace. But this will only happens if the KVM module > actually supports this SBI extension and we activate it. > > We'll check for DBCN support during init time, checking if get-reg-list > is advertising KVM_RISCV_SBI_EXT_DBCN. In that case, we'll enable it via > kvm_set_one_reg() during kvm_arch_init_vcpu(). > > Finally, change kvm_riscv_handle_sbi() to handle the incoming calls for > SBI_EXT_DBCN, reading and writing as required. > > A simple KVM guest with 'earlycon=sbi', running in an emulated RISC-V > host, takes around 20 seconds to boot without using DBCN. With this > patch we're taking around 14 seconds to boot due to the speed-up in the > terminal output. There's no change in boot time if the guest isn't > using earlycon. > > Signed-off-by: Daniel Henrique Barboza > --- > target/riscv/kvm/kvm-cpu.c | 111 + > target/riscv/sbi_ecall_interface.h | 17 + > 2 files changed, 128 insertions(+) > Reviewed-by: Andrew Jones
Re: [PATCH v2 1/1] target/riscv/kvm: tolerate KVM disable ext errors
On Mon, Apr 22, 2024 at 02:14:25PM GMT, Daniel Henrique Barboza wrote:
> Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
> enabled, will fail with a kernel oops SIGILL right at the start. The
> reason is that we can't expose zkr without implementing the SEED CSR.
> Disabling zkr in the guest would be a workaround, but if the KVM doesn't
> allow it we'll error out and never boot.
>
> In hindsight this is too strict. If we keep proceeding, despite not
> disabling the extension in the KVM vcpu, we'll not add the extension in
> the riscv,isa. The guest kernel will be unaware of the extension, i.e.
> it doesn't matter if the KVM vcpu has it enabled underneath or not. So
> it's ok to keep booting in this case.
>
> Change our current logic to not error out if we fail to disable an
> extension in kvm_set_one_reg(), but show a warning and keep booting. It
> is important to throw a warning because we must make the user aware that
> the extension is still available in the vcpu, meaning that an
> ill-behaved guest can ignore the riscv,isa settings and use the
> extension.
>
> The case we're handling happens with an EINVAL error code. If we fail to
> disable the extension in KVM for any other reason, error out.
>
> We'll also keep erroring out when we fail to enable an extension in KVM,
> since adding the extension in riscv,isa at this point will cause a guest
> malfunction because the extension isn't enabled in the vcpu.
>
> Suggested-by: Andrew Jones
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 6a6c6cae80..03e3fee607 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -427,10 +427,14 @@ static void kvm_riscv_update_cpu_cfg_isa_ext(RISCVCPU
> *cpu, CPUState *cs)
> reg = kvm_cpu_cfg_get(cpu, multi_ext_cfg);
> ret = kvm_set_one_reg(cs, id, );
> if (ret != 0) {
> -error_report("Unable to %s extension %s in KVM, error %d",
> - reg ? "enable" : "disable",
> - multi_ext_cfg->name, ret);
> -exit(EXIT_FAILURE);
> +if (!reg && ret == -EINVAL) {
> +warn_report("KVM cannot disable extension %s",
> +multi_ext_cfg->name);
> +} else {
> +error_report("Unable to enable extension %s in KVM, error
> %d",
> + multi_ext_cfg->name, ret);
> +exit(EXIT_FAILURE);
> +}
> }
> }
> }
> --
> 2.44.0
>
Reviewed-by: Andrew Jones
Re: [PATCH v6] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Mon, Apr 22, 2024 at 02:31:36PM +0200, Andrew Jones wrote:
> On Mon, Apr 22, 2024 at 02:42:54PM +0300, Alexei Filippov wrote:
> > kvm_riscv_handle_sbi() may return not supported return code to not
> > trigger qemu abort with vendor-specific sbi.
> >
> > Add new error path to provide proper error in case of
> > qemu_chr_fe_read_all() may not return sizeof(ch).
>
> I think something more along the lines of what I wrote in my previous
> reply will help clarify this more. Here's what I wrote
>
> """
> Exactly zero just means we failed to read input, which can happen, so
> telling the SBI caller we failed to read, but telling the caller of this
> function that we successfully emulated the SBI call, is correct. However,
> anything else, other than sizeof(ch), means something unexpected happened,
> so we should indeed return an error from this function.
> """
>
> Thanks,
> drew
>
> >
> > Added SBI related return code's defines.
> >
> > Signed-off-by: Alexei Filippov
> > ---
> > Changes since v4-5:
> > -Added new error path in case of qemu_chr_fe_read_all() may not
> > return sizeof(ch).
> > -Added more comments in commit message.
> > target/riscv/kvm/kvm-cpu.c | 10 ++
> > target/riscv/sbi_ecall_interface.h | 12
> > 2 files changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> > index f9dbc18a76..5bb7b74d03 100644
> > --- a/target/riscv/kvm/kvm-cpu.c
> > +++ b/target/riscv/kvm/kvm-cpu.c
> > @@ -1173,16 +1173,18 @@ static int kvm_riscv_handle_sbi(CPUState *cs,
> > struct kvm_run *run)
> > ret = qemu_chr_fe_read_all(serial_hd(0)->be, , sizeof(ch));
> > if (ret == sizeof(ch)) {
> > run->riscv_sbi.ret[0] = ch;
> > +ret = 0;
> > +} else if (ret == 0) {
> > +run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
I'd prefer we still explicitly assign ret[0] to -1 here since that's what
the spec explicitly says.
Thanks,
drew
> > } else {
> > -run->riscv_sbi.ret[0] = -1;
> > +ret = -1;
> > }
> > -ret = 0;
> > break;
> > default:
> > qemu_log_mask(LOG_UNIMP,
> > - "%s: un-handled SBI EXIT, specific reasons is %lu\n",
> > + "%s: Unhandled SBI exit with extension-id %lu\n"
> >__func__, run->riscv_sbi.extension_id);
> > -ret = -1;
> > +run->riscv_sbi.ret[0] = SBI_ERR_NOT_SUPPORTED;
> > break;
> > }
> > return ret;
> > diff --git a/target/riscv/sbi_ecall_interface.h
> > b/target/riscv/sbi_ecall_interface.h
> > index 43899d08f6..a2e21d9b8c 100644
> > --- a/target/riscv/sbi_ecall_interface.h
> > +++ b/target/riscv/sbi_ecall_interface.h
> > @@ -69,4 +69,16 @@
> > #define SBI_EXT_VENDOR_END 0x09FF
> > /* clang-format on */
> >
> > +/* SBI return error codes */
> > +#define SBI_SUCCESS 0
> > +#define SBI_ERR_FAILURE -1
> > +#define SBI_ERR_NOT_SUPPORTED -2
> > +#define SBI_ERR_INVALID_PARAM -3
> > +#define SBI_ERR_DENIED -4
> > +#define SBI_ERR_INVALID_ADDRESS -5
> > +#define SBI_ERR_ALREADY_AVAILABLE -6
> > +#define SBI_ERR_ALREADY_STARTED -7
> > +#define SBI_ERR_ALREADY_STOPPED -8
> > +#define SBI_ERR_NO_SHMEM-9
> > +
> > #endif
> > --
> > 2.34.1
> >
Re: [PATCH v3] target/riscv: Raise exceptions on wrs.nto
On Wed, Apr 24, 2024 at 04:28:09PM +0200, Andrew Jones wrote:
> Implementing wrs.nto to always just return is consistent with the
> specification, as the instruction is permitted to terminate the
> stall for any reason, but it's not useful for virtualization, where
> we'd like the guest to trap to the hypervisor in order to allow
> scheduling of the lock holding VCPU. Change to always immediately
> raise exceptions when the appropriate conditions are present,
> otherwise continue to just return. Note, immediately raising
> exceptions is also consistent with the specification since the
> time limit that should expire prior to the exception is
> implementation-specific.
>
> Signed-off-by: Andrew Jones
> Reviewed-by: Christoph M??llner
> ---
> v3:
> - Sending again, hoping the ?? remains in M??llner
This looks like my mail reader (neomutt)'s problem. The patch was correct
(also for v2) and other readers render it correctly. Sorry for the noise.
Thanks,
drew
> v2:
> - Added #ifndef CONFIG_USER_ONLY around helper call
>
> target/riscv/helper.h | 1 +
> target/riscv/insn_trans/trans_rvzawrs.c.inc | 29 ++---
> target/riscv/op_helper.c| 11
> 3 files changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/target/riscv/helper.h b/target/riscv/helper.h
> index 8a635238514d..451261ce5a4f 100644
> --- a/target/riscv/helper.h
> +++ b/target/riscv/helper.h
> @@ -132,6 +132,7 @@ DEF_HELPER_6(csrrw_i128, tl, env, int, tl, tl, tl, tl)
> DEF_HELPER_1(sret, tl, env)
> DEF_HELPER_1(mret, tl, env)
> DEF_HELPER_1(wfi, void, env)
> +DEF_HELPER_1(wrs_nto, void, env)
> DEF_HELPER_1(tlb_flush, void, env)
> DEF_HELPER_1(tlb_flush_all, void, env)
> /* Native Debug */
> diff --git a/target/riscv/insn_trans/trans_rvzawrs.c.inc
> b/target/riscv/insn_trans/trans_rvzawrs.c.inc
> index 32efbff4d5a5..0eef03383889 100644
> --- a/target/riscv/insn_trans/trans_rvzawrs.c.inc
> +++ b/target/riscv/insn_trans/trans_rvzawrs.c.inc
> @@ -16,7 +16,7 @@
> * this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> -static bool trans_wrs(DisasContext *ctx)
> +static bool trans_wrs_sto(DisasContext *ctx, arg_wrs_sto *a)
> {
> if (!ctx->cfg_ptr->ext_zawrs) {
> return false;
> @@ -40,12 +40,23 @@ static bool trans_wrs(DisasContext *ctx)
> return true;
> }
>
> -#define GEN_TRANS_WRS(insn) \
> -static bool trans_ ## insn(DisasContext *ctx, arg_ ## insn *a) \
> -{ \
> -(void)a;\
> -return trans_wrs(ctx); \
> -}
> +static bool trans_wrs_nto(DisasContext *ctx, arg_wrs_nto *a)
> +{
> +if (!ctx->cfg_ptr->ext_zawrs) {
> +return false;
> +}
>
> -GEN_TRANS_WRS(wrs_nto)
> -GEN_TRANS_WRS(wrs_sto)
> +/*
> + * Depending on the mode of execution, mstatus.TW and hstatus.VTW,
> wrs.nto
> + * should raise an exception when the implementation-specific bounded
> time
> + * limit has expired. Our time limit is zero, so we either return
> + * immediately, as does our implementation of wrs.sto, or raise an
> + * exception, as handled by the wrs.nto helper.
> + */
> +#ifndef CONFIG_USER_ONLY
> +gen_helper_wrs_nto(tcg_env);
> +#endif
> +
> +/* We only get here when helper_wrs_nto() doesn't raise an exception. */
> +return trans_wrs_sto(ctx, NULL);
> +}
> diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
> index f414aaebdbab..2baf5bc3ca19 100644
> --- a/target/riscv/op_helper.c
> +++ b/target/riscv/op_helper.c
> @@ -380,6 +380,17 @@ void helper_wfi(CPURISCVState *env)
> }
> }
>
> +void helper_wrs_nto(CPURISCVState *env)
> +{
> +if (env->virt_enabled && (env->priv == PRV_S || env->priv == PRV_U) &&
> +get_field(env->hstatus, HSTATUS_VTW) &&
> +!get_field(env->mstatus, MSTATUS_TW)) {
> +riscv_raise_exception(env, RISCV_EXCP_VIRT_INSTRUCTION_FAULT,
> GETPC());
> +} else if (env->priv != PRV_M && get_field(env->mstatus, MSTATUS_TW)) {
> +riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC());
> +}
> +}
> +
> void helper_tlb_flush(CPURISCVState *env)
> {
> CPUState *cs = env_cpu(env);
> --
> 2.44.0
>
[PATCH v3] target/riscv: Raise exceptions on wrs.nto
Implementing wrs.nto to always just return is consistent with the
specification, as the instruction is permitted to terminate the
stall for any reason, but it's not useful for virtualization, where
we'd like the guest to trap to the hypervisor in order to allow
scheduling of the lock holding VCPU. Change to always immediately
raise exceptions when the appropriate conditions are present,
otherwise continue to just return. Note, immediately raising
exceptions is also consistent with the specification since the
time limit that should expire prior to the exception is
implementation-specific.
Signed-off-by: Andrew Jones
Reviewed-by: Christoph Müllner
---
v3:
- Sending again, hoping the ü remains in Müllner
v2:
- Added #ifndef CONFIG_USER_ONLY around helper call
target/riscv/helper.h | 1 +
target/riscv/insn_trans/trans_rvzawrs.c.inc | 29 ++---
target/riscv/op_helper.c| 11
3 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 8a635238514d..451261ce5a4f 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -132,6 +132,7 @@ DEF_HELPER_6(csrrw_i128, tl, env, int, tl, tl, tl, tl)
DEF_HELPER_1(sret, tl, env)
DEF_HELPER_1(mret, tl, env)
DEF_HELPER_1(wfi, void, env)
+DEF_HELPER_1(wrs_nto, void, env)
DEF_HELPER_1(tlb_flush, void, env)
DEF_HELPER_1(tlb_flush_all, void, env)
/* Native Debug */
diff --git a/target/riscv/insn_trans/trans_rvzawrs.c.inc
b/target/riscv/insn_trans/trans_rvzawrs.c.inc
index 32efbff4d5a5..0eef03383889 100644
--- a/target/riscv/insn_trans/trans_rvzawrs.c.inc
+++ b/target/riscv/insn_trans/trans_rvzawrs.c.inc
@@ -16,7 +16,7 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
-static bool trans_wrs(DisasContext *ctx)
+static bool trans_wrs_sto(DisasContext *ctx, arg_wrs_sto *a)
{
if (!ctx->cfg_ptr->ext_zawrs) {
return false;
@@ -40,12 +40,23 @@ static bool trans_wrs(DisasContext *ctx)
return true;
}
-#define GEN_TRANS_WRS(insn) \
-static bool trans_ ## insn(DisasContext *ctx, arg_ ## insn *a) \
-{ \
-(void)a;\
-return trans_wrs(ctx); \
-}
+static bool trans_wrs_nto(DisasContext *ctx, arg_wrs_nto *a)
+{
+if (!ctx->cfg_ptr->ext_zawrs) {
+return false;
+}
-GEN_TRANS_WRS(wrs_nto)
-GEN_TRANS_WRS(wrs_sto)
+/*
+ * Depending on the mode of execution, mstatus.TW and hstatus.VTW, wrs.nto
+ * should raise an exception when the implementation-specific bounded time
+ * limit has expired. Our time limit is zero, so we either return
+ * immediately, as does our implementation of wrs.sto, or raise an
+ * exception, as handled by the wrs.nto helper.
+ */
+#ifndef CONFIG_USER_ONLY
+gen_helper_wrs_nto(tcg_env);
+#endif
+
+/* We only get here when helper_wrs_nto() doesn't raise an exception. */
+return trans_wrs_sto(ctx, NULL);
+}
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index f414aaebdbab..2baf5bc3ca19 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -380,6 +380,17 @@ void helper_wfi(CPURISCVState *env)
}
}
+void helper_wrs_nto(CPURISCVState *env)
+{
+if (env->virt_enabled && (env->priv == PRV_S || env->priv == PRV_U) &&
+get_field(env->hstatus, HSTATUS_VTW) &&
+!get_field(env->mstatus, MSTATUS_TW)) {
+riscv_raise_exception(env, RISCV_EXCP_VIRT_INSTRUCTION_FAULT, GETPC());
+} else if (env->priv != PRV_M && get_field(env->mstatus, MSTATUS_TW)) {
+riscv_raise_exception(env, RISCV_EXCP_ILLEGAL_INST, GETPC());
+}
+}
+
void helper_tlb_flush(CPURISCVState *env)
{
CPUState *cs = env_cpu(env);
--
2.44.0
Re: [PATCH] target/riscv/kvm: tolerate KVM disable ext errors
On Mon, Apr 22, 2024 at 11:08:31AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 4/22/24 10:43, Andrew Jones wrote:
> > On Mon, Apr 22, 2024 at 10:12:53AM -0300, Daniel Henrique Barboza wrote:
> > > Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
> > > enabled, will fail with a kernel oops SIGILL right at the start. The
> > > reason is that we can't expose zkr without implementing the SEED CSR.
> > > Disabling zkr in the guest would be a workaround, but if the KVM doesn't
> > > allow it we'll error out and never boot.
> > >
> > > In hindsight this is too strict. If we keep proceeding, despite not
> > > disabling the extension in the KVM vcpu, we'll not add extension in
> > ^ the
> > > riscv,isa. The guest kernel will be unaware of the extension, i.e. it
> > ^ the
> >
> > > doesn't matter if the KVM vcpu has it enabled underneath or not. So it's
> > > ok to keep booting in this case.
> > >
> > > Change our current logic to not error out if we fail to disable an
> > > extension in kvm_set_one_reg(): throw an warning instead and keep
> > > booting. We'll keep the existing behavior when we fail to enable an
> > > extension in KVM, since adding the extension in riscv,isa at this point
> > > will cause a guest malfunction because the extension isn't enabled in
> > > the vcpu.
> >
> > I'd probably add a sentence or two explaining why we still want to warn,
> > which is because KVM is stating that while you may think you're disabling
> > an extension, that extension's behavior (instructions, etc.) will still
> > be exposed to the guest since there's no way not to expose it. The user
> > should be aware that a guest could use it anyway, since that means the
> > attempt to disable it can't be relied upon for migration compatibility of
> > arbitrary guests. The guest needs to be well behaved, i.e. one that won't
> > try to use any extensions which aren't in the ISA string. So, disabling
> > these types of extensions either shouldn't generally be done (so a noisy
> > warning helps prohibit that) or done for debug purposes (where a noisy
> > warning is fine).
>
> I'll add this in the next version.
>
> >
> > >
> > > Suggested-by: Andrew Jones
> > > Signed-off-by: Daniel Henrique Barboza
> > > ---
> > > target/riscv/kvm/kvm-cpu.c | 12
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> > > index 6a6c6cae80..261ca24504 100644
> > > --- a/target/riscv/kvm/kvm-cpu.c
> > > +++ b/target/riscv/kvm/kvm-cpu.c
> > > @@ -427,10 +427,14 @@ static void
> > > kvm_riscv_update_cpu_cfg_isa_ext(RISCVCPU *cpu, CPUState *cs)
> > > reg = kvm_cpu_cfg_get(cpu, multi_ext_cfg);
> > > ret = kvm_set_one_reg(cs, id, );
> > > if (ret != 0) {
> > > -error_report("Unable to %s extension %s in KVM, error %d",
> > > - reg ? "enable" : "disable",
> > > - multi_ext_cfg->name, ret);
> > > -exit(EXIT_FAILURE);
> > > +if (reg) {
> > > +error_report("Unable to enable extension %s in KVM,
> > > error %d",
> > > + multi_ext_cfg->name, ret);
> > > +exit(EXIT_FAILURE);
> > > +} else {
> >
> > Maybe we should check for a specific error. Is it EINVAL? If we do, then
> > the message below would drop the (error %d) part and instead state
> > explicitly that it cannot disable this extension since it's not possible.
>
> It's throwing a 22 (EINVAL).
>
> >
> > > +warn_report("KVM did not disable extension %s (error
> > > %d)",
> >
> > s/did not/cannot/
> >
> > > +multi_ext_cfg->name, ret);
> > > +}
>
>
> I don't mind rephrasing it to "The KVM module is not able to disable
> extension %s"
> But I'm unsure what we gain from not showing the error code.
>
> Aside EINVAL the other (very unlikely) error code being thrown would be
> EBUSY. Should
> we handle EBUSY differently in this case? I don't think so. If we're already
> throwing a
> warning, with error code, the user is well informed about the guest having a
> flaky
> start and can proceed with discretion. Regardless of the extension
> disablement failing
> due to EINVAL or EBUSY.
But EBUSY means the VMM messed up and tried to do something it shouldn't,
which is to change the configuration of the VCPU after it already ran.
EINVAL isn't a VMM mess up. It wanted to disable the extension and will
remove it from the ISA string, KVM just can't guarantee that the guest
won't be able to use it anyway (making that a warn case). So, EBUSY isn't
a warn case (but it's also not something we'd expect to see in a function
called from kvm_arch_init_vcpu()). However, KVM is free to add new errors,
so I'd only warn for the ones which translate to warn cases (EINVAL).
Thanks,
drew
[PATCH] target/riscv/kvm: Fix exposure of Zkr
The Zkr extension may only be exposed to KVM guests if the VMM
implements the SEED CSR. Use the same implementation as TCG.
Without this patch, running with a KVM which does not forward the
SEED CSR access to QEMU will result in an ILL exception being
injected into the guest (this results in Linux guests crashing on
boot). And, when running with a KVM which does forward the access,
QEMU will crash, since QEMU doesn't know what to do with the exit.
Fixes: 3108e2f1c69d ("target/riscv/kvm: update KVM exts to Linux 6.8")
Signed-off-by: Andrew Jones
---
target/riscv/cpu.h | 3 +++
target/riscv/csr.c | 18 ++
target/riscv/kvm/kvm-cpu.c | 25 +
3 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 3b1a02b9449a..52fb8c15d08f 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -821,6 +821,9 @@ void riscv_set_csr_ops(int csrno, riscv_csr_operations
*ops);
void riscv_cpu_register_gdb_regs_for_features(CPUState *cs);
+target_ulong riscv_new_csr_seed(target_ulong new_value,
+target_ulong write_mask);
+
uint8_t satp_mode_max_from_map(uint32_t map);
const char *satp_mode_str(uint8_t satp_mode, bool is_32_bit);
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 726096444fae..829d8346ed4e 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -4267,10 +4267,8 @@ static RISCVException write_upmbase(CPURISCVState *env,
int csrno,
#endif
/* Crypto Extension */
-static RISCVException rmw_seed(CPURISCVState *env, int csrno,
- target_ulong *ret_value,
- target_ulong new_value,
- target_ulong write_mask)
+target_ulong riscv_new_csr_seed(target_ulong new_value,
+target_ulong write_mask)
{
uint16_t random_v;
Error *random_e = NULL;
@@ -4294,6 +4292,18 @@ static RISCVException rmw_seed(CPURISCVState *env, int
csrno,
rval = random_v | SEED_OPST_ES16;
}
+return rval;
+}
+
+static RISCVException rmw_seed(CPURISCVState *env, int csrno,
+ target_ulong *ret_value,
+ target_ulong new_value,
+ target_ulong write_mask)
+{
+target_ulong rval;
+
+rval = riscv_new_csr_seed(new_value, write_mask);
+
if (ret_value) {
*ret_value = rval;
}
diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index 6a6c6cae80f1..50bdbd24a878 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -1418,6 +1418,28 @@ static int kvm_riscv_handle_sbi(CPUState *cs, struct
kvm_run *run)
return ret;
}
+static int kvm_riscv_handle_csr(CPUState *cs, struct kvm_run *run)
+{
+target_ulong csr_num = run->riscv_csr.csr_num;
+target_ulong new_value = run->riscv_csr.new_value;
+target_ulong write_mask = run->riscv_csr.write_mask;
+int ret = 0;
+
+switch (csr_num) {
+case CSR_SEED:
+run->riscv_csr.ret_value = riscv_new_csr_seed(new_value, write_mask);
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+ "%s: un-handled CSR EXIT for CSR %lx\n",
+ __func__, csr_num);
+ret = -1;
+break;
+}
+
+return ret;
+}
+
int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
{
int ret = 0;
@@ -1425,6 +1447,9 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run
*run)
case KVM_EXIT_RISCV_SBI:
ret = kvm_riscv_handle_sbi(cs, run);
break;
+case KVM_EXIT_RISCV_CSR:
+ret = kvm_riscv_handle_csr(cs, run);
+break;
default:
qemu_log_mask(LOG_UNIMP, "%s: un-handled exit reason %d\n",
__func__, run->exit_reason);
--
2.44.0
Re: [PATCH] target/riscv/kvm: tolerate KVM disable ext errors
On Mon, Apr 22, 2024 at 10:12:53AM -0300, Daniel Henrique Barboza wrote:
> Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr
> enabled, will fail with a kernel oops SIGILL right at the start. The
> reason is that we can't expose zkr without implementing the SEED CSR.
> Disabling zkr in the guest would be a workaround, but if the KVM doesn't
> allow it we'll error out and never boot.
>
> In hindsight this is too strict. If we keep proceeding, despite not
> disabling the extension in the KVM vcpu, we'll not add extension in
^ the
> riscv,isa. The guest kernel will be unaware of the extension, i.e. it
^ the
> doesn't matter if the KVM vcpu has it enabled underneath or not. So it's
> ok to keep booting in this case.
>
> Change our current logic to not error out if we fail to disable an
> extension in kvm_set_one_reg(): throw an warning instead and keep
> booting. We'll keep the existing behavior when we fail to enable an
> extension in KVM, since adding the extension in riscv,isa at this point
> will cause a guest malfunction because the extension isn't enabled in
> the vcpu.
I'd probably add a sentence or two explaining why we still want to warn,
which is because KVM is stating that while you may think you're disabling
an extension, that extension's behavior (instructions, etc.) will still
be exposed to the guest since there's no way not to expose it. The user
should be aware that a guest could use it anyway, since that means the
attempt to disable it can't be relied upon for migration compatibility of
arbitrary guests. The guest needs to be well behaved, i.e. one that won't
try to use any extensions which aren't in the ISA string. So, disabling
these types of extensions either shouldn't generally be done (so a noisy
warning helps prohibit that) or done for debug purposes (where a noisy
warning is fine).
>
> Suggested-by: Andrew Jones
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 6a6c6cae80..261ca24504 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -427,10 +427,14 @@ static void kvm_riscv_update_cpu_cfg_isa_ext(RISCVCPU
> *cpu, CPUState *cs)
> reg = kvm_cpu_cfg_get(cpu, multi_ext_cfg);
> ret = kvm_set_one_reg(cs, id, );
> if (ret != 0) {
> -error_report("Unable to %s extension %s in KVM, error %d",
> - reg ? "enable" : "disable",
> - multi_ext_cfg->name, ret);
> -exit(EXIT_FAILURE);
> +if (reg) {
> +error_report("Unable to enable extension %s in KVM, error
> %d",
> + multi_ext_cfg->name, ret);
> +exit(EXIT_FAILURE);
> +} else {
Maybe we should check for a specific error. Is it EINVAL? If we do, then
the message below would drop the (error %d) part and instead state
explicitly that it cannot disable this extension since it's not possible.
> +warn_report("KVM did not disable extension %s (error %d)",
s/did not/cannot/
> +multi_ext_cfg->name, ret);
> +}
> }
> }
> }
> --
> 2.44.0
>
Thanks,
drew
Re: [PATCH v6] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Mon, Apr 22, 2024 at 02:42:54PM +0300, Alexei Filippov wrote:
> kvm_riscv_handle_sbi() may return not supported return code to not
> trigger qemu abort with vendor-specific sbi.
>
> Add new error path to provide proper error in case of
> qemu_chr_fe_read_all() may not return sizeof(ch).
I think something more along the lines of what I wrote in my previous
reply will help clarify this more. Here's what I wrote
"""
Exactly zero just means we failed to read input, which can happen, so
telling the SBI caller we failed to read, but telling the caller of this
function that we successfully emulated the SBI call, is correct. However,
anything else, other than sizeof(ch), means something unexpected happened,
so we should indeed return an error from this function.
"""
Thanks,
drew
>
> Added SBI related return code's defines.
>
> Signed-off-by: Alexei Filippov
> ---
> Changes since v4-5:
> -Added new error path in case of qemu_chr_fe_read_all() may not
> return sizeof(ch).
> -Added more comments in commit message.
> target/riscv/kvm/kvm-cpu.c | 10 ++
> target/riscv/sbi_ecall_interface.h | 12
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index f9dbc18a76..5bb7b74d03 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -1173,16 +1173,18 @@ static int kvm_riscv_handle_sbi(CPUState *cs, struct
> kvm_run *run)
> ret = qemu_chr_fe_read_all(serial_hd(0)->be, , sizeof(ch));
> if (ret == sizeof(ch)) {
> run->riscv_sbi.ret[0] = ch;
> +ret = 0;
> +} else if (ret == 0) {
> +run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
> } else {
> -run->riscv_sbi.ret[0] = -1;
> +ret = -1;
> }
> -ret = 0;
> break;
> default:
> qemu_log_mask(LOG_UNIMP,
> - "%s: un-handled SBI EXIT, specific reasons is %lu\n",
> + "%s: Unhandled SBI exit with extension-id %lu\n"
>__func__, run->riscv_sbi.extension_id);
> -ret = -1;
> +run->riscv_sbi.ret[0] = SBI_ERR_NOT_SUPPORTED;
> break;
> }
> return ret;
> diff --git a/target/riscv/sbi_ecall_interface.h
> b/target/riscv/sbi_ecall_interface.h
> index 43899d08f6..a2e21d9b8c 100644
> --- a/target/riscv/sbi_ecall_interface.h
> +++ b/target/riscv/sbi_ecall_interface.h
> @@ -69,4 +69,16 @@
> #define SBI_EXT_VENDOR_END 0x09FF
> /* clang-format on */
>
> +/* SBI return error codes */
> +#define SBI_SUCCESS 0
> +#define SBI_ERR_FAILURE -1
> +#define SBI_ERR_NOT_SUPPORTED -2
> +#define SBI_ERR_INVALID_PARAM -3
> +#define SBI_ERR_DENIED -4
> +#define SBI_ERR_INVALID_ADDRESS -5
> +#define SBI_ERR_ALREADY_AVAILABLE -6
> +#define SBI_ERR_ALREADY_STARTED -7
> +#define SBI_ERR_ALREADY_STOPPED -8
> +#define SBI_ERR_NO_SHMEM-9
> +
> #endif
> --
> 2.34.1
>
Re: [PATCH v4] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Mon, Apr 22, 2024 at 01:55:31PM +1000, Alistair Francis wrote:
> On Sat, Apr 13, 2024 at 9:26 PM Alexei Filippov
> wrote:
> >
> > kvm_riscv_handle_sbi() may return not supported return code to not trigger
> > qemu abort with vendor-specific sbi.
> >
> > Added SBI related return code's defines.
> >
> > Signed-off-by: Alexei Filippov
> > Fixes: 4eb47125 ("target/riscv: Handle KVM_EXIT_RISCV_SBI exit")
> > ---
> >
> > Changes since v3:
> > -Clear Reviewed-by tags
> > target/riscv/kvm/kvm-cpu.c | 13 +
> > target/riscv/sbi_ecall_interface.h | 12
> > 2 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> > index 6a6c6cae80..844942d9ba 100644
> > --- a/target/riscv/kvm/kvm-cpu.c
> > +++ b/target/riscv/kvm/kvm-cpu.c
> > @@ -1392,7 +1392,6 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cs)
> >
> > static int kvm_riscv_handle_sbi(CPUState *cs, struct kvm_run *run)
> > {
> > -int ret = 0;
> > unsigned char ch;
> > switch (run->riscv_sbi.extension_id) {
> > case SBI_EXT_0_1_CONSOLE_PUTCHAR:
> > @@ -1400,22 +1399,20 @@ static int kvm_riscv_handle_sbi(CPUState *cs,
> > struct kvm_run *run)
> > qemu_chr_fe_write(serial_hd(0)->be, , sizeof(ch));
> > break;
> > case SBI_EXT_0_1_CONSOLE_GETCHAR:
> > -ret = qemu_chr_fe_read_all(serial_hd(0)->be, , sizeof(ch));
> > -if (ret == sizeof(ch)) {
> > +if (qemu_chr_fe_read_all(serial_hd(0)->be, , sizeof(ch)) ==
> > sizeof(ch)) {
> > run->riscv_sbi.ret[0] = ch;
> > } else {
> > -run->riscv_sbi.ret[0] = -1;
> > +run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
>
> I'm not sure I follow. This seems like a failure but we report success
> to the caller of this function?
>
> Can you expand the commit message to explain why we want this change
Looking at this again, I think it would be more clear, and more correct,
if we only do the SBI_ERR_FAILURE path for a return value of exactly zero.
...
ret = qemu_chr_fe_read_all(...);
if (ret == sizeof(ch)) {
run->riscv_sbi.ret[0] = ch;
ret = 0;
} else if (ret == 0) {
run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
}
break;
...
return ret;
Exactly zero just means we failed to read input, which can happen, so
telling the SBI caller we failed to read, but telling the caller of this
function that we successfully emulated the SBI call, is correct. However,
anything else, other than sizeof(ch), means something unexpected happened,
so we should indeed return an error from this function.
Thanks,
drew
>
> Alistair
>
> > }
> > -ret = 0;
> > break;
> > default:
> > qemu_log_mask(LOG_UNIMP,
> > - "%s: un-handled SBI EXIT, specific reasons is %lu\n",
> > + "%s: Unhandled SBI exit with extension-id %lu\n",
> >__func__, run->riscv_sbi.extension_id);
> > -ret = -1;
> > +run->riscv_sbi.ret[0] = SBI_ERR_NOT_SUPPORTED;
> > break;
> > }
> > -return ret;
> > +return 0;
> > }
> >
> > int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
> > diff --git a/target/riscv/sbi_ecall_interface.h
> > b/target/riscv/sbi_ecall_interface.h
> > index 43899d08f6..a2e21d9b8c 100644
> > --- a/target/riscv/sbi_ecall_interface.h
> > +++ b/target/riscv/sbi_ecall_interface.h
> > @@ -69,4 +69,16 @@
> > #define SBI_EXT_VENDOR_END 0x09FF
> > /* clang-format on */
> >
> > +/* SBI return error codes */
> > +#define SBI_SUCCESS 0
> > +#define SBI_ERR_FAILURE -1
> > +#define SBI_ERR_NOT_SUPPORTED -2
> > +#define SBI_ERR_INVALID_PARAM -3
> > +#define SBI_ERR_DENIED -4
> > +#define SBI_ERR_INVALID_ADDRESS -5
> > +#define SBI_ERR_ALREADY_AVAILABLE -6
> > +#define SBI_ERR_ALREADY_STARTED -7
> > +#define SBI_ERR_ALREADY_STOPPED -8
> > +#define SBI_ERR_NO_SHMEM-9
> > +
> > #endif
> > --
> > 2.34.1
> >
> >
Re: [PATCH v4] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Sat, Apr 13, 2024 at 02:25:26PM +0300, Alexei Filippov wrote:
> kvm_riscv_handle_sbi() may return not supported return code to not trigger
> qemu abort with vendor-specific sbi.
>
> Added SBI related return code's defines.
>
> Signed-off-by: Alexei Filippov
> Fixes: 4eb47125 ("target/riscv: Handle KVM_EXIT_RISCV_SBI exit")
> ---
>
> Changes since v3:
> -Clear Reviewed-by tags
> target/riscv/kvm/kvm-cpu.c | 13 +
> target/riscv/sbi_ecall_interface.h | 12
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
Reviewed-by: Andrew Jones
Re: [PATCH v2] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Mon, Mar 25, 2024 at 04:01:16PM +0300, Alexei Filippov wrote:
> kvm_riscv_handle_sbi() may return not supported return code to not trigger
> qemu abort with vendor-specific sbi.
>
> Added SBI related return code's defines.
>
> Signed-off-by: Alexei Filippov
> Fixes: 4eb47125 ("target/riscv: Handle KVM_EXIT_RISCV_SBI exit")
> Reviewed-by: Daniel Henrique Barboza
> ---
>
> Changes since v1:
> -Add Fixes and Revied-by lines.
> target/riscv/kvm/kvm-cpu.c | 5 +++--
> target/riscv/sbi_ecall_interface.h | 11 +++
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 6a6c6cae80..a4f84ad950 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -1404,7 +1404,7 @@ static int kvm_riscv_handle_sbi(CPUState *cs, struct
> kvm_run *run)
> if (ret == sizeof(ch)) {
> run->riscv_sbi.ret[0] = ch;
> } else {
> -run->riscv_sbi.ret[0] = -1;
> +run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
> }
> ret = 0;
> break;
> @@ -1412,7 +1412,8 @@ static int kvm_riscv_handle_sbi(CPUState *cs, struct
> kvm_run *run)
> qemu_log_mask(LOG_UNIMP,
>"%s: un-handled SBI EXIT, specific reasons is %lu\n",
>__func__, run->riscv_sbi.extension_id);
While changing this, can we also change this log to something like
"%s: Unhandled SBI exit with extension-id %lu\n", __func__,
run->riscv_sbi.extension_id
> -ret = -1;
> +run->riscv_sbi.ret[0] = SBI_ERR_NOT_SUPPORTED;
> +ret = 0;
We don't have any paths that set ret to anything other than zero now.
Let's return zero at the bottom of the function instead. And the top
of the function can then be cleaned up to
unsigned char ch;
int ret;
switch (run->riscv_sbi.extension_id) {
> break;
> }
> return ret;
> diff --git a/target/riscv/sbi_ecall_interface.h
> b/target/riscv/sbi_ecall_interface.h
> index 43899d08f6..0279e92a36 100644
> --- a/target/riscv/sbi_ecall_interface.h
> +++ b/target/riscv/sbi_ecall_interface.h
> @@ -69,4 +69,15 @@
> #define SBI_EXT_VENDOR_END 0x09FF
> /* clang-format on */
>
> +/* SBI return error codes */
> +#define SBI_SUCCESS 0
> +#define SBI_ERR_FAILURE -1
> +#define SBI_ERR_NOT_SUPPORTED -2
> +#define SBI_ERR_INVALID_PARAM -3
> +#define SBI_ERR_DENIED -4
> +#define SBI_ERR_INVALID_ADDRESS -5
> +#define SBI_ERR_ALREADY_AVAILABLE -6
> +#define SBI_ERR_ALREADY_STARTED -7
> +#define SBI_ERR_ALREADY_STOPPED -8
v2 of the spec has SBI_ERR_NO_SHMEM as well.
Thanks,
drew
> +
> #endif
> --
> 2.34.1
>
>
Re: [PATCH v7 4/4] target/riscv: Enable sdtrig for Ventana's Veyron CPUs
On Fri, Mar 15, 2024 at 12:29:57AM +0530, Himanshu Chauhan wrote: > Ventana's Veyron CPUs support sdtrig ISA extension. By default, enable > the sdtrig extension and disable the debug property for these CPUs. You still have the 'and disable the debug property' here... > > Signed-off-by: Himanshu Chauhan > --- > target/riscv/cpu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > index 4231f36c1b..c9dda73748 100644 > --- a/target/riscv/cpu.c > +++ b/target/riscv/cpu.c > @@ -569,6 +569,7 @@ static void rv64_veyron_v1_cpu_init(Object *obj) > cpu->cfg.cbom_blocksize = 64; > cpu->cfg.cboz_blocksize = 64; > cpu->cfg.ext_zicboz = true; > +cpu->cfg.ext_sdtrig = true; > cpu->cfg.ext_smaia = true; > cpu->cfg.ext_ssaia = true; > cpu->cfg.ext_sscofpmf = true; > -- > 2.34.1 >
Re: [PATCH v7 3/4] target/riscv: Expose sdtrig ISA extension
On Fri, Mar 15, 2024 at 12:29:56AM +0530, Himanshu Chauhan wrote:
> This patch adds "sdtrig" in the ISA string when sdtrig extension is enabled.
> The sdtrig extension may or may not be implemented in a system. Therefore, the
>-cpu rv64,sdtrig=
> option can be used to dynamically turn sdtrig extension on or off.
>
> By default, the sdtrig extension is disabled and debug property enabled as
> usual.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index ab631500ac..4231f36c1b 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -175,6 +175,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zvkt, PRIV_VERSION_1_12_0, ext_zvkt),
> ISA_EXT_DATA_ENTRY(zhinx, PRIV_VERSION_1_12_0, ext_zhinx),
> ISA_EXT_DATA_ENTRY(zhinxmin, PRIV_VERSION_1_12_0, ext_zhinxmin),
> +ISA_EXT_DATA_ENTRY(sdtrig, PRIV_VERSION_1_12_0, ext_sdtrig),
So we're sure this should be 1.12? Or do we need to introduce
PRIV_VERSION_1_13_0?
> ISA_EXT_DATA_ENTRY(smaia, PRIV_VERSION_1_12_0, ext_smaia),
> ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
> ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
> @@ -1485,6 +1486,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> MULTI_EXT_CFG_BOOL("zvfhmin", ext_zvfhmin, false),
> MULTI_EXT_CFG_BOOL("sstc", ext_sstc, true),
>
> +MULTI_EXT_CFG_BOOL("sdtrig", ext_sdtrig, false),
> MULTI_EXT_CFG_BOOL("smaia", ext_smaia, false),
> MULTI_EXT_CFG_BOOL("smepmp", ext_smepmp, false),
> MULTI_EXT_CFG_BOOL("smstateen", ext_smstateen, false),
> --
> 2.34.1
>
Thanks,
drew
Re: [PATCH v7 2/4] target/riscv: Enable mcontrol6 triggers only when sdtrig is selected
On Fri, Mar 15, 2024 at 12:29:55AM +0530, Himanshu Chauhan wrote:
> The mcontrol6 triggers are not defined in debug specification v0.13
> These triggers are defined in sdtrig ISA extension.
>
> This patch:
>* Adds ext_sdtrig capability which is used to select mcontrol6 triggers
>* Keeps the debug property. All triggers that are defined in v0.13 are
> exposed.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 5 +
> target/riscv/cpu_cfg.h | 1 +
> target/riscv/debug.c | 30 +-
> 3 files changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index c160b9216b..ab631500ac 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1008,6 +1008,11 @@ static void riscv_cpu_reset_hold(Object *obj)
> set_default_nan_mode(1, >fp_status);
>
> #ifndef CONFIG_USER_ONLY
> +if (!cpu->cfg.debug && cpu->cfg.ext_sdtrig) {
> +warn_report("Enabling 'debug' since 'sdtrig' is enabled.");
> +cpu->cfg.debug = true;
> +}
> +
> if (cpu->cfg.debug) {
> riscv_trigger_reset_hold(env);
> }
> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> index 2040b90da0..0c57e1acd4 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -114,6 +114,7 @@ struct RISCVCPUConfig {
> bool ext_zvfbfwma;
> bool ext_zvfh;
> bool ext_zvfhmin;
> +bool ext_sdtrig;
> bool ext_smaia;
> bool ext_ssaia;
> bool ext_sscofpmf;
> diff --git a/target/riscv/debug.c b/target/riscv/debug.c
> index 5f14b39b06..c40e727e12 100644
> --- a/target/riscv/debug.c
> +++ b/target/riscv/debug.c
> @@ -100,13 +100,16 @@ static trigger_action_t
> get_trigger_action(CPURISCVState *env,
> target_ulong tdata1 = env->tdata1[trigger_index];
> int trigger_type = get_trigger_type(env, trigger_index);
> trigger_action_t action = DBG_ACTION_NONE;
> +const RISCVCPUConfig *cfg = riscv_cpu_cfg(env);
>
> switch (trigger_type) {
> case TRIGGER_TYPE_AD_MATCH:
> action = (tdata1 & TYPE2_ACTION) >> 12;
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -action = (tdata1 & TYPE6_ACTION) >> 12;
> +if (cfg->ext_sdtrig) {
> +action = (tdata1 & TYPE6_ACTION) >> 12;
> +}
> break;
> case TRIGGER_TYPE_INST_CNT:
> case TRIGGER_TYPE_INT:
> @@ -727,7 +730,12 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
> type2_reg_write(env, env->trigger_cur, tdata_index, val);
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +if (riscv_cpu_cfg(env)->ext_sdtrig) {
> +type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +} else {
> +qemu_log_mask(LOG_UNIMP, "trigger type: %d is not supported\n",
> + trigger_type);
> +}
> break;
> case TRIGGER_TYPE_INST_CNT:
> itrigger_reg_write(env, env->trigger_cur, tdata_index, val);
> @@ -750,9 +758,13 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
>
> target_ulong tinfo_csr_read(CPURISCVState *env)
> {
> -/* assume all triggers support the same types of triggers */
> -return BIT(TRIGGER_TYPE_AD_MATCH) |
> - BIT(TRIGGER_TYPE_AD_MATCH6);
> +target_ulong ts = BIT(TRIGGER_TYPE_AD_MATCH);
> +
> +if (riscv_cpu_cfg(env)->ext_sdtrig) {
> +ts |= BIT(TRIGGER_TYPE_AD_MATCH6);
> +}
> +
> +return ts;
> }
>
> void riscv_cpu_debug_excp_handler(CPUState *cs)
> @@ -803,6 +815,10 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
> }
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> +if (!cpu->cfg.ext_sdtrig) {
> +break;
> +}
> +
> ctrl = env->tdata1[i];
> pc = env->tdata2[i];
>
> @@ -869,6 +885,10 @@ bool riscv_cpu_debug_check_watchpoint(CPUState *cs,
> CPUWatchpoint *wp)
> }
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> +if (!cpu->cfg.ext_sdtrig) {
> +break;
> +}
> +
> ctrl = env->tdata1[i];
> addr = env->tdata2[i];
> flags = 0;
> --
> 2.34.1
>
Reviewed-by: Andrew Jones
Re: [PATCH v6 3/3] target/riscv: Enable sdtrig for Ventana's Veyron CPUs
On Thu, Mar 14, 2024 at 05:05:10PM +0530, Himanshu Chauhan wrote: > Ventana's Veyron CPUs support sdtrig ISA extension. By default, enable > the sdtrig extension and disable the debug property for these CPUs. The commit message needs to be updated to remove the 'and disable the debug property'. > > Signed-off-by: Himanshu Chauhan > --- > target/riscv/cpu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > index 66c91fffd6..3c7ad1c903 100644 > --- a/target/riscv/cpu.c > +++ b/target/riscv/cpu.c > @@ -569,6 +569,7 @@ static void rv64_veyron_v1_cpu_init(Object *obj) > cpu->cfg.cbom_blocksize = 64; > cpu->cfg.cboz_blocksize = 64; > cpu->cfg.ext_zicboz = true; > +cpu->cfg.ext_sdtrig = true; > cpu->cfg.ext_smaia = true; > cpu->cfg.ext_ssaia = true; > cpu->cfg.ext_sscofpmf = true; > -- > 2.34.1 > Thanks, drew
Re: [PATCH v6 2/3] target/riscv: Expose sdtrig ISA extension
On Thu, Mar 14, 2024 at 05:05:09PM +0530, Himanshu Chauhan wrote:
> This patch adds "sdtrig" in the ISA string when sdtrig extension is enabled.
> The sdtrig extension may or may not be implemented in a system. Therefore, the
>-cpu rv64,sdtrig=
> option can be used to dynamically turn sdtrig extension on or off.
>
> Since, the sdtrig ISA extension is a superset of debug specification, disable
> the debug property when sdtrig is enabled. A warning is printed when this is
> done.
>
> By default, the sdtrig extension is disabled and debug property enabled as
> usual.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 2602aae9f5..66c91fffd6 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -175,6 +175,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zvkt, PRIV_VERSION_1_12_0, ext_zvkt),
> ISA_EXT_DATA_ENTRY(zhinx, PRIV_VERSION_1_12_0, ext_zhinx),
> ISA_EXT_DATA_ENTRY(zhinxmin, PRIV_VERSION_1_12_0, ext_zhinxmin),
> +ISA_EXT_DATA_ENTRY(sdtrig, PRIV_VERSION_1_12_0, ext_sdtrig),
sdtrig isn't in 1.12, is it? I think it's 1.13. Hmm, I wonder if we don't
need to audit all our recently added extensions to make sure they're
actually 1.12, since we don't have PRIV_VERSION_1_13_0 defined...
> ISA_EXT_DATA_ENTRY(smaia, PRIV_VERSION_1_12_0, ext_smaia),
> ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
> ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
> @@ -1008,6 +1009,11 @@ static void riscv_cpu_reset_hold(Object *obj)
> set_default_nan_mode(1, >fp_status);
>
> #ifndef CONFIG_USER_ONLY
> +if (!cpu->cfg.debug && cpu->cfg.ext_sdtrig) {
> +warn_report("Enabling 'debug' since 'sdtrig' is enabled.");
> +cpu->cfg.debug = true;
> +}
> +
> if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_reset_hold(env);
> }
> @@ -1480,6 +1486,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> MULTI_EXT_CFG_BOOL("zvfhmin", ext_zvfhmin, false),
> MULTI_EXT_CFG_BOOL("sstc", ext_sstc, true),
>
> +MULTI_EXT_CFG_BOOL("sdtrig", ext_sdtrig, false),
> MULTI_EXT_CFG_BOOL("smaia", ext_smaia, false),
> MULTI_EXT_CFG_BOOL("smepmp", ext_smepmp, false),
> MULTI_EXT_CFG_BOOL("smstateen", ext_smstateen, false),
> --
> 2.34.1
>
Thanks,
drew
Re: [PATCH v6 1/3] target/riscv: Enable mcontrol6 triggers only when sdtrig is selected
On Thu, Mar 14, 2024 at 05:05:08PM +0530, Himanshu Chauhan wrote:
> The mcontrol6 triggers are not defined in debug specification v0.13
> These triggers are defined in sdtrig ISA extension.
>
> This patch:
>* Adds ext_sdtrig capability which is used to select mcontrol6 triggers
>* Keeps the debug property. All triggers that are defined in v0.13 are
> exposed.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 4 +-
> target/riscv/cpu_cfg.h | 1 +
> target/riscv/csr.c | 2 +-
> target/riscv/debug.c | 90 +-
> 4 files changed, 57 insertions(+), 40 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index c160b9216b..2602aae9f5 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1008,7 +1008,7 @@ static void riscv_cpu_reset_hold(Object *obj)
> set_default_nan_mode(1, >fp_status);
>
> #ifndef CONFIG_USER_ONLY
> -if (cpu->cfg.debug) {
> +if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
I still don't see the point of adding '|| cpu->cfg.ext_sdtrig'. debug must
be true when ext_sdtrig is true.
> riscv_trigger_reset_hold(env);
> }
>
> @@ -1168,7 +1168,7 @@ static void riscv_cpu_realize(DeviceState *dev, Error
> **errp)
> riscv_cpu_register_gdb_regs_for_features(cs);
>
> #ifndef CONFIG_USER_ONLY
> -if (cpu->cfg.debug) {
> +if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_realize(>env);
> }
> #endif
> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> index 2040b90da0..0c57e1acd4 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -114,6 +114,7 @@ struct RISCVCPUConfig {
> bool ext_zvfbfwma;
> bool ext_zvfh;
> bool ext_zvfhmin;
> +bool ext_sdtrig;
> bool ext_smaia;
> bool ext_ssaia;
> bool ext_sscofpmf;
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index 726096444f..26623d3640 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -546,7 +546,7 @@ static RISCVException have_mseccfg(CPURISCVState *env,
> int csrno)
>
> static RISCVException debug(CPURISCVState *env, int csrno)
> {
> -if (riscv_cpu_cfg(env)->debug) {
> +if (riscv_cpu_cfg(env)->debug || riscv_cpu_cfg(env)->ext_sdtrig) {
> return RISCV_EXCP_NONE;
> }
>
> diff --git a/target/riscv/debug.c b/target/riscv/debug.c
> index e30d99cc2f..674223e966 100644
> --- a/target/riscv/debug.c
> +++ b/target/riscv/debug.c
> @@ -100,13 +100,15 @@ static trigger_action_t
> get_trigger_action(CPURISCVState *env,
> target_ulong tdata1 = env->tdata1[trigger_index];
> int trigger_type = get_trigger_type(env, trigger_index);
> trigger_action_t action = DBG_ACTION_NONE;
> +const RISCVCPUConfig *cfg = riscv_cpu_cfg(env);
>
> switch (trigger_type) {
> case TRIGGER_TYPE_AD_MATCH:
> action = (tdata1 & TYPE2_ACTION) >> 12;
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -action = (tdata1 & TYPE6_ACTION) >> 12;
> +if (cfg->ext_sdtrig)
> +action = (tdata1 & TYPE6_ACTION) >> 12;
QEMU requires {}, even for single line blocks. I'm not sure if QEMU's
checkpatch is smart enough to complain about that, but if you haven't
run checkpatch, then you probably should.
> break;
> case TRIGGER_TYPE_INST_CNT:
> case TRIGGER_TYPE_INT:
> @@ -727,7 +729,12 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
> type2_reg_write(env, env->trigger_cur, tdata_index, val);
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +if (riscv_cpu_cfg(env)->ext_sdtrig) {
> +type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +} else {
> +qemu_log_mask(LOG_UNIMP, "trigger type: %d is not supported\n",
> + trigger_type);
> +}
> break;
> case TRIGGER_TYPE_INST_CNT:
> itrigger_reg_write(env, env->trigger_cur, tdata_index, val);
> @@ -750,9 +757,14 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
>
> target_ulong tinfo_csr_read(CPURISCVState *env)
> {
> -/* assume all triggers support the same types of triggers */
> -return BIT(TRIGGER_TYPE_AD_MATCH) |
> - BIT(TRIGGER_TYPE_AD_MATCH6);
> +target_ulong ts = 0;
Useless initialization to zero since it's assigned in the next line.
Actually, should just do
target_ulong ts = BIT(TRIGGER_TYPE_AD_MATCH);
> +
> +ts = BIT(TRIGGER_TYPE_AD_MATCH);
> +
> +if (riscv_cpu_cfg(env)->ext_sdtrig)
> +ts |= BIT(TRIGGER_TYPE_AD_MATCH6);
Need {}
> +
> +return ts;
> }
>
> void riscv_cpu_debug_excp_handler(CPUState *cs)
> @@ -803,19 +815,21 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
> }
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -
Re: [PATCH for-9.0] target/riscv: do not enable all named features by default
On Tue, Mar 12, 2024 at 05:32:14PM -0300, Daniel Henrique Barboza wrote:
> Commit 3b8022269c added the capability of named features/profile
> extensions to be added in riscv,isa. To do that we had to assign priv
> versions for each one of them in isa_edata_arr[]. But this resulted in a
> side-effect: vendor CPUs that aren't running priv_version_latest started
> to experience warnings for these profile extensions [1]:
>
> | $ qemu-system-riscv32 -M sifive_e
> | qemu-system-riscv32: warning: disabling zic64b extension for hart
> 0x because privilege spec version does not match
> | qemu-system-riscv32: warning: disabling ziccamoa extension for
> hart 0x because privilege spec version does not match
>
> This is benign as far as the CPU behavior is concerned since disabling
> both extensions is a no-op (aside from riscv,isa). But the warnings are
> unpleasant to deal with, especially because we're sending user warnings
> for extensions that users can't enable/disable.
>
> Instead of enabling all named features all the time, separate them by
> priv version. During finalize() time, after we decided which
> priv_version the CPU is running, enable/disable all the named extensions
> based on the priv spec chosen. This will be enough for a bug fix, but as
> a future work we should look into how we can name these extensions in a
> way that we don't need an explicit ext_name => priv_ver as we're doing
> here.
>
> The named extensions being added in isa_edata_arr[] that will be
> enabled/disabled based solely on priv version can be removed from
> riscv_cpu_named_features[]. 'zic64b' is an extension that can be
> disabled based on block sizes so it'll retain its own flag and entry.
>
> [1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg02592.html
>
> Reported-by: Clément Chigot
> Fixes: 3b8022269c ("target/riscv: add riscv,isa to named features")
> Suggested-by: Andrew Jones
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 40 +-
> target/riscv/cpu_cfg.h | 8 +---
> target/riscv/tcg/tcg-cpu.c | 14 ++---
> 3 files changed, 25 insertions(+), 37 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 5a48d30828..1da5417764 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -102,10 +102,10 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zicbom, PRIV_VERSION_1_12_0, ext_zicbom),
> ISA_EXT_DATA_ENTRY(zicbop, PRIV_VERSION_1_12_0, ext_zicbop),
> ISA_EXT_DATA_ENTRY(zicboz, PRIV_VERSION_1_12_0, ext_zicboz),
> -ISA_EXT_DATA_ENTRY(ziccamoa, PRIV_VERSION_1_11_0, ext_always_enabled),
> -ISA_EXT_DATA_ENTRY(ziccif, PRIV_VERSION_1_11_0, ext_always_enabled),
> -ISA_EXT_DATA_ENTRY(zicclsm, PRIV_VERSION_1_11_0, ext_always_enabled),
> -ISA_EXT_DATA_ENTRY(ziccrse, PRIV_VERSION_1_11_0, ext_always_enabled),
> +ISA_EXT_DATA_ENTRY(ziccamoa, PRIV_VERSION_1_11_0, has_priv_1_11),
> +ISA_EXT_DATA_ENTRY(ziccif, PRIV_VERSION_1_11_0, has_priv_1_11),
> +ISA_EXT_DATA_ENTRY(zicclsm, PRIV_VERSION_1_11_0, has_priv_1_11),
> +ISA_EXT_DATA_ENTRY(ziccrse, PRIV_VERSION_1_11_0, has_priv_1_11),
> ISA_EXT_DATA_ENTRY(zicond, PRIV_VERSION_1_12_0, ext_zicond),
> ISA_EXT_DATA_ENTRY(zicntr, PRIV_VERSION_1_12_0, ext_zicntr),
> ISA_EXT_DATA_ENTRY(zicsr, PRIV_VERSION_1_10_0, ext_zicsr),
> @@ -114,7 +114,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zihintpause, PRIV_VERSION_1_10_0, ext_zihintpause),
> ISA_EXT_DATA_ENTRY(zihpm, PRIV_VERSION_1_12_0, ext_zihpm),
> ISA_EXT_DATA_ENTRY(zmmul, PRIV_VERSION_1_12_0, ext_zmmul),
> -ISA_EXT_DATA_ENTRY(za64rs, PRIV_VERSION_1_12_0, ext_always_enabled),
> +ISA_EXT_DATA_ENTRY(za64rs, PRIV_VERSION_1_12_0, has_priv_1_11),
> ISA_EXT_DATA_ENTRY(zaamo, PRIV_VERSION_1_12_0, ext_zaamo),
> ISA_EXT_DATA_ENTRY(zacas, PRIV_VERSION_1_12_0, ext_zacas),
> ISA_EXT_DATA_ENTRY(zalrsc, PRIV_VERSION_1_12_0, ext_zalrsc),
> @@ -179,12 +179,12 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
> ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
> ISA_EXT_DATA_ENTRY(ssaia, PRIV_VERSION_1_12_0, ext_ssaia),
> -ISA_EXT_DATA_ENTRY(ssccptr, PRIV_VERSION_1_11_0, ext_always_enabled),
> +ISA_EXT_DATA_ENTRY(ssccptr, PRIV_VERSION_1_11_0, has_priv_1_11),
> ISA_EXT_DATA_ENTRY(sscofpmf, PRIV_VERSION_1_12_0, ext_sscofpmf),
> -ISA_EXT_DATA_ENTRY(sscounterenw, PRIV_VERSION_1_12_0,
> ext_always_enabled),
> +ISA_EXT_DATA_ENTRY(sscounterenw, PRIV_VERSION_1_12_0, has_priv_1_12),
> ISA_EXT_DATA_ENTRY(sstc,
Re: [PATCH v5 3/3] target/riscv: Enable sdtrig for Ventana's Veyron CPUs
On Wed, Mar 13, 2024 at 11:50:09PM +0530, Himanshu Chauhan wrote: > Ventana's Veyron CPUs support sdtrig ISA extension. By default, enable > the sdtrig extension and disable the debug property for these CPUs. > > Signed-off-by: Himanshu Chauhan > --- > target/riscv/cpu.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > index e0710010f5..a7ea66c7fa 100644 > --- a/target/riscv/cpu.c > +++ b/target/riscv/cpu.c > @@ -568,7 +568,9 @@ static void rv64_veyron_v1_cpu_init(Object *obj) > cpu->cfg.ext_zicbom = true; > cpu->cfg.cbom_blocksize = 64; > cpu->cfg.cboz_blocksize = 64; > +cpu->cfg.debug = false; We don't want/need the above line. Veyron does support 'debug' since it supports 'sdtrig'. And removing the line above allows all the '|| cfg->ext_sdtrig' to also be removed. Thanks, drew > cpu->cfg.ext_zicboz = true; > +cpu->cfg.ext_sdtrig = true; > cpu->cfg.ext_smaia = true; > cpu->cfg.ext_ssaia = true; > cpu->cfg.ext_sscofpmf = true; > -- > 2.34.1 > >
Re: [PATCH v5 2/3] target/riscv: Expose sdtrig ISA extension
On Wed, Mar 13, 2024 at 11:50:08PM +0530, Himanshu Chauhan wrote:
> This patch adds "sdtrig" in the ISA string when sdtrig extension is enabled.
> The sdtrig extension may or may not be implemented in a system. Therefore, the
>-cpu rv64,sdtrig=
> option can be used to dynamically turn sdtrig extension on or off.
>
> Since, the sdtrig ISA extension is a superset of debug specification, disable
> the debug property when sdtrig is enabled. A warning is printed when this is
> done.
>
> By default, the sdtrig extension is disabled and debug property enabled as
> usual.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 2602aae9f5..e0710010f5 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -175,6 +175,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zvkt, PRIV_VERSION_1_12_0, ext_zvkt),
> ISA_EXT_DATA_ENTRY(zhinx, PRIV_VERSION_1_12_0, ext_zhinx),
> ISA_EXT_DATA_ENTRY(zhinxmin, PRIV_VERSION_1_12_0, ext_zhinxmin),
> +ISA_EXT_DATA_ENTRY(sdtrig, PRIV_VERSION_1_12_0, ext_sdtrig),
> ISA_EXT_DATA_ENTRY(smaia, PRIV_VERSION_1_12_0, ext_smaia),
> ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
> ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
> @@ -1008,6 +1009,10 @@ static void riscv_cpu_reset_hold(Object *obj)
> set_default_nan_mode(1, >fp_status);
>
> #ifndef CONFIG_USER_ONLY
> +if (!cpu->cfg.debug && cpu->cfg.ext_sdtrig) {
> + cpu->cfg.debug = 1;
nit: '= true'
I also wonder if we need a warning here that says something like
"reenabling 'debug' since 'sdtrig' is enabled...", since the only way we'd
get here is if the user did 'debug=off,sdtrig=on'. But, I think I might be
OK with just silently ignoring that 'debug=off' too.
Thanks,
drew
> +}
> +
> if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_reset_hold(env);
> }
> @@ -1480,6 +1485,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> MULTI_EXT_CFG_BOOL("zvfhmin", ext_zvfhmin, false),
> MULTI_EXT_CFG_BOOL("sstc", ext_sstc, true),
>
> +MULTI_EXT_CFG_BOOL("sdtrig", ext_sdtrig, false),
> MULTI_EXT_CFG_BOOL("smaia", ext_smaia, false),
> MULTI_EXT_CFG_BOOL("smepmp", ext_smepmp, false),
> MULTI_EXT_CFG_BOOL("smstateen", ext_smstateen, false),
> --
> 2.34.1
>
>
Re: [PATCH v5 1/3] target/riscv: Enable mcontrol6 triggers only when sdtrig is selected
On Wed, Mar 13, 2024 at 11:50:07PM +0530, Himanshu Chauhan wrote:
> The mcontrol6 triggers are not defined in debug specification v0.13
> These triggers are defined in sdtrig ISA extension.
>
> This patch:
>* Adds ext_sdtrig capability which is used to select mcontrol6 triggers
>* Keeps the debug property. All triggers that are defined in v0.13 are
> exposed.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 4 +-
> target/riscv/cpu_cfg.h | 1 +
> target/riscv/csr.c | 2 +-
> target/riscv/debug.c | 90 +-
> target/riscv/machine.c | 2 +-
> 5 files changed, 58 insertions(+), 41 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index c160b9216b..2602aae9f5 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1008,7 +1008,7 @@ static void riscv_cpu_reset_hold(Object *obj)
> set_default_nan_mode(1, >fp_status);
>
> #ifndef CONFIG_USER_ONLY
> -if (cpu->cfg.debug) {
> +if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_reset_hold(env);
> }
>
> @@ -1168,7 +1168,7 @@ static void riscv_cpu_realize(DeviceState *dev, Error
> **errp)
> riscv_cpu_register_gdb_regs_for_features(cs);
>
> #ifndef CONFIG_USER_ONLY
> -if (cpu->cfg.debug) {
> +if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_realize(>env);
> }
> #endif
> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> index 2040b90da0..0c57e1acd4 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -114,6 +114,7 @@ struct RISCVCPUConfig {
> bool ext_zvfbfwma;
> bool ext_zvfh;
> bool ext_zvfhmin;
> +bool ext_sdtrig;
> bool ext_smaia;
> bool ext_ssaia;
> bool ext_sscofpmf;
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index 726096444f..26623d3640 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -546,7 +546,7 @@ static RISCVException have_mseccfg(CPURISCVState *env,
> int csrno)
>
> static RISCVException debug(CPURISCVState *env, int csrno)
> {
> -if (riscv_cpu_cfg(env)->debug) {
> +if (riscv_cpu_cfg(env)->debug || riscv_cpu_cfg(env)->ext_sdtrig) {
> return RISCV_EXCP_NONE;
> }
>
> diff --git a/target/riscv/debug.c b/target/riscv/debug.c
> index e30d99cc2f..674223e966 100644
> --- a/target/riscv/debug.c
> +++ b/target/riscv/debug.c
> @@ -100,13 +100,15 @@ static trigger_action_t
> get_trigger_action(CPURISCVState *env,
> target_ulong tdata1 = env->tdata1[trigger_index];
> int trigger_type = get_trigger_type(env, trigger_index);
> trigger_action_t action = DBG_ACTION_NONE;
> +const RISCVCPUConfig *cfg = riscv_cpu_cfg(env);
>
> switch (trigger_type) {
> case TRIGGER_TYPE_AD_MATCH:
> action = (tdata1 & TYPE2_ACTION) >> 12;
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -action = (tdata1 & TYPE6_ACTION) >> 12;
> +if (cfg->ext_sdtrig)
> +action = (tdata1 & TYPE6_ACTION) >> 12;
> break;
> case TRIGGER_TYPE_INST_CNT:
> case TRIGGER_TYPE_INT:
> @@ -727,7 +729,12 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
> type2_reg_write(env, env->trigger_cur, tdata_index, val);
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +if (riscv_cpu_cfg(env)->ext_sdtrig) {
> +type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +} else {
> +qemu_log_mask(LOG_UNIMP, "trigger type: %d is not supported\n",
> + trigger_type);
> +}
> break;
> case TRIGGER_TYPE_INST_CNT:
> itrigger_reg_write(env, env->trigger_cur, tdata_index, val);
> @@ -750,9 +757,14 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
>
> target_ulong tinfo_csr_read(CPURISCVState *env)
> {
> -/* assume all triggers support the same types of triggers */
> -return BIT(TRIGGER_TYPE_AD_MATCH) |
> - BIT(TRIGGER_TYPE_AD_MATCH6);
> +target_ulong ts = 0;
> +
> +ts = BIT(TRIGGER_TYPE_AD_MATCH);
> +
> +if (riscv_cpu_cfg(env)->ext_sdtrig)
> +ts |= BIT(TRIGGER_TYPE_AD_MATCH6);
> +
> +return ts;
> }
>
> void riscv_cpu_debug_excp_handler(CPUState *cs)
> @@ -803,19 +815,21 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
> }
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -ctrl = env->tdata1[i];
> -pc = env->tdata2[i];
> -
> -if ((ctrl & TYPE6_EXEC) && (bp->pc == pc)) {
> -if (env->virt_enabled) {
> -/* check VU/VS bit against current privilege level */
> -if ((ctrl >> 23) & BIT(env->priv)) {
> -return true;
> -}
> -
Re: [PATCH v4 2/3] target/riscv: Expose sdtrig ISA extension
On Wed, Mar 13, 2024 at 05:48:16PM +0530, Himanshu Chauhan wrote:
...
> #ifndef CONFIG_USER_ONLY
> +if (cpu->cfg.debug && cpu->cfg.ext_sdtrig) {
> + warn_report("Disabling debug property since sdtrig ISA
> >>> extension "
> + "is enabled");
> + cpu->cfg.debug = 0;
> >>>
> >>> If sdtrig is a superset of debug, then why do we need to disable debug?
> >>>
> >>
> >> "debug" is not disabled. The flag is turned off. This is for unambiguity
> >> between which spec is in force currently.
> >> May come handy (not now but later) in if conditions.
> >
> > I know sdtrig/debug functionality remains enabled, but why state that the
> > 'debug' functionality is no longer enabled?
>
> Got it. The warning can be removed.
>
> > If sdtrig is a superset, then,
> > when it's enabled, both the debug functionality and the sdtrig
> > functionality are enabled. Actually, sdtrig should do the opposite, it
> > should ensure debug=true. The warning would look odd to users that know
>
> I would disagree to set debug=true when sdtrig is selected. These are two
> different specifications and should be treated so. Sdtrig is a superset now
> but may have another revision not backward compatible. For two different
> specifications and flags should mirror the same. On the same lines, this
> patch (as it does) should keep (cfg->debug || cfg->sdtrig) which shows that
> you are dealing with two different specifications. They behave same for some
> triggers but are still different. Deprecation isn’t a problem now or later.
sdtrig is frozen, otherwise it would require the 'x-' prefix, so it can
no longer change in a substantial way and therefore if it's a superset of
debug now then it always will be. If a change is made to "debug
functionality" then it will get a new extension name which may not be
compatible with either 'debug' or 'sdtrig', however that's not the case
here. If a platform supports 'sdtrig', then it supports 'debug', as
'sdtrig' is a superset of 'debug'. Pretending like they're mutually
exclusive doesn't make sense when they completely overlap. Indeed
platform's will likely *want* to advertise that they are compatible with
both because software that is only compatible with 'debug' will need to
know if it will work or not. A platform that says it's not compatible
with 'debug', when it is, because it supports sdtrig, is limiting the
software that will run on it for no reason.
Thanks,
drew
>
> > this and the debug=off would also look odd in the results of cpu model
> > expansion. Keeping debug=true would also avoid needing to change all the
> > if cpu->cfg.debug conditions to if cpu->cfg.debug || cpu->cfg.ext_sdtrig.
> >
> > If we deprecate 'debug' someday, then we'll add a warning for when
> > there is 'debug' explicitly enabled by a user and also for 'debug'
> > configs which lack 'sdtrig', but we don't need to worry about that now.
> >
> > Thanks,
> > drew
>
>
Re: [PATCH v4 2/3] target/riscv: Expose sdtrig ISA extension
On Wed, Mar 13, 2024 at 03:50:16PM +0530, Himanshu Chauhan wrote:
> On Wed, Mar 13, 2024 at 3:24 PM Andrew Jones
> wrote:
>
> > On Wed, Mar 13, 2024 at 11:39:30AM +0530, Himanshu Chauhan wrote:
> > > This patch adds "sdtrig" in the ISA string when sdtrig extension is
> > enabled.
> > > The sdtrig extension may or may not be implemented in a system.
> > Therefore, the
> > >-cpu rv64,sdtrig=
> > > option can be used to dynamically turn sdtrig extension on or off.
> > >
> > > Since, the sdtrig ISA extension is a superset of debug specification,
> > disable
> > > the debug property when sdtrig is enabled. A warning is printed when
> > this is
> > > done.
> > >
> > > By default, the sdtrig extension is disabled and debug property enabled
> > as usual.
> > >
> > > Signed-off-by: Himanshu Chauhan
> > > ---
> > > target/riscv/cpu.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > > index 2602aae9f5..ab057a0926 100644
> > > --- a/target/riscv/cpu.c
> > > +++ b/target/riscv/cpu.c
> > > @@ -175,6 +175,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> > > ISA_EXT_DATA_ENTRY(zvkt, PRIV_VERSION_1_12_0, ext_zvkt),
> > > ISA_EXT_DATA_ENTRY(zhinx, PRIV_VERSION_1_12_0, ext_zhinx),
> > > ISA_EXT_DATA_ENTRY(zhinxmin, PRIV_VERSION_1_12_0, ext_zhinxmin),
> > > +ISA_EXT_DATA_ENTRY(sdtrig, PRIV_VERSION_1_12_0, ext_sdtrig),
> > > ISA_EXT_DATA_ENTRY(smaia, PRIV_VERSION_1_12_0, ext_smaia),
> > > ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
> > > ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
> > > @@ -1008,6 +1009,12 @@ static void riscv_cpu_reset_hold(Object *obj)
> > > set_default_nan_mode(1, >fp_status);
> > >
> > > #ifndef CONFIG_USER_ONLY
> > > +if (cpu->cfg.debug && cpu->cfg.ext_sdtrig) {
> > > + warn_report("Disabling debug property since sdtrig ISA
> > extension "
> > > + "is enabled");
> > > + cpu->cfg.debug = 0;
> >
> > If sdtrig is a superset of debug, then why do we need to disable debug?
> >
>
> "debug" is not disabled. The flag is turned off. This is for unambiguity
> between which spec is in force currently.
> May come handy (not now but later) in if conditions.
I know sdtrig/debug functionality remains enabled, but why state that the
'debug' functionality is no longer enabled? If sdtrig is a superset, then,
when it's enabled, both the debug functionality and the sdtrig
functionality are enabled. Actually, sdtrig should do the opposite, it
should ensure debug=true. The warning would look odd to users that know
this and the debug=off would also look odd in the results of cpu model
expansion. Keeping debug=true would also avoid needing to change all the
if cpu->cfg.debug conditions to if cpu->cfg.debug || cpu->cfg.ext_sdtrig.
If we deprecate 'debug' someday, then we'll add a warning for when
there is 'debug' explicitly enabled by a user and also for 'debug'
configs which lack 'sdtrig', but we don't need to worry about that now.
Thanks,
drew
Re: [PATCH v4 3/3] target/riscv: Enable sdtrig for Ventana's Veyron CPUs
On Wed, Mar 13, 2024 at 11:39:31AM +0530, Himanshu Chauhan wrote: > Ventana's Veyron CPUs support sdtrig ISA extension. By default, enable > the sdtrig extension and disable the debug property for these CPUs. > > Signed-off-by: Himanshu Chauhan > --- > target/riscv/cpu.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > index ab057a0926..9ddebe468b 100644 > --- a/target/riscv/cpu.c > +++ b/target/riscv/cpu.c > @@ -568,7 +568,9 @@ static void rv64_veyron_v1_cpu_init(Object *obj) > cpu->cfg.ext_zicbom = true; > cpu->cfg.cbom_blocksize = 64; > cpu->cfg.cboz_blocksize = 64; > +cpu->cfg.debug=false; Need spaces around '=' > cpu->cfg.ext_zicboz = true; > +cpu->cfg.ext_sdtrig = true; > cpu->cfg.ext_smaia = true; > cpu->cfg.ext_ssaia = true; > cpu->cfg.ext_sscofpmf = true; > -- > 2.34.1 > > Thanks, drew
Re: [PATCH v4 2/3] target/riscv: Expose sdtrig ISA extension
On Wed, Mar 13, 2024 at 11:39:30AM +0530, Himanshu Chauhan wrote:
> This patch adds "sdtrig" in the ISA string when sdtrig extension is enabled.
> The sdtrig extension may or may not be implemented in a system. Therefore, the
>-cpu rv64,sdtrig=
> option can be used to dynamically turn sdtrig extension on or off.
>
> Since, the sdtrig ISA extension is a superset of debug specification, disable
> the debug property when sdtrig is enabled. A warning is printed when this is
> done.
>
> By default, the sdtrig extension is disabled and debug property enabled as
> usual.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 2602aae9f5..ab057a0926 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -175,6 +175,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zvkt, PRIV_VERSION_1_12_0, ext_zvkt),
> ISA_EXT_DATA_ENTRY(zhinx, PRIV_VERSION_1_12_0, ext_zhinx),
> ISA_EXT_DATA_ENTRY(zhinxmin, PRIV_VERSION_1_12_0, ext_zhinxmin),
> +ISA_EXT_DATA_ENTRY(sdtrig, PRIV_VERSION_1_12_0, ext_sdtrig),
> ISA_EXT_DATA_ENTRY(smaia, PRIV_VERSION_1_12_0, ext_smaia),
> ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
> ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
> @@ -1008,6 +1009,12 @@ static void riscv_cpu_reset_hold(Object *obj)
> set_default_nan_mode(1, >fp_status);
>
> #ifndef CONFIG_USER_ONLY
> +if (cpu->cfg.debug && cpu->cfg.ext_sdtrig) {
> + warn_report("Disabling debug property since sdtrig ISA extension "
> + "is enabled");
> + cpu->cfg.debug = 0;
If sdtrig is a superset of debug, then why do we need to disable debug?
Thanks,
drew
> +}
> +
> if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_reset_hold(env);
> }
> @@ -1480,6 +1487,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> MULTI_EXT_CFG_BOOL("zvfhmin", ext_zvfhmin, false),
> MULTI_EXT_CFG_BOOL("sstc", ext_sstc, true),
>
> +MULTI_EXT_CFG_BOOL("sdtrig", ext_sdtrig, false),
> MULTI_EXT_CFG_BOOL("smaia", ext_smaia, false),
> MULTI_EXT_CFG_BOOL("smepmp", ext_smepmp, false),
> MULTI_EXT_CFG_BOOL("smstateen", ext_smstateen, false),
> --
> 2.34.1
>
>
Re: [PATCH v4 1/3] target/riscv: Enable mcontrol6 triggers only when sdtrig is selected
On Wed, Mar 13, 2024 at 11:39:29AM +0530, Himanshu Chauhan wrote:
> The mcontrol6 triggers are not defined in debug specification v0.13
> These triggers are defined in sdtrig ISA extension.
>
> This patch:
>* Adds ext_sdtrig capability which is used to select mcontrol6 triggers
>* Keeps the debug property. All triggers that are defined in v0.13 are
> exposed.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 4 +-
> target/riscv/cpu_cfg.h | 1 +
> target/riscv/csr.c | 2 +-
> target/riscv/debug.c | 92 +-
> target/riscv/machine.c | 2 +-
> 5 files changed, 60 insertions(+), 41 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index c160b9216b..2602aae9f5 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1008,7 +1008,7 @@ static void riscv_cpu_reset_hold(Object *obj)
> set_default_nan_mode(1, >fp_status);
>
> #ifndef CONFIG_USER_ONLY
> -if (cpu->cfg.debug) {
> +if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_reset_hold(env);
> }
>
> @@ -1168,7 +1168,7 @@ static void riscv_cpu_realize(DeviceState *dev, Error
> **errp)
> riscv_cpu_register_gdb_regs_for_features(cs);
>
> #ifndef CONFIG_USER_ONLY
> -if (cpu->cfg.debug) {
> +if (cpu->cfg.debug || cpu->cfg.ext_sdtrig) {
> riscv_trigger_realize(>env);
> }
> #endif
> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> index 2040b90da0..0c57e1acd4 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -114,6 +114,7 @@ struct RISCVCPUConfig {
> bool ext_zvfbfwma;
> bool ext_zvfh;
> bool ext_zvfhmin;
> +bool ext_sdtrig;
> bool ext_smaia;
> bool ext_ssaia;
> bool ext_sscofpmf;
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index 726096444f..26623d3640 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -546,7 +546,7 @@ static RISCVException have_mseccfg(CPURISCVState *env,
> int csrno)
>
> static RISCVException debug(CPURISCVState *env, int csrno)
> {
> -if (riscv_cpu_cfg(env)->debug) {
> +if (riscv_cpu_cfg(env)->debug || riscv_cpu_cfg(env)->ext_sdtrig) {
> return RISCV_EXCP_NONE;
> }
>
> diff --git a/target/riscv/debug.c b/target/riscv/debug.c
> index e30d99cc2f..c6a92ba0f7 100644
> --- a/target/riscv/debug.c
> +++ b/target/riscv/debug.c
> @@ -100,13 +100,16 @@ static trigger_action_t
> get_trigger_action(CPURISCVState *env,
> target_ulong tdata1 = env->tdata1[trigger_index];
> int trigger_type = get_trigger_type(env, trigger_index);
> trigger_action_t action = DBG_ACTION_NONE;
> +const RISCVCPUConfig *cfg = riscv_cpu_cfg(env);
>
> switch (trigger_type) {
> case TRIGGER_TYPE_AD_MATCH:
> action = (tdata1 & TYPE2_ACTION) >> 12;
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -action = (tdata1 & TYPE6_ACTION) >> 12;
> +/* Only sdtrig ISA extension supports type 6 match */
I'd drop the comment since the if-statement says the same thing.
> +if (cfg->ext_sdtrig)
> +action = (tdata1 & TYPE6_ACTION) >> 12;
> break;
> case TRIGGER_TYPE_INST_CNT:
> case TRIGGER_TYPE_INT:
> @@ -727,7 +730,12 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
> type2_reg_write(env, env->trigger_cur, tdata_index, val);
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +if (riscv_cpu_cfg(env)->ext_sdtrig) {
> +type6_reg_write(env, env->trigger_cur, tdata_index, val);
> +} else {
> +qemu_log_mask(LOG_UNIMP, "trigger type: %d is not supported\n",
> + trigger_type);
> +}
> break;
> case TRIGGER_TYPE_INST_CNT:
> itrigger_reg_write(env, env->trigger_cur, tdata_index, val);
> @@ -750,9 +758,15 @@ void tdata_csr_write(CPURISCVState *env, int
> tdata_index, target_ulong val)
>
> target_ulong tinfo_csr_read(CPURISCVState *env)
> {
> -/* assume all triggers support the same types of triggers */
> -return BIT(TRIGGER_TYPE_AD_MATCH) |
> - BIT(TRIGGER_TYPE_AD_MATCH6);
> +target_ulong ts = 0;
> +
> +ts = BIT(TRIGGER_TYPE_AD_MATCH);
> +
> +/* sdtrig ISA extension supports type 6 match */
Also drop this comment.
> +if (riscv_cpu_cfg(env)->ext_sdtrig)
> +ts |= BIT(TRIGGER_TYPE_AD_MATCH6);
> +
> +return ts;
> }
>
> void riscv_cpu_debug_excp_handler(CPUState *cs)
> @@ -803,19 +817,21 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
> }
> break;
> case TRIGGER_TYPE_AD_MATCH6:
> -ctrl = env->tdata1[i];
> -pc = env->tdata2[i];
> -
> -if ((ctrl & TYPE6_EXEC) && (bp->pc == pc)) {
> -if (env->virt_enabled) {
> -
Re: [PATCH 1/1] target/riscv/kvm: fix timebase-frequency when using KVM acceleration
On Wed, Mar 13, 2024 at 04:13:57PM +0800, Yong-Xuan Wang wrote:
> The timebase-frequency of guest OS should be the same with host
> machine. The timebase-frequency value in DTS should be got from
> hypervisor when using KVM acceleration.
>
> Signed-off-by: Yong-Xuan Wang
> ---
> hw/riscv/virt.c | 11 +--
> target/riscv/kvm/kvm-cpu.c | 9 +
> target/riscv/kvm/kvm_riscv.h | 13 +
> 3 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index a094af97c32a..a7ed7fa13010 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -710,8 +710,15 @@ static void create_fdt_sockets(RISCVVirtState *s, const
> MemMapEntry *memmap,
> int socket_count = riscv_socket_count(ms);
>
> qemu_fdt_add_subnode(ms->fdt, "/cpus");
> -qemu_fdt_setprop_cell(ms->fdt, "/cpus", "timebase-frequency",
> - RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ);
> +
> +if (kvm_enabled()) {
> +qemu_fdt_setprop_cell(ms->fdt, "/cpus", "timebase-frequency",
> + kvm_riscv_get_timebase_frequency(first_cpu));
> +} else {
> +qemu_fdt_setprop_cell(ms->fdt, "/cpus", "timebase-frequency",
> + RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ);
> +}
> +
> qemu_fdt_setprop_cell(ms->fdt, "/cpus", "#size-cells", 0x0);
> qemu_fdt_setprop_cell(ms->fdt, "/cpus", "#address-cells", 0x1);
> qemu_fdt_add_subnode(ms->fdt, "/cpus/cpu-map");
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index c7afdb1e81b7..bbb115eaa867 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -739,6 +739,15 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
> env->kvm_timer_dirty = false;
> }
>
> +uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs)
> +{
> +uint64_t reg;
> +
> +KVM_RISCV_GET_TIMER(cs, frequency, reg);
> +
> +return reg;
> +}
> +
> static int kvm_riscv_get_regs_vector(CPUState *cs)
> {
> RISCVCPU *cpu = RISCV_CPU(cs);
> diff --git a/target/riscv/kvm/kvm_riscv.h b/target/riscv/kvm/kvm_riscv.h
> index 4bd98fddc776..130a4bde0480 100644
> --- a/target/riscv/kvm/kvm_riscv.h
> +++ b/target/riscv/kvm/kvm_riscv.h
> @@ -29,4 +29,17 @@ void riscv_kvm_aplic_request(void *opaque, int irq, int
> level);
> int kvm_riscv_sync_mpstate_to_kvm(RISCVCPU *cpu, int state);
> void riscv_kvm_cpu_finalize_features(RISCVCPU *cpu, Error **errp);
>
> +#ifdef CONFIG_KVM
> +
> +uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs);
> +
> +#else
> +
> +static inline uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs)
> +{
> +g_assert_not_reached();
> +}
> +
> +#endif
> +
I think we've decided we don't need stubs like these since kvm_riscv_*
functions should always be called within 'if (kvm_enabled())' blocks (as
you have above), and then we leave it to the compile testing to point
out kvm function calls without kvm_enabled().
> #endif
> --
> 2.17.1
>
Besides dropping the stubs,
Reviewed-by: Andrew Jones
Thanks,
drew
Re: [PATCH] disas/riscv: Further correction to LUI disassembly
On Mon, Mar 11, 2024 at 11:56:42AM -0700, Richard Bagley wrote: > I have realized that *the patch is indeed a fix*, not a workaround. > > In fact, the argument to LUI and AUIPC in assembly *must* be a number > between [0x0, 0xf]. > RISC-V Assembly Programmer's Manual : Load Upper Immediate's Immediate > <https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#load-upper-immediates-immediate> I think that's just documenting the current behavior, but the behavior (not accepting a signed decimal number for a signed immediate) doesn't appear to be justified, so I think my suggestion in [1] still stands. That said, I don't really have much of a horse in this race so if somebody comes along and closes that BZ with a simple justification of "we, the people that work on this stuff, agreed we prefer the range [0x0, 0xf]", then I won't argue. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30746 Thanks, drew > Signed decimal numbers are programmed as their two's complement. > > I checked: neither GCC nor LLVM will assemble > > > lui x1, -4 > > The LLVM compiled models the arguments to LUI and AUIPC as UIMM (unsigned > immediate) or UIMM20 (20 bit unsigned immediate). > > I should have checked this from the start. I jumped to the conclusion that > both formats (signed decimal, two's complement) for negative arguments > should be supported, and that I was encountering a bug. > I apologize to all for the unnecessary back-and-forth. > > I don't yet see a reason why llvm and gcc could not support a signed number > in decimal format, perhaps requiring a pseudo-instruction. > This might be desirable, if only in support of assembly programming. > On the other hand, it is easy to make the conversion to a two's-complement > number. > > Richard > > On Sat, Mar 9, 2024 at 4:01 AM Andrew Jones wrote: > > > On Fri, Mar 08, 2024 at 08:22:01PM -0800, Richard Bagley wrote: > > > post-nack, one further comment: > > > > > > One could argue that this change also aligns QEMU with supporting tools > > (as > > > Andrew observed), and it makes sense to merge this change into QEMU until > > > those tools update to supporting signed decimal numbers with immediates. > > > > > > As it is, both GNU assembler and the LLVM integrated assembler (or > > llvm-mc) > > > throws an error with examples such as > > > auipc s0, -17 > > > > > > On the other hand, I have only seen this problem with the output of the > > > COLLECT plug-in, not (as yet) with QEMU execution proper. > > > If the problem is confined to COLLECT, perhaps the argument for aligning > > > with other tools is not as strong. > > > > > > In the meantime, I have adjusted my change locally to include AUIPC, and > > > written a substantive, and I hope, clear commit description. > > > If you would like me to resubmit a patch with this updated change, please > > > let me know. > > > > Since the patch is ready for posting, then it might as well be posted > > (even if it may not get merged right away). If the issue arises again, > > then we can refer to the latest proposed patch, which will be preserved > > in the mail archives. > > > > Thanks, > > drew > >
Re: [RISC-V][tech-server-soc] [RISC-V][tech-server-platform] [RFC 1/2] hw/riscv: Add server platform reference machine
On Mon, Mar 11, 2024 at 04:55:24AM -0700, Wu, Fei2 wrote: > On 3/8/2024 5:20 PM, Andrew Jones wrote: > > On Thu, Mar 07, 2024 at 02:26:18PM +0800, Wu, Fei wrote: > >> On 3/7/2024 8:48 AM, Alistair Francis wrote: > >>> On Thu, Mar 7, 2024 at 5:13 AM Atish Kumar Patra > >>> wrote: > >>>> > >>>> On Wed, Mar 6, 2024 at 4:56 AM Wu, Fei wrote: > >>>>> > >>>>> On 3/6/2024 8:19 AM, Alistair Francis wrote: > >>>>>> On Mon, Mar 4, 2024 at 8:28 PM Fei Wu wrote: > > ... > >>>>>>> +config SERVER_PLATFORM_REF > >>>>>>> +bool > >>>>>>> +select RISCV_NUMA > >>>>>>> +select GOLDFISH_RTC > >>>>>>> +select PCI > >>>>>>> +select PCI_EXPRESS_GENERIC_BRIDGE > >>>>>>> +select PFLASH_CFI01 > >>>>>>> +select SERIAL > >>>>>>> +select RISCV_ACLINT > >>>>>>> +select RISCV_APLIC > >>>>>>> +select RISCV_IMSIC > >>>>>>> +select SIFIVE_TEST > >>>>>> > >>>>>> Do we really need SiFive Test in the server platform? > >>>>>> > >>>>> It's used to reset the system, is there any better choice? > >>> > >>> If we add this now we are stuck with it forever (or at least a long > >>> time). So it'd be nice to think about these and decide if these really > >>> are the best way to do things. We don't have to just copy the existing > >>> virt machine. > >>> > >> We need a solution to poweroff/reboot, and sifive test is one of the > >> hardware implementations, so in general I think it's okay. But I agree > >> Sifive test looks a device for testing only. > >> > >>> There must be a more standard way to do this then MMIO mapped SiFive > >>> hardware? > >>> > >> The mapped MMIO mechanism leveraged by Sifive test by itself is kinda > >> generic, the sbsa_ec for sbsa-ref is also an MMIO mapped device. These > >> two devices look very similar except different encodings of the > >> shutdown/reboot command. > >> > >> Probably we can have a generic shutdown/reboot device in QEMU for both > >> sifive test and sbsa_ec, and likely more (not in this patch series). In > >> this way, sifive test device will be replaced by this more generic > >> device. Any suggestions? > > > > Operating systems shouldn't need to implement odd-ball device drivers to > > function on a reference of a standard platform. So the reference platform > > should only be comprised of devices which have specifications and already, > > or will, have DT bindings. Generic devices would be best, but I don't > > think it should be a problem to use devices from multiple vendors. The > > devices just need to allow GPL drivers to be written. With all that in > > mind, what about adding a generic GPIO controller or using SiFive's GPIO > > controller. Then, we could add gpio-restart and gpio-poweroff. > > > I agree with most of what you said. Regarding generic devices, syscon > looks a better choice than gpio in the current situation. > > Linux kernel has these configurations enabled for virt, and I'm not > going to add a new soc for this new board currently, we can use the same > syscon interface for power, and it has already well supported. > > config SOC_VIRT > bool "QEMU Virt Machine" > select CLINT_TIMER if RISCV_M_MODE > select POWER_RESET > select POWER_RESET_SYSCON > select POWER_RESET_SYSCON_POWEROFF > select GOLDFISH > > For the qemu part, we can remove device 'sifive_test' and manage that > memory region directly with MemoryRegionOps, similar to what > hw/mips/boston.c does. OK, that sounds good. Also, I guess the real concern is whether firmware (e.g. OpenSBI) supports the platform's power-off device, since firmware will present the SRST SBI call to Linux, so Linux doesn't need to worry about it at all. However, if we want Linux to worry about it, then we can't forget to ensure we can implement the syscon interface in AML for ACPI too. Indeed, we should be introducing ACPI support for this reference machine type at the same time we introduce the machine in order to ensure all device selections have, or will have, both DT and ACPI support. Thanks, drew
Re: [PATCH] disas/riscv: Further correction to LUI disassembly
On Fri, Mar 08, 2024 at 08:22:01PM -0800, Richard Bagley wrote: > post-nack, one further comment: > > One could argue that this change also aligns QEMU with supporting tools (as > Andrew observed), and it makes sense to merge this change into QEMU until > those tools update to supporting signed decimal numbers with immediates. > > As it is, both GNU assembler and the LLVM integrated assembler (or llvm-mc) > throws an error with examples such as > auipc s0, -17 > > On the other hand, I have only seen this problem with the output of the > COLLECT plug-in, not (as yet) with QEMU execution proper. > If the problem is confined to COLLECT, perhaps the argument for aligning > with other tools is not as strong. > > In the meantime, I have adjusted my change locally to include AUIPC, and > written a substantive, and I hope, clear commit description. > If you would like me to resubmit a patch with this updated change, please > let me know. Since the patch is ready for posting, then it might as well be posted (even if it may not get merged right away). If the issue arises again, then we can refer to the latest proposed patch, which will be preserved in the mail archives. Thanks, drew
Re: [RFC 1/2] hw/riscv: Add server platform reference machine
On Thu, Mar 07, 2024 at 02:26:18PM +0800, Wu, Fei wrote: > On 3/7/2024 8:48 AM, Alistair Francis wrote: > > On Thu, Mar 7, 2024 at 5:13 AM Atish Kumar Patra > > wrote: > >> > >> On Wed, Mar 6, 2024 at 4:56 AM Wu, Fei wrote: > >>> > >>> On 3/6/2024 8:19 AM, Alistair Francis wrote: > On Mon, Mar 4, 2024 at 8:28 PM Fei Wu wrote: ... > > +config SERVER_PLATFORM_REF > > +bool > > +select RISCV_NUMA > > +select GOLDFISH_RTC > > +select PCI > > +select PCI_EXPRESS_GENERIC_BRIDGE > > +select PFLASH_CFI01 > > +select SERIAL > > +select RISCV_ACLINT > > +select RISCV_APLIC > > +select RISCV_IMSIC > > +select SIFIVE_TEST > > Do we really need SiFive Test in the server platform? > > >>> It's used to reset the system, is there any better choice? > > > > If we add this now we are stuck with it forever (or at least a long > > time). So it'd be nice to think about these and decide if these really > > are the best way to do things. We don't have to just copy the existing > > virt machine. > > > We need a solution to poweroff/reboot, and sifive test is one of the > hardware implementations, so in general I think it's okay. But I agree > Sifive test looks a device for testing only. > > > There must be a more standard way to do this then MMIO mapped SiFive > > hardware? > > > The mapped MMIO mechanism leveraged by Sifive test by itself is kinda > generic, the sbsa_ec for sbsa-ref is also an MMIO mapped device. These > two devices look very similar except different encodings of the > shutdown/reboot command. > > Probably we can have a generic shutdown/reboot device in QEMU for both > sifive test and sbsa_ec, and likely more (not in this patch series). In > this way, sifive test device will be replaced by this more generic > device. Any suggestions? Operating systems shouldn't need to implement odd-ball device drivers to function on a reference of a standard platform. So the reference platform should only be comprised of devices which have specifications and already, or will, have DT bindings. Generic devices would be best, but I don't think it should be a problem to use devices from multiple vendors. The devices just need to allow GPL drivers to be written. With all that in mind, what about adding a generic GPIO controller or using SiFive's GPIO controller. Then, we could add gpio-restart and gpio-poweroff. Thanks, drew
Re: [PATCH v3 0/2] Export debug triggers as an extension
On Thu, Feb 29, 2024 at 07:07:43PM +0530, Himanshu Chauhan wrote: > All the CPUs may or may not implement the debug triggers (sdtrig) > extension. The presence of it should be dynamically detectable. > This patch exports the debug triggers as an extension which > can be turned on or off by sdtrig= option. It is > turned on by default. > > "sdtrig" is concatenated to ISA string when it is enabled. > Like so: > rv64imafdch_zicbom_*_sdtrig_*_sstc_svadu > > Changes from v1: >- Replaced the debug property with ext_sdtrig >- Marked it experimenatal by naming it x-sdtrig >- x-sdtrig is added to ISA string >- Reversed the patch order > > Changes from v2: >- Mark debug property as deprecated and replace internally with sdtrig > extension I'm getting lost in our discussions, but I thought we needed both in case a machine only implements debug 0.13, since sdtrig is at least 'more than' debug, even if backwards compatible (which I also wasn't sure was the case). If, OTOH, QEMU's debug implementation exactly implements sdtrig's specification, then I'm in favor of deprecating the 'debug' extension. Thanks, drew >- setting/unsetting debug property shows warning and sets/unsets ext_sdtrig >- sdtrig is added to ISA string as RISC-V debug specification is frozen > > Himanshu Chauhan (2): > target/riscv: Mark debug property as deprecated > target/riscv: Export sdtrig in ISA string > > target/riscv/cpu.c| 38 +++--- > target/riscv/cpu_cfg.h| 2 +- > target/riscv/cpu_helper.c | 2 +- > target/riscv/csr.c| 2 +- > target/riscv/machine.c| 2 +- > 5 files changed, 39 insertions(+), 7 deletions(-) > > -- > 2.34.1 > >
Re: [PATCH v3 3/6] target/riscv: add remaining named features
On Thu, Feb 15, 2024 at 04:34:32PM +, Conor Dooley wrote: > On Thu, Feb 15, 2024 at 03:26:18PM +0100, Andrew Jones wrote: > > On Thu, Feb 15, 2024 at 01:33:47PM +, Conor Dooley wrote: > > > On Fri, Feb 02, 2024 at 12:21:51PM -0300, Daniel Henrique Barboza wrote: > > > > The RVA22U64 and RVA22S64 profiles mandates certain extensions that, > > > > until now, we were implying that they were available. > > > > > > > > We can't do this anymore since named features also has a riscv,isa > > > > entry. Let's add them to riscv_cpu_named_features[]. > > > > > > > > Instead of adding one bool for each named feature that we'll always > > > > implement, i.e. can't be turned off, add a 'ext_always_enabled' bool in > > > > cpu->cfg. This bool will be set to 'true' in TCG accel init, and all > > > > named features will point to it. This also means that KVM won't see > > > > these features as always enable, which is our intention. > > > > > > > > If any accelerator adds support to disable one of these features, we'll > > > > have to promote them to regular extensions and allow users to disable it > > > > via command line. > > > > > > > > After this patch, here's the riscv,isa from a buildroot using the > > > > 'rva22s64' CPU: > > > > > > Why does an "rva22s64" cpu have "zicclsm" in it? Isn't zicclsm only > > > present in "u" profiles? > > > > "s" profiles mandate all the "u" profile mandatory extensions. For example > > 6.2.2 says > > > > """ > > The RVA22S64 mandatory unprivileged extensions include all the mandatory > > unprivileged > > extensions in RVA22U64. > > """ > > Doesn't that rule out emulating misaligned access in s-mode if you want > to be profile compliant? That's how I interpret it, but I'll defer to a profile spec author, or at least to somebody more confident of their spec interpretation skills. > > > > > # cat /proc/device-tree/cpus/cpu@0/riscv,isa > > > > rv64imafdc_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_ > > > > zicntr_zicsr_zifencei_zihintpause_zihpm_za64rs_zfhmin_zca_zcd_zba_zbb_ > > > > zbs_zkt_ssccptr_sscounterenw_sstvala_sstvecd_svade_svinval_svpbmt# > > > > > > I want to raise my frustration with the crock we've been given here by > > > RVI. Any "named feature" that just creates a name for something that > > > already is assumed is completely useless, and DT property that is used > > > to communicate it's presence cannot be used - instead the property needs > > > to be inverted - indicating the absence of that named feature. > > > > > > Without the inversion, software that parses "riscv,isa" cannot make any > > > determination based on the absence of the property - it could be parsing > > > an old DT that does not have the property or it could be parsing the DT > > > of a system that does not support the extension. > > > > I'm guessing any platform which wants to advertise that it's compliant > > with a profile will update its hardware descriptions to ensure all the > > profile's mandatory extensions are presented. But, I think I understand > > your concern. If somebody is parsing the ISA string as way to determine > > if the platform is compliant with a profile, then they may get a false > > negative due to the ISA string missing a newly named feature. > > Nah, you misunderstand me. I don't care at all about profiles or > checking for compliance with one. I'm only interested in how my software > can check that some feature is (or is not) supported. This creating a name > for something implicit business is not a problem in and of itself, but > putting then into "riscv,isa" is a pointless activity as it communicates > nothing. > > > I'm not > > sure how much of a problem that will be in practice, though, since testing > > for profile compliance, just for the sake of it, doesn't seem very useful. > > Software really only needs to know which extensions are available and if > > it's an old feature that got newly named, then software likely already > > has another way of detecting it. > > Right. That part is fine, but creating extensions for these things we > previously assumed present gives me the impression that creating systems > that do not support these features is valid. IFF that does happen, > removing the string from "riscv,isa" isn't goin
Re: [PATCH v3 3/6] target/riscv: add remaining named features
On Thu, Feb 15, 2024 at 11:13:51AM -0300, Daniel Henrique Barboza wrote: ... > > I want to raise my frustration with the crock we've been given here by > > RVI. Any "named feature" that just creates a name for something that > > already is assumed is completely useless, and DT property that is used > > to communicate it's presence cannot be used - instead the property needs > > to be inverted - indicating the absence of that named feature. > > Let's say that I'm not the biggest fan of how these profile extensions are > being > dealt with in the spec :) the text is vague w.r.t whether zicclsm and others > are actual extensions, or a 'named feature'( like we're calling here in QEMU) > The text is vague, I certainly didn't get it at first, but it's been clarified that these "named features" are considered extensions with the given names and those extensions are ratified at the time the profile in which they first appear is ratified. As I said in my other reply, I hope the need to name old features is behind us now that the first profiles are done. > that is just a glorified way of saying, for example, "zic64b" instead of "all > cache blocks have 64 bytes". The note that accompanies "Zic64b" also states that the cache blocks may be larger or smaller than 64 bytes. So, when a platform includes this "Zic64b" extension in its DT it doesn't mean all blocks are 64 bytes, it means they're all compatible with 64 bytes by either using 64-byte sub- blocks (when they're bigger) or by sequencing cache ops across multiple blocks (when they're smaller). So, while we can derive 'zic64b' from a platform which does have all blocks of size 64, some platforms will need to explicitly add it to the ISA string when they know they're compatible, since they'll be putting other block sizes in the block size descriptions. Thanks, drew
Re: [PATCH v3 3/6] target/riscv: add remaining named features
On Thu, Feb 15, 2024 at 01:33:47PM +, Conor Dooley wrote: > On Fri, Feb 02, 2024 at 12:21:51PM -0300, Daniel Henrique Barboza wrote: > > The RVA22U64 and RVA22S64 profiles mandates certain extensions that, > > until now, we were implying that they were available. > > > > We can't do this anymore since named features also has a riscv,isa > > entry. Let's add them to riscv_cpu_named_features[]. > > > > Instead of adding one bool for each named feature that we'll always > > implement, i.e. can't be turned off, add a 'ext_always_enabled' bool in > > cpu->cfg. This bool will be set to 'true' in TCG accel init, and all > > named features will point to it. This also means that KVM won't see > > these features as always enable, which is our intention. > > > > If any accelerator adds support to disable one of these features, we'll > > have to promote them to regular extensions and allow users to disable it > > via command line. > > > > After this patch, here's the riscv,isa from a buildroot using the > > 'rva22s64' CPU: > > Why does an "rva22s64" cpu have "zicclsm" in it? Isn't zicclsm only > present in "u" profiles? "s" profiles mandate all the "u" profile mandatory extensions. For example 6.2.2 says """ The RVA22S64 mandatory unprivileged extensions include all the mandatory unprivileged extensions in RVA22U64. """ > > > # cat /proc/device-tree/cpus/cpu@0/riscv,isa > > rv64imafdc_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_ > > zicntr_zicsr_zifencei_zihintpause_zihpm_za64rs_zfhmin_zca_zcd_zba_zbb_ > > zbs_zkt_ssccptr_sscounterenw_sstvala_sstvecd_svade_svinval_svpbmt# > > I want to raise my frustration with the crock we've been given here by > RVI. Any "named feature" that just creates a name for something that > already is assumed is completely useless, and DT property that is used > to communicate it's presence cannot be used - instead the property needs > to be inverted - indicating the absence of that named feature. > > Without the inversion, software that parses "riscv,isa" cannot make any > determination based on the absence of the property - it could be parsing > an old DT that does not have the property or it could be parsing the DT > of a system that does not support the extension. I'm guessing any platform which wants to advertise that it's compliant with a profile will update its hardware descriptions to ensure all the profile's mandatory extensions are presented. But, I think I understand your concern. If somebody is parsing the ISA string as way to determine if the platform is compliant with a profile, then they may get a false negative due to the ISA string missing a newly named feature. I'm not sure how much of a problem that will be in practice, though, since testing for profile compliance, just for the sake of it, doesn't seem very useful. Software really only needs to know which extensions are available and if it's an old feature that got newly named, then software likely already has another way of detecting it. > > This is part of why I deprecated `riscv,isa`. It's the same problem as > with "zifencei" et al - does a system with `riscv,isa = "rv64imac"` > support fence.i? Yes, there's a handful of these messy things and the first profiles expose them since they're trying to define them. Fingers crossed that the next profiles won't have to name old features. FWIW, I at least don't see any "This is a new extension name for this feature" notes in the RVA23 profile. Thanks, drew
Re: [PATCH 0/2] RISC-V: Add Ztso extension
On Wed, Feb 14, 2024 at 02:38:34PM +0100, Christoph Müllner wrote: > On Wed, Feb 14, 2024 at 2:35 PM Daniel Henrique Barboza > wrote: > > > > > > > > On 2/7/24 09:22, Christoph Müllner wrote: > > > The first patch of this series picks up an earlier v2 Ztso patch from > > > Palmer, > > > which can be found here: > > > > > > https://patchwork.kernel.org/project/qemu-devel/patch/20220917072635.11616-1-pal...@rivosinc.com/ > > > This patch did not apply cleanly but the necessary changes were trivial. > > > There was a request to extend the commit message, which is part of the > > > posted patch of this series. As this patch was reviewed a year ago, > > > I believe it could be merged. > > > > > > The second patch simply exposes Ztso via hwprobe. > > > > It's also worth mentioning that the second patch relies on: > > > > "[PATCH 0/2] linux-user/riscv: Sync hwprobe keys with kernel" > > > > To be applied beforehand. > > Indeed! Therefore, the end of the cover letter contains the following > paragraph: > """ > This series is based on today's riscv-to-apply.next with my other series > that adds the new hwprobe keys > (https://lists.gnu.org/archive/html/qemu-devel/2024-02/msg01293.html). > """ I think a line like Based-on: 20240207115926.887816-1-christoph.muell...@vrull.eu in the cover letter would allow the automated tools to green-light this series too. Thanks, drew > > To ease reviewing and testing for others, I've also created a remote > branch on GitHub. > > Thanks for reviewing! > > > > > > > > > Thanks, > > > > Daniel > > > > > > > > > > Relevant in this context might be also, that Richard's patch to improve > > > TCG's memory barrier selection depending on host and guest memory ordering > > > landed in June 2023: > > > > > > https://lore.kernel.org/all/a313b36b-dcc1-f812-ccbd-afed1cbd5...@linaro.org/T/ > > > > > > The first patch was already sent as part of an RFC series for Ssdtso: > > >https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg02962.html > > > Since I don't want to keep this patch until the ratification of Ssdtso, > > > I would like to get this merged independent of Ssdtso. > > > > > > This series is based on today's riscv-to-apply.next with my other series > > > that adds the new hwprobe keys > > > (https://lists.gnu.org/archive/html/qemu-devel/2024-02/msg01293.html). > > > > > > This series can also be found here: > > >https://github.com/cmuellner/qemu/tree/ztso > > > > > > Christoph Müllner (1): > > >linux-user/riscv: Add Ztso extension to hwprobe > > > > > > Palmer Dabbelt (1): > > >RISC-V: Add support for Ztso > > > > > > linux-user/syscall.c| 3 +++ > > > target/riscv/cpu.c | 2 ++ > > > target/riscv/cpu_cfg.h | 1 + > > > target/riscv/insn_trans/trans_rva.c.inc | 11 --- > > > target/riscv/insn_trans/trans_rvi.c.inc | 16 ++-- > > > target/riscv/insn_trans/trans_rvv.c.inc | 20 > > > target/riscv/translate.c| 3 +++ > > > 7 files changed, 51 insertions(+), 5 deletions(-) > > >
Re: [PATCH RFC] target: riscv: Add Svvptc extension support
On Tue, Feb 13, 2024 at 03:53:08PM +0100, Alexandre Ghiti wrote:
> The Svvptc extension describes a uarch that does not cache invalid TLB
> entries: that's the case for qemu so there is nothing particular to
> implement other than the introduction of this extension, which is done
> here.
>
> Signed-off-by: Alexandre Ghiti
> ---
>
> That's an RFC since the extension has not been ratified yet.
Hi Alex,
No need for the RFC tag. You can add not-yet-ratified extension support
to QEMU as long as the CPU property is off by default (as you've done)
and you add it to the riscv_cpu_experimental_exts[] array with an "x-"
prefix on its property name.
Thanks,
drew
>
> target/riscv/cpu.c | 2 ++
> target/riscv/cpu_cfg.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 1b8d001d23..4beb5d0350 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -178,6 +178,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(svinval, PRIV_VERSION_1_12_0, ext_svinval),
> ISA_EXT_DATA_ENTRY(svnapot, PRIV_VERSION_1_12_0, ext_svnapot),
> ISA_EXT_DATA_ENTRY(svpbmt, PRIV_VERSION_1_12_0, ext_svpbmt),
> +ISA_EXT_DATA_ENTRY(svvptc, PRIV_VERSION_1_12_0, ext_svvptc),
> ISA_EXT_DATA_ENTRY(xtheadba, PRIV_VERSION_1_11_0, ext_xtheadba),
> ISA_EXT_DATA_ENTRY(xtheadbb, PRIV_VERSION_1_11_0, ext_xtheadbb),
> ISA_EXT_DATA_ENTRY(xtheadbs, PRIV_VERSION_1_11_0, ext_xtheadbs),
> @@ -1467,6 +1468,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> MULTI_EXT_CFG_BOOL("svinval", ext_svinval, false),
> MULTI_EXT_CFG_BOOL("svnapot", ext_svnapot, false),
> MULTI_EXT_CFG_BOOL("svpbmt", ext_svpbmt, false),
> +MULTI_EXT_CFG_BOOL("svvptc", ext_svvptc, false),
>
> MULTI_EXT_CFG_BOOL("zicntr", ext_zicntr, true),
> MULTI_EXT_CFG_BOOL("zihpm", ext_zihpm, true),
> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> index 833bf58217..c973693b6e 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -77,6 +77,7 @@ struct RISCVCPUConfig {
> bool ext_svinval;
> bool ext_svnapot;
> bool ext_svpbmt;
> +bool ext_svvptc;
> bool ext_zdinx;
> bool ext_zaamo;
> bool ext_zacas;
> --
> 2.39.2
>
>
Re: [PATCH v4] target/riscv: mcountinhibit, mcounteren, scounteren, hcounteren is 32-bit
On Fri, Feb 02, 2024 at 02:39:19PM +0300, Vadim Shakirov wrote:
> mcountinhibit, mcounteren, scounteren and hcounteren must always be 32-bit
> by privileged spec
>
> Signed-off-by: Vadim Shakirov
You should have added my and Alistair's tags when reposting.
And you should CC previous reviewers.
Anyway, here's mine again
Reviewed-by: Andrew Jones
drew
> ---
> target/riscv/cpu.h | 8
> target/riscv/machine.c | 16
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 5138187727..cf1867a6e2 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -271,7 +271,7 @@ struct CPUArchState {
> target_ulong hstatus;
> target_ulong hedeleg;
> uint64_t hideleg;
> -target_ulong hcounteren;
> +uint32_t hcounteren;
> target_ulong htval;
> target_ulong htinst;
> target_ulong hgatp;
> @@ -334,10 +334,10 @@ struct CPUArchState {
> */
> bool two_stage_indirect_lookup;
>
> -target_ulong scounteren;
> -target_ulong mcounteren;
> +uint32_t scounteren;
> +uint32_t mcounteren;
>
> -target_ulong mcountinhibit;
> +uint32_t mcountinhibit;
>
> /* PMU counter state */
> PMUCTRState pmu_ctrs[RV_MAX_MHPMCOUNTERS];
> diff --git a/target/riscv/machine.c b/target/riscv/machine.c
> index 72fe2374dc..a4d47ec17e 100644
> --- a/target/riscv/machine.c
> +++ b/target/riscv/machine.c
> @@ -79,14 +79,14 @@ static bool hyper_needed(void *opaque)
>
> static const VMStateDescription vmstate_hyper = {
> .name = "cpu/hyper",
> -.version_id = 3,
> -.minimum_version_id = 3,
> +.version_id = 4,
> +.minimum_version_id = 4,
> .needed = hyper_needed,
> .fields = (const VMStateField[]) {
> VMSTATE_UINTTL(env.hstatus, RISCVCPU),
> VMSTATE_UINTTL(env.hedeleg, RISCVCPU),
> VMSTATE_UINT64(env.hideleg, RISCVCPU),
> -VMSTATE_UINTTL(env.hcounteren, RISCVCPU),
> +VMSTATE_UINT32(env.hcounteren, RISCVCPU),
> VMSTATE_UINTTL(env.htval, RISCVCPU),
> VMSTATE_UINTTL(env.htinst, RISCVCPU),
> VMSTATE_UINTTL(env.hgatp, RISCVCPU),
> @@ -354,8 +354,8 @@ static const VMStateDescription vmstate_jvt = {
>
> const VMStateDescription vmstate_riscv_cpu = {
> .name = "cpu",
> -.version_id = 9,
> -.minimum_version_id = 9,
> +.version_id = 10,
> +.minimum_version_id = 10,
> .post_load = riscv_cpu_post_load,
> .fields = (const VMStateField[]) {
> VMSTATE_UINTTL_ARRAY(env.gpr, RISCVCPU, 32),
> @@ -398,9 +398,9 @@ const VMStateDescription vmstate_riscv_cpu = {
> VMSTATE_UINTTL(env.mtval, RISCVCPU),
> VMSTATE_UINTTL(env.miselect, RISCVCPU),
> VMSTATE_UINTTL(env.siselect, RISCVCPU),
> -VMSTATE_UINTTL(env.scounteren, RISCVCPU),
> -VMSTATE_UINTTL(env.mcounteren, RISCVCPU),
> -VMSTATE_UINTTL(env.mcountinhibit, RISCVCPU),
> +VMSTATE_UINT32(env.scounteren, RISCVCPU),
> +VMSTATE_UINT32(env.mcounteren, RISCVCPU),
> +VMSTATE_UINT32(env.mcountinhibit, RISCVCPU),
> VMSTATE_STRUCT_ARRAY(env.pmu_ctrs, RISCVCPU, RV_MAX_MHPMCOUNTERS, 0,
> vmstate_pmu_ctr_state, PMUCTRState),
> VMSTATE_UINTTL_ARRAY(env.mhpmevent_val, RISCVCPU, RV_MAX_MHPMEVENTS),
> --
> 2.34.1
>
>
Re: [PATCH v3 3/6] target/riscv: add remaining named features
On Fri, Feb 02, 2024 at 12:21:51PM -0300, Daniel Henrique Barboza wrote: > The RVA22U64 and RVA22S64 profiles mandates certain extensions that, > until now, we were implying that they were available. > > We can't do this anymore since named features also has a riscv,isa > entry. Let's add them to riscv_cpu_named_features[]. > > Instead of adding one bool for each named feature that we'll always > implement, i.e. can't be turned off, add a 'ext_always_enabled' bool in > cpu->cfg. This bool will be set to 'true' in TCG accel init, and all > named features will point to it. This also means that KVM won't see > these features as always enable, which is our intention. > > If any accelerator adds support to disable one of these features, we'll > have to promote them to regular extensions and allow users to disable it > via command line. > > After this patch, here's the riscv,isa from a buildroot using the > 'rva22s64' CPU: > > # cat /proc/device-tree/cpus/cpu@0/riscv,isa > rv64imafdc_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_ > zicntr_zicsr_zifencei_zihintpause_zihpm_za64rs_zfhmin_zca_zcd_zba_zbb_ > zbs_zkt_ssccptr_sscounterenw_sstvala_sstvecd_svade_svinval_svpbmt# > > Signed-off-by: Daniel Henrique Barboza > --- > target/riscv/cpu.c | 42 +++--- > target/riscv/cpu_cfg.h | 6 ++ > target/riscv/tcg/tcg-cpu.c | 2 ++ > 3 files changed, 43 insertions(+), 7 deletions(-) > Reviewed-by: Andrew Jones
Re: Re: [PATCH] RISC-V: Report the QEMU vendor/arch IDs on virtual CPUs
On Thu, Feb 01, 2024 at 04:06:15PM +0100, Andrew Jones wrote: > On Wed, Jan 31, 2024 at 10:24:30AM -0800, Palmer Dabbelt wrote: > > Right now we just report 0 for marchid/mvendorid in QEMU. That's legal, > > but it's tricky for users that want to check if they're running on QEMU > > to do so. This sets marchid to 42, which I've proposed as the QEMU > > architecture ID (mvendorid remains 0, just explicitly set, as that's how > > the ISA handles open source implementations). > > Hi Palmer, > > marchid has this text > > """ > Open-source project architecture IDs are allocated globally by RISC-V > International, and have non-zero architecture IDs with a zero > most-significant-bit (MSB). Commercial architecture IDs are allocated > by each commercial vendor independently, but must have the MSB set and > cannot contain zero in the remaining MXLEN-1 bits. > """ > > and mvendorid has this text > > """ > ...a value of 0 can be > returned to indicate the field is not implemented or that this is a > non-commercial implementation. > """ > > We must select zero for mvendorid, since we're a non-commercial > implementation, and that means we can't set the marchid to a commercial > ID of our choosing, i.e. some ID with the MSB set. We also can't select > an archid without the MSB set, though, because RVI needs to allocate > us that ID. Long story short, I think we need to use mvendorid=0,marchid=0 > unless we ask for and receive an marchid from RVI. Now, looking at mimpid, > I think we're free to set that to whatever we want, even if the other IDs > must be zero, but we should probably consider if we also want some bits > reserved for revisions or something before settling on an ID. Actually, > my vote would be to get an official marchid from RVI and then mimpid can > be reserved for other uses. So it looks like my vote was the plan all along :-) After reading Alistair's "this has been approved" comment regarding the Link below I actually bothered to check it and see that 42 is indeed the official RVI marchid. That wasn't clear to me from the commit message, but I guess I should have clicked the link! Sorry for the noise. Thanks, drew > > Thanks, > drew > > > > > > > Link: https://github.com/riscv/riscv-isa-manual/pull/1213 > > Signed-off-by: Palmer Dabbelt > > --- > > target/riscv/cpu.c | 16 > > target/riscv/cpu_vendorid.h | 3 +++ > > 2 files changed, 19 insertions(+) > > > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > > index 8cbfc7e781..1aef186f87 100644 > > --- a/target/riscv/cpu.c > > +++ b/target/riscv/cpu.c > > @@ -415,6 +415,9 @@ static void riscv_any_cpu_init(Object *obj) > > cpu->cfg.ext_zicsr = true; > > cpu->cfg.mmu = true; > > cpu->cfg.pmp = true; > > + > > +cpu->cfg.mvendorid = QEMU_MVENDORID; > > +cpu->cfg.marchid = QEMU_MARCHID; > > } > > > > static void riscv_max_cpu_init(Object *obj) > > @@ -432,6 +435,8 @@ static void riscv_max_cpu_init(Object *obj) > > set_satp_mode_max_supported(RISCV_CPU(obj), mlx == MXL_RV32 ? > > VM_1_10_SV32 : VM_1_10_SV57); > > #endif > > +cpu->cfg.mvendorid = QEMU_MVENDORID; > > +cpu->cfg.marchid = QEMU_MARCHID; > > } > > > > #if defined(TARGET_RISCV64) > > @@ -445,6 +450,8 @@ static void rv64_base_cpu_init(Object *obj) > > #ifndef CONFIG_USER_ONLY > > set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57); > > #endif > > +cpu->cfg.mvendorid = QEMU_MVENDORID; > > +cpu->cfg.marchid = QEMU_MARCHID; > > } > > > > static void rv64_sifive_u_cpu_init(Object *obj) > > @@ -569,6 +576,8 @@ static void rv128_base_cpu_init(Object *obj) > > #ifndef CONFIG_USER_ONLY > > set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57); > > #endif > > +cpu->cfg.mvendorid = QEMU_MVENDORID; > > +cpu->cfg.marchid = QEMU_MARCHID; > > } > > > > static void rv64i_bare_cpu_init(Object *obj) > > @@ -591,6 +600,8 @@ static void rv64i_bare_cpu_init(Object *obj) > > #ifndef CONFIG_USER_ONLY > > set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV64); > > #endif > > +cpu->cfg.mvendorid = QEMU_MVENDORID; > > +cpu->cfg.marchid = QEMU_MARCHID; > > } > > #else > > static void rv32_base_cpu_init(Object *obj) > > @@ -603,6 +614,8 @@ static void rv32_base_cpu_init(Object *obj) > > #ifndef CONFIG_USER_ONLY &g
Re: [PATCH] RISC-V: Report the QEMU vendor/arch IDs on virtual CPUs
On Wed, Jan 31, 2024 at 10:24:30AM -0800, Palmer Dabbelt wrote: > Right now we just report 0 for marchid/mvendorid in QEMU. That's legal, > but it's tricky for users that want to check if they're running on QEMU > to do so. This sets marchid to 42, which I've proposed as the QEMU > architecture ID (mvendorid remains 0, just explicitly set, as that's how > the ISA handles open source implementations). Hi Palmer, marchid has this text """ Open-source project architecture IDs are allocated globally by RISC-V International, and have non-zero architecture IDs with a zero most-significant-bit (MSB). Commercial architecture IDs are allocated by each commercial vendor independently, but must have the MSB set and cannot contain zero in the remaining MXLEN-1 bits. """ and mvendorid has this text """ ...a value of 0 can be returned to indicate the field is not implemented or that this is a non-commercial implementation. """ We must select zero for mvendorid, since we're a non-commercial implementation, and that means we can't set the marchid to a commercial ID of our choosing, i.e. some ID with the MSB set. We also can't select an archid without the MSB set, though, because RVI needs to allocate us that ID. Long story short, I think we need to use mvendorid=0,marchid=0 unless we ask for and receive an marchid from RVI. Now, looking at mimpid, I think we're free to set that to whatever we want, even if the other IDs must be zero, but we should probably consider if we also want some bits reserved for revisions or something before settling on an ID. Actually, my vote would be to get an official marchid from RVI and then mimpid can be reserved for other uses. Thanks, drew > > Link: https://github.com/riscv/riscv-isa-manual/pull/1213 > Signed-off-by: Palmer Dabbelt > --- > target/riscv/cpu.c | 16 > target/riscv/cpu_vendorid.h | 3 +++ > 2 files changed, 19 insertions(+) > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > index 8cbfc7e781..1aef186f87 100644 > --- a/target/riscv/cpu.c > +++ b/target/riscv/cpu.c > @@ -415,6 +415,9 @@ static void riscv_any_cpu_init(Object *obj) > cpu->cfg.ext_zicsr = true; > cpu->cfg.mmu = true; > cpu->cfg.pmp = true; > + > +cpu->cfg.mvendorid = QEMU_MVENDORID; > +cpu->cfg.marchid = QEMU_MARCHID; > } > > static void riscv_max_cpu_init(Object *obj) > @@ -432,6 +435,8 @@ static void riscv_max_cpu_init(Object *obj) > set_satp_mode_max_supported(RISCV_CPU(obj), mlx == MXL_RV32 ? > VM_1_10_SV32 : VM_1_10_SV57); > #endif > +cpu->cfg.mvendorid = QEMU_MVENDORID; > +cpu->cfg.marchid = QEMU_MARCHID; > } > > #if defined(TARGET_RISCV64) > @@ -445,6 +450,8 @@ static void rv64_base_cpu_init(Object *obj) > #ifndef CONFIG_USER_ONLY > set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57); > #endif > +cpu->cfg.mvendorid = QEMU_MVENDORID; > +cpu->cfg.marchid = QEMU_MARCHID; > } > > static void rv64_sifive_u_cpu_init(Object *obj) > @@ -569,6 +576,8 @@ static void rv128_base_cpu_init(Object *obj) > #ifndef CONFIG_USER_ONLY > set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57); > #endif > +cpu->cfg.mvendorid = QEMU_MVENDORID; > +cpu->cfg.marchid = QEMU_MARCHID; > } > > static void rv64i_bare_cpu_init(Object *obj) > @@ -591,6 +600,8 @@ static void rv64i_bare_cpu_init(Object *obj) > #ifndef CONFIG_USER_ONLY > set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV64); > #endif > +cpu->cfg.mvendorid = QEMU_MVENDORID; > +cpu->cfg.marchid = QEMU_MARCHID; > } > #else > static void rv32_base_cpu_init(Object *obj) > @@ -603,6 +614,8 @@ static void rv32_base_cpu_init(Object *obj) > #ifndef CONFIG_USER_ONLY > set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV32); > #endif > +cpu->cfg.mvendorid = QEMU_MVENDORID; > +cpu->cfg.marchid = QEMU_MARCHID; > } > > static void rv32_sifive_u_cpu_init(Object *obj) > @@ -672,6 +685,9 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj) > cpu->cfg.ext_zifencei = true; > cpu->cfg.ext_zicsr = true; > cpu->cfg.pmp = true; > + > +cpu->cfg.mvendorid = QEMU_MVENDORID; > +cpu->cfg.marchid = QEMU_MARCHID; > } > #endif > > diff --git a/target/riscv/cpu_vendorid.h b/target/riscv/cpu_vendorid.h > index 96b6b9c2cb..486832cd53 100644 > --- a/target/riscv/cpu_vendorid.h > +++ b/target/riscv/cpu_vendorid.h > @@ -7,4 +7,7 @@ > #define VEYRON_V1_MIMPID0x111 > #define VEYRON_V1_MVENDORID 0x61f > > +#define QEMU_VIRT_MVENDORID 0 > +#define QEMU_VIRT_MARCHID 42 > + > #endif /* TARGET_RISCV_CPU_VENDORID_H */ > -- > 2.43.0 > >
Re: [PATCH v3] target/riscv: mcountinhibit, mcounteren, scounteren, hcounteren is 32-bit
On Wed, Jan 31, 2024 at 03:36:24PM +0300, Vadim Shakirov wrote: > mcountinhibit, mcounteren, scounteren and hcounteren must always be 32-bit > by privileged spec > > Signed-off-by: Vadim Shakirov > --- > target/riscv/cpu.h | 8 > target/riscv/machine.c | 16 > 2 files changed, 12 insertions(+), 12 deletions(-) > Reviewed-by: Andrew Jones
Re: RE: [RESEND v2 1/2] hw/arm/virt-acpi-build.c: Migrate SPCR creation to common location
On Tue, Jan 30, 2024 at 03:30:13AM +, JeeHeng Sia wrote: ... > > Sharing code is good, but if we have to parametrize the entire table, then > > we might as well keep Arm and RISCV separate. Building the table first > > with this struct, just to have it built again with the build_append API, > > doesn't make much sense to me. Do Arm and riscv really diverge on all > > these parameters? If not, then just add the parameters which do diverge > > build_scpr's arguments. > It is kind of chicken and egg thing, I would suggest let the arch code to > fill in the value. It doesn't make sense to change again in the future when > both riscv and arm realized the parameters were different. > Can arm confirm that these values wouldn't change in the future? > > We can't be sure that arm nor riscv will change in the future, but we (arm/riscv/etc. QEMU developers) control the code for both, so I don't see a problem with only parametrizing what's necessary today and then extending that, or completely separating, later if necessary. In any case, I'd rather see the two completely separate from the start, than to see the structure with all the parameters get added. There's no difference to me when reading a list of 's->param_name = value' or a list of build_append_int(table, value, size) /* param_name */. And, given we need the later eventually anyway, then there's no reason for the former at all. Thanks, drew
Re: RE: [RESEND v2 1/2] hw/arm/virt-acpi-build.c: Migrate SPCR creation to common location
On Tue, Jan 30, 2024 at 03:16:34AM +, JeeHeng Sia wrote: ... > > I think either there should be a comment that this supports only v2 of > > SPCR spec or it should be able to create SPCR of any version. IMO, I > > think it is better to add support till v4 (latest). Since consumers like > > Linux probably doesn't support v4 yet, ARM/RISC-V can continue to create > > v2 itself for the time being but the generic build_spcr() should be able > > to create v4 also if the arch requires it. > A v4 table depends on the updated acpica. I am not aware if there is a > request from ARM to update to v4. Anyway, RISC-V BRS Spec did mentioned > on poll-based sbi console. I can check with acpica community if updating > table to v4 is the go otherwise I would suggest we cont stick to v2 because > there is no compatible ACPI guest to test the code. > > Generally we want to produce the oldest version which meets the requirements in order to support the widest set of consumers. Thanks, drew
Re: [PATCH] hw/riscv/virt-acpi-build.c: Add SRAT and SLIT ACPI tables
On Mon, Jan 29, 2024 at 05:42:00PM +0800, Haibo Xu wrote:
> Enable ACPI NUMA support by adding the following 2 ACPI tables:
> SRAT: provides the association for memory/Harts and Proximity Domains
> SLIT: provides the relative distance between Proximity Domains
>
> The SRAT RINTC Affinity Structure definition[1] was based on the recently
> approved ACPI CodeFirst ECR[2].
>
> [1] https://github.com/riscv-non-isa/riscv-acpi/issues/25
> [2] https://mantis.uefi.org/mantis/view.php?id=2433
>
> Signed-off-by: Haibo Xu
> ---
> hw/riscv/virt-acpi-build.c | 60 ++
> 1 file changed, 60 insertions(+)
>
> diff --git a/hw/riscv/virt-acpi-build.c b/hw/riscv/virt-acpi-build.c
> index 26c7e4482d..f0a6b61747 100644
> --- a/hw/riscv/virt-acpi-build.c
> +++ b/hw/riscv/virt-acpi-build.c
> @@ -528,11 +528,61 @@ static void build_madt(GArray *table_data,
> acpi_table_end(linker, );
> }
>
> +/*
> + * ACPI spec, Revision 6.5+
> + * 5.2.16 System Resource Affinity Table (SRAT)
> + * REF: https://github.com/riscv-non-isa/riscv-acpi/issues/25
> + *
> https://drive.google.com/file/d/1YTdDx2IPm5IeZjAW932EYU-tUtgS08tX/view
> + */
> +static void
> +build_srat(GArray *table_data, BIOSLinker *linker, RISCVVirtState *vms)
> +{
> +int i;
> +uint64_t mem_base;
> +MachineClass *mc = MACHINE_GET_CLASS(vms);
> +MachineState *ms = MACHINE(vms);
> +const CPUArchIdList *cpu_list = mc->possible_cpu_arch_ids(ms);
> +AcpiTable table = { .sig = "SRAT", .rev = 3, .oem_id = vms->oem_id,
> +.oem_table_id = vms->oem_table_id };
> +
> +acpi_table_begin(, table_data);
> +build_append_int_noprefix(table_data, 1, 4); /* Reserved */
> +build_append_int_noprefix(table_data, 0, 8); /* Reserved */
> +
> +for (i = 0; i < cpu_list->len; ++i) {
> +uint32_t nodeid = cpu_list->cpus[i].props.node_id;
> +/*
> + * 5.2.16.8 RINTC Affinity Structure
> + */
> +build_append_int_noprefix(table_data, 7, 1); /* Type */
> +build_append_int_noprefix(table_data, 20, 1); /* Length */
> +build_append_int_noprefix(table_data, 0, 2);/* Reserved */
> +build_append_int_noprefix(table_data, nodeid, 4); /* Proximity
> Domain */
> +build_append_int_noprefix(table_data, i, 4); /* ACPI Processor UID */
> +/* Flags, Table 5-70 */
> +build_append_int_noprefix(table_data, 1 /* Flags: Enabled */, 4);
> +build_append_int_noprefix(table_data, 0, 4); /* Clock Domain */
> +}
> +
> +mem_base = vms->memmap[VIRT_DRAM].base;
> +for (i = 0; i < ms->numa_state->num_nodes; ++i) {
> +if (ms->numa_state->nodes[i].node_mem > 0) {
> +build_srat_memory(table_data, mem_base,
> + ms->numa_state->nodes[i].node_mem, i,
> + MEM_AFFINITY_ENABLED);
> +mem_base += ms->numa_state->nodes[i].node_mem;
> +}
> +}
> +
> +acpi_table_end(linker, );
> +}
> +
> static void virt_acpi_build(RISCVVirtState *s, AcpiBuildTables *tables)
> {
> GArray *table_offsets;
> unsigned dsdt, xsdt;
> GArray *tables_blob = tables->table_data;
> +MachineState *ms = MACHINE(s);
>
> table_offsets = g_array_new(false, true,
> sizeof(uint32_t));
> @@ -565,6 +615,16 @@ static void virt_acpi_build(RISCVVirtState *s,
> AcpiBuildTables *tables)
> s->oem_table_id);
> }
>
> +if (ms->numa_state->num_nodes > 0) {
> +acpi_add_table(table_offsets, tables_blob);
> +build_srat(tables_blob, tables->linker, s);
> +if (ms->numa_state->have_numa_distance) {
> + acpi_add_table(table_offsets, tables_blob);
> +build_slit(tables_blob, tables->linker, ms, s->oem_id,
> + s->oem_table_id);
> +}
> +}
> +
> /* XSDT is pointed to by RSDP */
> xsdt = tables_blob->len;
> build_xsdt(tables_blob, tables->linker, table_offsets, s->oem_id,
> --
> 2.34.1
>
>
Reviewed-by: Andrew Jones
Re: [PATCH v2] target/riscv: mcountinhibit, mcounteren and scounteren always 32-bit
On Mon, Jan 29, 2024 at 11:47:28AM +0300, Vadim Shakirov wrote:
> mcountinhibit, mcounteren and scounteren must always be 32-bit by
> privileged spec
We should also change hcounteren.
Thanks,
drew
>
> Signed-off-by: Vadim Shakirov
> ---
> target/riscv/cpu.h | 6 +++---
> target/riscv/machine.c | 10 +-
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 5138187727..2236a55bf1 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -334,10 +334,10 @@ struct CPUArchState {
> */
> bool two_stage_indirect_lookup;
>
> -target_ulong scounteren;
> -target_ulong mcounteren;
> +uint32_t scounteren;
> +uint32_t mcounteren;
>
> -target_ulong mcountinhibit;
> +uint32_t mcountinhibit;
>
> /* PMU counter state */
> PMUCTRState pmu_ctrs[RV_MAX_MHPMCOUNTERS];
> diff --git a/target/riscv/machine.c b/target/riscv/machine.c
> index 72fe2374dc..6bf013054d 100644
> --- a/target/riscv/machine.c
> +++ b/target/riscv/machine.c
> @@ -354,8 +354,8 @@ static const VMStateDescription vmstate_jvt = {
>
> const VMStateDescription vmstate_riscv_cpu = {
> .name = "cpu",
> -.version_id = 9,
> -.minimum_version_id = 9,
> +.version_id = 10,
> +.minimum_version_id = 10,
> .post_load = riscv_cpu_post_load,
> .fields = (const VMStateField[]) {
> VMSTATE_UINTTL_ARRAY(env.gpr, RISCVCPU, 32),
> @@ -398,9 +398,9 @@ const VMStateDescription vmstate_riscv_cpu = {
> VMSTATE_UINTTL(env.mtval, RISCVCPU),
> VMSTATE_UINTTL(env.miselect, RISCVCPU),
> VMSTATE_UINTTL(env.siselect, RISCVCPU),
> -VMSTATE_UINTTL(env.scounteren, RISCVCPU),
> -VMSTATE_UINTTL(env.mcounteren, RISCVCPU),
> -VMSTATE_UINTTL(env.mcountinhibit, RISCVCPU),
> +VMSTATE_UINT32(env.scounteren, RISCVCPU),
> +VMSTATE_UINT32(env.mcounteren, RISCVCPU),
> +VMSTATE_UINT32(env.mcountinhibit, RISCVCPU),
> VMSTATE_STRUCT_ARRAY(env.pmu_ctrs, RISCVCPU, RV_MAX_MHPMCOUNTERS, 0,
> vmstate_pmu_ctr_state, PMUCTRState),
> VMSTATE_UINTTL_ARRAY(env.mhpmevent_val, RISCVCPU, RV_MAX_MHPMEVENTS),
> --
> 2.34.1
>
>
Re: [RESEND v2 1/2] hw/arm/virt-acpi-build.c: Migrate SPCR creation to common location
On Sun, Jan 28, 2024 at 06:14:39PM -0800, Sia Jee Heng wrote:
> RISC-V should also generate the SPCR in a manner similar to ARM.
> Therefore, instead of replicating the code, relocate this function
> to the common AML build.
>
> Signed-off-by: Sia Jee Heng
> ---
> hw/acpi/aml-build.c | 51
> hw/arm/virt-acpi-build.c| 68 +++--
> include/hw/acpi/acpi-defs.h | 33 ++
> include/hw/acpi/aml-build.h | 4 +++
> 4 files changed, 115 insertions(+), 41 deletions(-)
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index af66bde0f5..f3904650e4 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -1994,6 +1994,57 @@ static void build_processor_hierarchy_node(GArray
> *tbl, uint32_t flags,
> }
> }
>
> +void build_spcr(GArray *table_data, BIOSLinker *linker,
> +const AcpiSpcrData *f, const uint8_t rev,
> +const char *oem_id, const char *oem_table_id)
> +{
> +AcpiTable table = { .sig = "SPCR", .rev = rev, .oem_id = oem_id,
> +.oem_table_id = oem_table_id };
> +
> +acpi_table_begin(, table_data);
> +/* Interface type */
> +build_append_int_noprefix(table_data, f->interface_type, 1);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 3);
> +/* Base Address */
> +build_append_gas(table_data, f->base_addr.id, f->base_addr.width,
> + f->base_addr.offset, f->base_addr.size,
> + f->base_addr.addr);
> +/* Interrupt type */
> +build_append_int_noprefix(table_data, f->interrupt_type, 1);
> +/* IRQ */
> +build_append_int_noprefix(table_data, f->pc_interrupt, 1);
> +/* Global System Interrupt */
> +build_append_int_noprefix(table_data, f->interrupt, 4);
> +/* Baud Rate */
> +build_append_int_noprefix(table_data, f->baud_rate, 1);
> +/* Parity */
> +build_append_int_noprefix(table_data, f->parity, 1);
> +/* Stop Bits */
> +build_append_int_noprefix(table_data, f->stop_bits, 1);
> +/* Flow Control */
> +build_append_int_noprefix(table_data, f->flow_control, 1);
> +/* Terminal Type */
> +build_append_int_noprefix(table_data, f->terminal_type, 1);
> +/* PCI Device ID */
> +build_append_int_noprefix(table_data, f->pci_device_id, 2);
> +/* PCI Vendor ID */
> +build_append_int_noprefix(table_data, f->pci_vendor_id, 2);
> +/* PCI Bus Number */
> +build_append_int_noprefix(table_data, f->pci_bus, 1);
> +/* PCI Device Number */
> +build_append_int_noprefix(table_data, f->pci_device, 1);
> +/* PCI Function Number */
> +build_append_int_noprefix(table_data, f->pci_function, 1);
> +/* PCI Flags */
> +build_append_int_noprefix(table_data, f->pci_flags, 4);
> +/* PCI Segment */
> +build_append_int_noprefix(table_data, f->pci_segment, 1);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 4);
> +
> +acpi_table_end(linker, );
> +}
> /*
> * ACPI spec, Revision 6.3
> * 5.2.29 Processor Properties Topology Table (PPTT)
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index a22a2f43a5..195767c0f0 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -431,48 +431,34 @@ build_iort(GArray *table_data, BIOSLinker *linker,
> VirtMachineState *vms)
> * Rev: 1.07
> */
> static void
> -build_spcr(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> +spcr_setup(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> {
> -AcpiTable table = { .sig = "SPCR", .rev = 2, .oem_id = vms->oem_id,
> -.oem_table_id = vms->oem_table_id };
> -
> -acpi_table_begin(, table_data);
> -
> -/* Interface Type */
> -build_append_int_noprefix(table_data, 3, 1); /* ARM PL011 UART */
> -build_append_int_noprefix(table_data, 0, 3); /* Reserved */
> -/* Base Address */
> -build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 3,
> - vms->memmap[VIRT_UART].base);
> -/* Interrupt Type */
> -build_append_int_noprefix(table_data,
> -(1 << 3) /* Bit[3] ARMH GIC interrupt */, 1);
> -build_append_int_noprefix(table_data, 0, 1); /* IRQ */
> -/* Global System Interrupt */
> -build_append_int_noprefix(table_data,
> - vms->irqmap[VIRT_UART] + ARM_SPI_BASE, 4);
> -build_append_int_noprefix(table_data, 3 /* 9600 */, 1); /* Baud Rate */
> -build_append_int_noprefix(table_data, 0 /* No Parity */, 1); /* Parity */
> -/* Stop Bits */
> -build_append_int_noprefix(table_data, 1 /* 1 Stop bit */, 1);
> -/* Flow Control */
> -build_append_int_noprefix(table_data,
> -(1 << 1) /* RTS/CTS hardware flow control */, 1);
> -/* Terminal Type */
> -build_append_int_noprefix(table_data, 0 /* VT100 */, 1);
> -build_append_int_noprefix(table_data, 0, 1); /*
[PATCH v2 6/6] target/riscv: Promote svade to a normal extension
Named features are extensions which don't make sense for users to
control and are therefore not exposed on the command line. However,
svade is an extension which makes sense for users to control, so treat
it like a "normal" extension. The default is false, even for the max
cpu type, since QEMU has always implemented hardware A/D PTE bit
updating, so users must opt into svade (or get it from a CPU type
which enables it by default).
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Andrew Jones
---
target/riscv/cpu.c | 8 +++-
target/riscv/tcg/tcg-cpu.c | 6 ++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index a56c2ff91d6d..4ddde2541233 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -1421,6 +1421,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
MULTI_EXT_CFG_BOOL("smepmp", ext_smepmp, false),
MULTI_EXT_CFG_BOOL("smstateen", ext_smstateen, false),
+MULTI_EXT_CFG_BOOL("svade", ext_svade, false),
MULTI_EXT_CFG_BOOL("svadu", ext_svadu, true),
MULTI_EXT_CFG_BOOL("svinval", ext_svinval, false),
MULTI_EXT_CFG_BOOL("svnapot", ext_svnapot, false),
@@ -1528,7 +1529,6 @@ const RISCVCPUMultiExtConfig
riscv_cpu_experimental_exts[] = {
* and priv_ver like regular extensions.
*/
const RISCVCPUMultiExtConfig riscv_cpu_named_features[] = {
-MULTI_EXT_CFG_BOOL("svade", ext_svade, true),
MULTI_EXT_CFG_BOOL("zic64b", ext_zic64b, true),
/*
@@ -2175,8 +2175,6 @@ static RISCVCPUProfile RVA22U64 = {
* Other named features that we already implement: Sstvecd, Sstvala,
* Sscounterenw
*
- * Named features that we need to enable: svade
- *
* The remaining features/extensions comes from RVA22U64.
*/
static RISCVCPUProfile RVA22S64 = {
@@ -2188,11 +2186,11 @@ static RISCVCPUProfile RVA22S64 = {
.ext_offsets = {
/* rva22s64 exts */
CPU_CFG_OFFSET(ext_zifencei), CPU_CFG_OFFSET(ext_svpbmt),
-CPU_CFG_OFFSET(ext_svinval),
+CPU_CFG_OFFSET(ext_svinval), CPU_CFG_OFFSET(ext_svade),
/* rva22s64 named features */
CPU_CFG_OFFSET(ext_sstvecd), CPU_CFG_OFFSET(ext_sstvala),
-CPU_CFG_OFFSET(ext_sscounterenw), CPU_CFG_OFFSET(ext_svade),
+CPU_CFG_OFFSET(ext_sscounterenw),
RISCV_PROFILE_EXT_LIST_END
}
diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index bc3c45b11704..b93df1725a79 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -1314,6 +1314,12 @@ static void riscv_init_max_cpu_extensions(Object *obj)
isa_ext_update_enabled(cpu, prop->offset, true);
}
+/*
+ * Some extensions can't be added without backward compatibilty concerns.
+ * Disable those, the user can still opt in to them on the command line.
+ */
+cpu->cfg.ext_svade = false;
+
/* set vector version */
env->vext_ver = VEXT_VERSION_1_00_0;
--
2.43.0
[PATCH v2 3/6] target/riscv: add remaining named features
From: Daniel Henrique Barboza
The RVA22U64 and RVA22S64 profiles mandates certain extensions that,
until now, we were implying that they were available.
We can't do this anymore since named features also has a riscv,isa
entry. Let's add them to riscv_cpu_named_features[].
They will also need to be explicitly enabled in both profile
descriptions. TCG will enable the named features it already implements,
other accelerators are free to handle it as they like.
After this patch, here's the riscv,isa from a buildroot using the
'rva22s64' CPU:
# cat /proc/device-tree/cpus/cpu@0/riscv,isa
rv64imafdc_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_
zicntr_zicsr_zifencei_zihintpause_zihpm_za64rs_zfhmin_zca_zcd_zba_zbb_
zbs_zkt_sscounterenw_sstvala_sstvecd_svade_svinval_svpbmt#
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
---
target/riscv/cpu.c | 41 +-
target/riscv/cpu_cfg.h | 9 +
target/riscv/tcg/tcg-cpu.c | 19 +-
3 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 28d3cfa8ce59..1ecd8a57ed02 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -101,6 +101,10 @@ const RISCVIsaExtData isa_edata_arr[] = {
ISA_EXT_DATA_ENTRY(zicbom, PRIV_VERSION_1_12_0, ext_zicbom),
ISA_EXT_DATA_ENTRY(zicbop, PRIV_VERSION_1_12_0, ext_zicbop),
ISA_EXT_DATA_ENTRY(zicboz, PRIV_VERSION_1_12_0, ext_zicboz),
+ISA_EXT_DATA_ENTRY(ziccamoa, PRIV_VERSION_1_11_0, ext_ziccamoa),
+ISA_EXT_DATA_ENTRY(ziccif, PRIV_VERSION_1_11_0, ext_ziccif),
+ISA_EXT_DATA_ENTRY(zicclsm, PRIV_VERSION_1_11_0, ext_zicclsm),
+ISA_EXT_DATA_ENTRY(ziccrse, PRIV_VERSION_1_11_0, ext_ziccrse),
ISA_EXT_DATA_ENTRY(zicond, PRIV_VERSION_1_12_0, ext_zicond),
ISA_EXT_DATA_ENTRY(zicntr, PRIV_VERSION_1_12_0, ext_zicntr),
ISA_EXT_DATA_ENTRY(zicsr, PRIV_VERSION_1_10_0, ext_zicsr),
@@ -109,6 +113,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
ISA_EXT_DATA_ENTRY(zihintpause, PRIV_VERSION_1_10_0, ext_zihintpause),
ISA_EXT_DATA_ENTRY(zihpm, PRIV_VERSION_1_12_0, ext_zihpm),
ISA_EXT_DATA_ENTRY(zmmul, PRIV_VERSION_1_12_0, ext_zmmul),
+ISA_EXT_DATA_ENTRY(za64rs, PRIV_VERSION_1_12_0, ext_za64rs),
ISA_EXT_DATA_ENTRY(zacas, PRIV_VERSION_1_12_0, ext_zacas),
ISA_EXT_DATA_ENTRY(zawrs, PRIV_VERSION_1_12_0, ext_zawrs),
ISA_EXT_DATA_ENTRY(zfa, PRIV_VERSION_1_12_0, ext_zfa),
@@ -170,8 +175,12 @@ const RISCVIsaExtData isa_edata_arr[] = {
ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
ISA_EXT_DATA_ENTRY(ssaia, PRIV_VERSION_1_12_0, ext_ssaia),
+ISA_EXT_DATA_ENTRY(ssccptr, PRIV_VERSION_1_11_0, ext_ssccptr),
ISA_EXT_DATA_ENTRY(sscofpmf, PRIV_VERSION_1_12_0, ext_sscofpmf),
+ISA_EXT_DATA_ENTRY(sscounterenw, PRIV_VERSION_1_12_0, ext_sscounterenw),
ISA_EXT_DATA_ENTRY(sstc, PRIV_VERSION_1_12_0, ext_sstc),
+ISA_EXT_DATA_ENTRY(sstvala, PRIV_VERSION_1_12_0, ext_sstvala),
+ISA_EXT_DATA_ENTRY(sstvecd, PRIV_VERSION_1_12_0, ext_sstvecd),
ISA_EXT_DATA_ENTRY(svade, PRIV_VERSION_1_11_0, ext_svade),
ISA_EXT_DATA_ENTRY(svadu, PRIV_VERSION_1_12_0, ext_svadu),
ISA_EXT_DATA_ENTRY(svinval, PRIV_VERSION_1_12_0, ext_svinval),
@@ -1523,6 +1532,22 @@ const RISCVCPUMultiExtConfig riscv_cpu_named_features[]
= {
MULTI_EXT_CFG_BOOL("svade", ext_svade, true),
MULTI_EXT_CFG_BOOL("zic64b", ext_zic64b, true),
+/*
+ * cache-related extensions that are always enabled
+ * since QEMU RISC-V does not have a cache model.
+ */
+MULTI_EXT_CFG_BOOL("za64rs", ext_za64rs, true),
+MULTI_EXT_CFG_BOOL("ziccif", ext_ziccif, true),
+MULTI_EXT_CFG_BOOL("ziccrse", ext_ziccrse, true),
+MULTI_EXT_CFG_BOOL("ziccamoa", ext_ziccamoa, true),
+MULTI_EXT_CFG_BOOL("zicclsm", ext_zicclsm, true),
+MULTI_EXT_CFG_BOOL("ssccptr", ext_ssccptr, true),
+
+/* Other named features that QEMU TCG always implements */
+MULTI_EXT_CFG_BOOL("sstvecd", ext_sstvecd, true),
+MULTI_EXT_CFG_BOOL("sstvala", ext_sstvala, true),
+MULTI_EXT_CFG_BOOL("sscounterenw", ext_sscounterenw, true),
+
DEFINE_PROP_END_OF_LIST(),
};
@@ -2116,13 +2141,8 @@ static const PropertyInfo prop_marchid = {
};
/*
- * RVA22U64 defines some 'named features' or 'synthetic extensions'
- * that are cache related: Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa
- * and Zicclsm. We do not implement caching in QEMU so we'll consider
- * all these named features as always enabled.
- *
- * There's no riscv,isa update for them (nor for zic64b, despite it
- * having a cfg offset) at this moment.
+ * RVA22U64 defines some cache related extensions: Za64rs,
+ * Ziccif, Ziccrse, Ziccamoa and Zicclsm.
*/
static RISCVCPUProfile RVA22U64 = {
[PATCH v2 0/6] riscv: named features riscv,isa, 'svade' rework
Hi, This is a bundle of fixes based on discoveries that were made in the last week or so: - what we call "named features" are actually real extensions, which are considered to be ratified by the profile spec that defines them. This means that we need to add riscv,isa strings for them. More info can be found on the commit msg of patch 2; - the design behind 'svade' and 'svadu' is wrong. 'svade' does not mean 'we do not have svadu'. In fact they can coexist. Patch 5 gives more details about it. After this series, 'svade' is promoted to a regular extension and all the named features QEMU implements are now being displayed in riscv,isa. v2: - Ensure svade is off by default even for the max cpu type Andrew Jones (3): target/riscv: Reset henvcfg to zero target/riscv: Gate hardware A/D PTE bit updating target/riscv: Promote svade to a normal extension Daniel Henrique Barboza (3): target/riscv/tcg: set 'mmu' with 'satp' in cpu_set_profile() target/riscv: add riscv,isa to named features target/riscv: add remaining named features target/riscv/cpu.c | 63 -- target/riscv/cpu_cfg.h | 15 +++-- target/riscv/cpu_helper.c | 18 --- target/riscv/csr.c | 2 +- target/riscv/tcg/tcg-cpu.c | 48 +++-- 5 files changed, 105 insertions(+), 41 deletions(-) -- 2.43.0
[PATCH v2 2/6] target/riscv: add riscv,isa to named features
From: Daniel Henrique Barboza
Further discussions after the introduction of rva22 support in QEMU
revealed that what we've been calling 'named features' are actually
regular extensions, with their respective riscv,isa DTs. This is
clarified in [1]. [2] is a bug tracker asking for the profile spec to be
less cryptic about it.
As far as QEMU goes we understand extensions as something that the user
can enable/disable in the command line. This isn't the case for named
features, so we'll have to reach a middle ground.
We'll keep our existing nomenclature 'named features' to refer to any
extension that the user can't control in the command line. We'll also do
the following:
- 'svade' and 'zic64b' flags are renamed to 'ext_svade' and
'ext_zic64b'. 'ext_svade' and 'ext_zic64b' now have riscv,isa strings and
priv_spec versions;
- skip name feature check in cpu_bump_multi_ext_priv_ver(). Now that
named features have a riscv,isa and an entry in isa_edata_arr[] we
don't need to gate the call to cpu_cfg_ext_get_min_version() anymore.
[1] https://github.com/riscv/riscv-profiles/issues/121
[2] https://github.com/riscv/riscv-profiles/issues/142
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
---
target/riscv/cpu.c | 17 +
target/riscv/cpu_cfg.h | 6 --
target/riscv/tcg/tcg-cpu.c | 16 ++--
3 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 88e8cc868144..28d3cfa8ce59 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -97,6 +97,7 @@ bool riscv_cpu_option_set(const char *optname)
* instead.
*/
const RISCVIsaExtData isa_edata_arr[] = {
+ISA_EXT_DATA_ENTRY(zic64b, PRIV_VERSION_1_12_0, ext_zic64b),
ISA_EXT_DATA_ENTRY(zicbom, PRIV_VERSION_1_12_0, ext_zicbom),
ISA_EXT_DATA_ENTRY(zicbop, PRIV_VERSION_1_12_0, ext_zicbop),
ISA_EXT_DATA_ENTRY(zicboz, PRIV_VERSION_1_12_0, ext_zicboz),
@@ -171,6 +172,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
ISA_EXT_DATA_ENTRY(ssaia, PRIV_VERSION_1_12_0, ext_ssaia),
ISA_EXT_DATA_ENTRY(sscofpmf, PRIV_VERSION_1_12_0, ext_sscofpmf),
ISA_EXT_DATA_ENTRY(sstc, PRIV_VERSION_1_12_0, ext_sstc),
+ISA_EXT_DATA_ENTRY(svade, PRIV_VERSION_1_11_0, ext_svade),
ISA_EXT_DATA_ENTRY(svadu, PRIV_VERSION_1_12_0, ext_svadu),
ISA_EXT_DATA_ENTRY(svinval, PRIV_VERSION_1_12_0, ext_svinval),
ISA_EXT_DATA_ENTRY(svnapot, PRIV_VERSION_1_12_0, ext_svnapot),
@@ -1510,9 +1512,16 @@ const RISCVCPUMultiExtConfig
riscv_cpu_experimental_exts[] = {
DEFINE_PROP_END_OF_LIST(),
};
+/*
+ * 'Named features' is the name we give to extensions that we
+ * don't want to expose to users. They are either immutable
+ * (always enabled/disable) or they'll vary depending on
+ * the resulting CPU state. They have riscv,isa strings
+ * and priv_ver like regular extensions.
+ */
const RISCVCPUMultiExtConfig riscv_cpu_named_features[] = {
-MULTI_EXT_CFG_BOOL("svade", svade, true),
-MULTI_EXT_CFG_BOOL("zic64b", zic64b, true),
+MULTI_EXT_CFG_BOOL("svade", ext_svade, true),
+MULTI_EXT_CFG_BOOL("zic64b", ext_zic64b, true),
DEFINE_PROP_END_OF_LIST(),
};
@@ -2130,7 +2139,7 @@ static RISCVCPUProfile RVA22U64 = {
CPU_CFG_OFFSET(ext_zicbop), CPU_CFG_OFFSET(ext_zicboz),
/* mandatory named features for this profile */
-CPU_CFG_OFFSET(zic64b),
+CPU_CFG_OFFSET(ext_zic64b),
RISCV_PROFILE_EXT_LIST_END
}
@@ -2161,7 +2170,7 @@ static RISCVCPUProfile RVA22S64 = {
CPU_CFG_OFFSET(ext_svinval),
/* rva22s64 named features */
-CPU_CFG_OFFSET(svade),
+CPU_CFG_OFFSET(ext_svade),
RISCV_PROFILE_EXT_LIST_END
}
diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
index e241922f89c4..698f926ab1be 100644
--- a/target/riscv/cpu_cfg.h
+++ b/target/riscv/cpu_cfg.h
@@ -117,13 +117,15 @@ struct RISCVCPUConfig {
bool ext_smepmp;
bool rvv_ta_all_1s;
bool rvv_ma_all_1s;
-bool svade;
-bool zic64b;
uint32_t mvendorid;
uint64_t marchid;
uint64_t mimpid;
+/* Named features */
+bool ext_svade;
+bool ext_zic64b;
+
/* Vendor-specific custom extensions */
bool ext_xtheadba;
bool ext_xtheadbb;
diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 88f92d1c7d2c..90861cc065e5 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -197,12 +197,12 @@ static bool cpu_cfg_offset_is_named_feat(uint32_t
ext_offset)
static void riscv_cpu_enable_named_feat(RISCVCPU *cpu, uint32_t feat_offset)
{
switch (feat_offset) {
-case CPU_CFG_OFFSET(zic64b):
+case CPU_CFG_OFFSET(ext_zic64b):
cpu->cfg.cbom_blocksize = 64;
cpu->cfg.cbop_blocksize = 64;
cpu->cfg.cboz_blocksize = 64;
break;
-case CPU_CFG_OFFSET(svade):
+case CPU_CFG_OFFSET(ext_svade):
[PATCH v2 5/6] target/riscv: Gate hardware A/D PTE bit updating
Gate hardware A/D PTE bit updating on {m,h}envcfg.ADUE and only
enable menvcfg.ADUE on reset if svade has not been selected. Now
that we also consider svade, we have four possible configurations:
1) !svade && !svadu
use hardware updating and there's no way to disable it
(the default, which maintains past behavior. Maintaining
the default, even with !svadu is a change that fixes [1])
2) !svade && svadu
use hardware updating, but also provide {m,h}envcfg.ADUE,
allowing software to switch to exception mode
(being able to switch is a change which fixes [1])
3) svade && !svadu
use exception mode and there's no way to switch to hardware
updating
(this behavior change fixes [2])
4) svade && svadu
use exception mode, but also provide {m,h}envcfg.ADUE,
allowing software to switch to hardware updating
(this behavior change fixes [2])
Fixes: 0af3f115e68e ("target/riscv: Add *envcfg.HADE related check in address
translation") [1]
Fixes: 48531f5adb2a ("target/riscv: implement svade") [2]
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Andrew Jones
---
target/riscv/cpu.c | 2 +-
target/riscv/cpu_helper.c | 18 ++
target/riscv/tcg/tcg-cpu.c | 16 +---
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 7fd433daee74..a56c2ff91d6d 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -960,7 +960,7 @@ static void riscv_cpu_reset_hold(Object *obj)
env->two_stage_lookup = false;
env->menvcfg = (cpu->cfg.ext_svpbmt ? MENVCFG_PBMTE : 0) |
- (cpu->cfg.ext_svadu ? MENVCFG_ADUE : 0);
+ (!cpu->cfg.ext_svade && cpu->cfg.ext_svadu ? MENVCFG_ADUE :
0);
env->henvcfg = 0;
/* Initialized default priorities of local interrupts. */
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 8da9104da450..9da9758cb4d4 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -907,7 +907,9 @@ static int get_physical_address(CPURISCVState *env, hwaddr
*physical,
}
bool pbmte = env->menvcfg & MENVCFG_PBMTE;
-bool adue = env->menvcfg & MENVCFG_ADUE;
+bool svade = riscv_cpu_cfg(env)->ext_svade;
+bool svadu = riscv_cpu_cfg(env)->ext_svadu;
+bool adue = svadu ? env->menvcfg & MENVCFG_ADUE : !svade;
if (first_stage && two_stage && env->virt_enabled) {
pbmte = pbmte && (env->henvcfg & HENVCFG_PBMTE);
@@ -1082,9 +1084,17 @@ restart:
return TRANSLATE_FAIL;
}
-/* If necessary, set accessed and dirty bits. */
-target_ulong updated_pte = pte | PTE_A |
-(access_type == MMU_DATA_STORE ? PTE_D : 0);
+target_ulong updated_pte = pte;
+
+/*
+ * If ADUE is enabled, set accessed and dirty bits.
+ * Otherwise raise an exception if necessary.
+ */
+if (adue) {
+updated_pte |= PTE_A | (access_type == MMU_DATA_STORE ? PTE_D : 0);
+} else if (!(pte & PTE_A) || (access_type == MMU_DATA_STORE && !(pte &
PTE_D))) {
+return TRANSLATE_FAIL;
+}
/* Page table updates need to be atomic with MTTCG enabled */
if (updated_pte != pte && !is_debug) {
diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 6d5028cf84d0..bc3c45b11704 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -196,18 +196,14 @@ static bool cpu_cfg_offset_is_named_feat(uint32_t
ext_offset)
static void riscv_cpu_enable_named_feat(RISCVCPU *cpu, uint32_t feat_offset)
{
-switch (feat_offset) {
-case CPU_CFG_OFFSET(ext_zic64b):
+ /*
+ * All other named features are already enabled
+ * in riscv_tcg_cpu_instance_init().
+ */
+if (feat_offset == CPU_CFG_OFFSET(ext_zic64b)) {
cpu->cfg.cbom_blocksize = 64;
cpu->cfg.cbop_blocksize = 64;
cpu->cfg.cboz_blocksize = 64;
-break;
-case CPU_CFG_OFFSET(ext_svade):
-cpu->cfg.ext_svadu = false;
-break;
-default:
-/* Named feature already enabled in riscv_tcg_cpu_instance_init */
-return;
}
}
@@ -349,8 +345,6 @@ static void riscv_cpu_update_named_features(RISCVCPU *cpu)
cpu->cfg.ext_zic64b = cpu->cfg.cbom_blocksize == 64 &&
cpu->cfg.cbop_blocksize == 64 &&
cpu->cfg.cboz_blocksize == 64;
-
-cpu->cfg.ext_svade = !cpu->cfg.ext_svadu;
}
static void riscv_cpu_validate_g(RISCVCPU *cpu)
--
2.43.0
[PATCH v2 1/6] target/riscv/tcg: set 'mmu' with 'satp' in cpu_set_profile()
From: Daniel Henrique Barboza
Recent changes in options handling removed the 'mmu' default the bare
CPUs had, meaning that we must enable 'mmu' by hand when using the
rva22s64 profile CPU.
Given that this profile is setting a satp mode, it already implies that
we need a 'mmu'. Enable the 'mmu' in this case.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/tcg/tcg-cpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index da437975b429..88f92d1c7d2c 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -1107,6 +1107,7 @@ static void cpu_set_profile(Object *obj, Visitor *v,
const char *name,
#ifndef CONFIG_USER_ONLY
if (profile->satp_mode != RISCV_PROFILE_ATTR_UNUSED) {
+object_property_set_bool(obj, "mmu", true, NULL);
const char *satp_prop = satp_mode_str(profile->satp_mode,
riscv_cpu_is_32bit(cpu));
object_property_set_bool(obj, satp_prop, profile->enabled, NULL);
--
2.43.0
[PATCH v2 4/6] target/riscv: Reset henvcfg to zero
The hypervisor should decide what it wants to enable. Zero all
configuration enable bits on reset.
Also, commit ed67d63798f2 ("target/riscv: Update CSR bits name for
svadu extension") missed one reference to 'hade'. Change it now.
Fixes: 0af3f115e68e ("target/riscv: Add *envcfg.HADE related check in address
translation")
Fixes: ed67d63798f2 ("target/riscv: Update CSR bits name for svadu extension")
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Andrew Jones
---
target/riscv/cpu.c | 3 +--
target/riscv/csr.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 1ecd8a57ed02..7fd433daee74 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -961,8 +961,7 @@ static void riscv_cpu_reset_hold(Object *obj)
env->menvcfg = (cpu->cfg.ext_svpbmt ? MENVCFG_PBMTE : 0) |
(cpu->cfg.ext_svadu ? MENVCFG_ADUE : 0);
-env->henvcfg = (cpu->cfg.ext_svpbmt ? HENVCFG_PBMTE : 0) |
- (cpu->cfg.ext_svadu ? HENVCFG_ADUE : 0);
+env->henvcfg = 0;
/* Initialized default priorities of local interrupts. */
for (i = 0; i < ARRAY_SIZE(env->miprio); i++) {
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index d9a010387f72..93f7bc2cb48f 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -2115,7 +2115,7 @@ static RISCVException read_henvcfg(CPURISCVState *env,
int csrno,
/*
* henvcfg.pbmte is read_only 0 when menvcfg.pbmte = 0
* henvcfg.stce is read_only 0 when menvcfg.stce = 0
- * henvcfg.hade is read_only 0 when menvcfg.hade = 0
+ * henvcfg.adue is read_only 0 when menvcfg.adue = 0
*/
*val = env->henvcfg & (~(HENVCFG_PBMTE | HENVCFG_STCE | HENVCFG_ADUE) |
env->menvcfg);
--
2.43.0
Re: [PATCH 6/6] target/riscv: Promote svade to a normal extension
On Thu, Jan 25, 2024 at 04:53:19PM -0300, Daniel Henrique Barboza wrote:
> From: Andrew Jones
>
> Named features are extensions which don't make sense for users to
> control and are therefore not exposed on the command line. However,
> svade is an extension which makes sense for users to control, so treat
> it like a "normal" extension. The default is false, since QEMU has
> always implemented hardware A/D PTE bit updating, so users must opt into
> svade (or get it from a CPU type which enables it by default).
>
> Signed-off-by: Andrew Jones
> Reviewed-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index a56c2ff91d..4ddde25412 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1421,6 +1421,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
>
> MULTI_EXT_CFG_BOOL("smepmp", ext_smepmp, false),
> MULTI_EXT_CFG_BOOL("smstateen", ext_smstateen, false),
> +MULTI_EXT_CFG_BOOL("svade", ext_svade, false),
I forgot that the 'max' cpu type will ignore this off by default setting
and enable svade by default. I'll send a v2 of this series where I ensure
svade for 'max' also defaults false.
Thanks,
drew
> MULTI_EXT_CFG_BOOL("svadu", ext_svadu, true),
> MULTI_EXT_CFG_BOOL("svinval", ext_svinval, false),
> MULTI_EXT_CFG_BOOL("svnapot", ext_svnapot, false),
> @@ -1528,7 +1529,6 @@ const RISCVCPUMultiExtConfig
> riscv_cpu_experimental_exts[] = {
> * and priv_ver like regular extensions.
> */
> const RISCVCPUMultiExtConfig riscv_cpu_named_features[] = {
> -MULTI_EXT_CFG_BOOL("svade", ext_svade, true),
> MULTI_EXT_CFG_BOOL("zic64b", ext_zic64b, true),
>
> /*
> @@ -2175,8 +2175,6 @@ static RISCVCPUProfile RVA22U64 = {
> * Other named features that we already implement: Sstvecd, Sstvala,
> * Sscounterenw
> *
> - * Named features that we need to enable: svade
> - *
> * The remaining features/extensions comes from RVA22U64.
> */
> static RISCVCPUProfile RVA22S64 = {
> @@ -2188,11 +2186,11 @@ static RISCVCPUProfile RVA22S64 = {
> .ext_offsets = {
> /* rva22s64 exts */
> CPU_CFG_OFFSET(ext_zifencei), CPU_CFG_OFFSET(ext_svpbmt),
> -CPU_CFG_OFFSET(ext_svinval),
> +CPU_CFG_OFFSET(ext_svinval), CPU_CFG_OFFSET(ext_svade),
>
> /* rva22s64 named features */
> CPU_CFG_OFFSET(ext_sstvecd), CPU_CFG_OFFSET(ext_sstvala),
> -CPU_CFG_OFFSET(ext_sscounterenw), CPU_CFG_OFFSET(ext_svade),
> +CPU_CFG_OFFSET(ext_sscounterenw),
>
> RISCV_PROFILE_EXT_LIST_END
> }
> --
> 2.43.0
>
Re: Re: [PATCH v3 01/21] hw/riscv: Use misa_mxl instead of misa_mxl_max
On Thu, Jan 25, 2024 at 05:23:20PM +0900, Akihiko Odaki wrote:
> On 2024/01/24 17:16, Andrew Jones wrote:
> > On Wed, Jan 24, 2024 at 12:08:33PM +0900, Akihiko Odaki wrote:
> > > On 2024/01/23 17:20, Andrew Jones wrote:
> > > > On Mon, Jan 22, 2024 at 02:55:50PM +, Alex Bennée wrote:
> > > > > From: Akihiko Odaki
> > > > >
> > > > > The effective MXL value matters when booting.
> > > >
> > > > I'd prefer this commit message get some elaboration. riscv_is_32bit()
> > > > is used in a variety of contexts, some where it should be reporting
> > > > the max misa.mxl. However, when used for booting an S-mode kernel it
> > > > should indeed report the effective mxl. I think we're fine with the
> > > > change, though, because at init and on reset the effective mxl is set
> > > > to the max mxl, so, in those contexts, where riscv_is_32bit() should
> > > > be reporting the max, it does.
> > > >
> > > > >
> > > > > Signed-off-by: Akihiko Odaki
> > > > > Message-Id: <20240103173349.398526-23-alex.ben...@linaro.org>
> > > > > Message-Id: <20231213-riscv-v7-1-a760156a3...@daynix.com>
> > > > > Signed-off-by: Alex Bennée
> > > > > ---
> > > > >hw/riscv/boot.c | 2 +-
> > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> > > > > index 0ffca05189f..bc67c0bd189 100644
> > > > > --- a/hw/riscv/boot.c
> > > > > +++ b/hw/riscv/boot.c
> > > > > @@ -36,7 +36,7 @@
> > > > >bool riscv_is_32bit(RISCVHartArrayState *harts)
> > > > >{
> > > > > -return harts->harts[0].env.misa_mxl_max == MXL_RV32;
> > > > > +return harts->harts[0].env.misa_mxl == MXL_RV32;
> > > > >}
> > > >
> > > > Assuming everyone agrees with what I've written above, then maybe we
> > > > should write something similar in a comment above this function.
> > > >
> > > > Thanks,
> > > > drew
> > >
> > > The corresponding commit in my series has a more elaborated message:
> > > https://patchew.org/QEMU/20240115-riscv-v9-0-ff171e1ae...@daynix.com/20240115-riscv-v9-1-ff171e1ae...@daynix.com/
> >
> > I've pulled the message from that link and quoted it below
> >
> > > A later commit requires one extra step to retrieve misa_mxl_max. As
> > > misa_mxl is semantically more correct and does not need such a extra
> > > step, refer to misa_mxl instead. Below is the explanation why misa_mxl
> > > is more semantically correct to refer to than misa_mxl_max in this case.
> > >
> > > Currently misa_mxl always equals to misa_mxl_max so it does not matter
> >
> > That's true, but I think that's due to a bug in write_misa(), which
> > shouldn't be masking val with the extension mask until mxl has been
> > extracted.
>
> misa.MXL writes are not supported since the MISA write code was introduced
> with commit f18637cd611c ("RISC-V: Add misa runtime write support"). It
> doesn't matter if we allow the guest to write MXL; the firmware code is
> emulated by QEMU when QEMU loads a kernel.
Of course it matters. mxl will only change if we allow the guest to write
it. Being aware of when/why mxl changes, i.e. is no longer equal to the
max mxl, is the whole point of this patch.
>
> >
> > > which of misa_mxl or misa_mxl_max to refer to. However, it is possible
> > > to have different values for misa_mxl and misa_mxl_max if QEMU gains a
> > > new feature to load a RV32 kernel on a RV64 system, for example. For
> > > such a behavior, the real system will need the firmware to switch MXL to
> > > RV32, and if QEMU implements the same behavior, mxl will represent the
> > > MXL that corresponds to the kernel being loaded. Therefore, it is more
> > > appropriate to refer to mxl instead of misa_mxl_max when
> > > misa_mxl != misa_mxl_max.
> >
> > Right, but that doesn't say anything more than the original one line,
> > "The effective MXL value matters when booting."
>
> What do you think is missing?
Um, what I wrote below...
>
> >
> > What I'm looking for is a code comment explaining how riscv_is_32bit()
> > is always safe to use. Something like
> >
> > /*
> >* Checking the effective mxl is always correct, because t
Re: [PATCH v4 1/2] target/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS
On Wed, Jan 24, 2024 at 12:55:49PM +, Conor Dooley wrote:
> From: Conor Dooley
>
> A cpu may not have the same xlen as the compile time target, and
> misa_mxl_max is the source of truth for what the hart supports.
>
> The conversion from misa_mxl_max to xlen already has one user, so
> introduce a helper and use that to populate the isa string.
>
> Link:
> https://lore.kernel.org/qemu-riscv/20240108-efa3f83dcd3997dc0af458d7@orel/
> Signed-off-by: Conor Dooley
> ---
> I dropped the tags since I added the helper
> ---
> target/riscv/cpu.c | 9 -
> target/riscv/cpu.h | 1 +
> target/riscv/gdbstub.c | 2 +-
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index ad1df2318b..4aa4b2e988 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -307,6 +307,11 @@ void riscv_cpu_set_misa(CPURISCVState *env, RISCVMXL
> mxl, uint32_t ext)
> env->misa_ext_mask = env->misa_ext = ext;
> }
>
> +int riscv_cpu_max_xlen(CPURISCVState env)
> +{
> +return 16 << env.misa_mxl_max;
> +}
Something like this could probably be a static inline in the header.
> +
> #ifndef CONFIG_USER_ONLY
> static uint8_t satp_mode_from_str(const char *satp_mode_str)
> {
> @@ -2332,7 +2337,9 @@ char *riscv_isa_string(RISCVCPU *cpu)
> int i;
> const size_t maxlen = sizeof("rv128") + sizeof(riscv_single_letter_exts);
> char *isa_str = g_new(char, maxlen);
> -char *p = isa_str + snprintf(isa_str, maxlen, "rv%d", TARGET_LONG_BITS);
> +int xlen = riscv_cpu_max_xlen(cpu->env);
> +char *p = isa_str + snprintf(isa_str, maxlen, "rv%d", xlen);
> +
> for (i = 0; i < sizeof(riscv_single_letter_exts) - 1; i++) {
> if (cpu->env.misa_ext & RV(riscv_single_letter_exts[i])) {
> *p++ = qemu_tolower(riscv_single_letter_exts[i]);
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 05e83c4ac9..aacc031397 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -511,6 +511,7 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, int
> size,
> MMUAccessType access_type, int mmu_idx,
> bool probe, uintptr_t retaddr);
> char *riscv_isa_string(RISCVCPU *cpu);
> +int riscv_cpu_max_xlen(CPURISCVState env);
> bool riscv_cpu_option_set(const char *optname);
>
> #define cpu_mmu_index riscv_cpu_mmu_index
> diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
> index 58b3ace0fe..f15980fdcf 100644
> --- a/target/riscv/gdbstub.c
> +++ b/target/riscv/gdbstub.c
> @@ -218,7 +218,7 @@ static int riscv_gen_dynamic_csr_xml(CPUState *cs, int
> base_reg)
> CPURISCVState *env = >env;
> GString *s = g_string_new(NULL);
> riscv_csr_predicate_fn predicate;
> -int bitsize = 16 << env->misa_mxl_max;
> +int bitsize = riscv_cpu_max_xlen(*env);
> int i;
>
> #if !defined(CONFIG_USER_ONLY)
> --
> 2.43.0
>
Otherwise,
Reviewed-by: Andrew Jones
Re: Re: [PATCH v3 01/21] hw/riscv: Use misa_mxl instead of misa_mxl_max
On Wed, Jan 24, 2024 at 12:08:33PM +0900, Akihiko Odaki wrote:
> On 2024/01/23 17:20, Andrew Jones wrote:
> > On Mon, Jan 22, 2024 at 02:55:50PM +, Alex Bennée wrote:
> > > From: Akihiko Odaki
> > >
> > > The effective MXL value matters when booting.
> >
> > I'd prefer this commit message get some elaboration. riscv_is_32bit()
> > is used in a variety of contexts, some where it should be reporting
> > the max misa.mxl. However, when used for booting an S-mode kernel it
> > should indeed report the effective mxl. I think we're fine with the
> > change, though, because at init and on reset the effective mxl is set
> > to the max mxl, so, in those contexts, where riscv_is_32bit() should
> > be reporting the max, it does.
> >
> > >
> > > Signed-off-by: Akihiko Odaki
> > > Message-Id: <20240103173349.398526-23-alex.ben...@linaro.org>
> > > Message-Id: <20231213-riscv-v7-1-a760156a3...@daynix.com>
> > > Signed-off-by: Alex Bennée
> > > ---
> > > hw/riscv/boot.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> > > index 0ffca05189f..bc67c0bd189 100644
> > > --- a/hw/riscv/boot.c
> > > +++ b/hw/riscv/boot.c
> > > @@ -36,7 +36,7 @@
> > > bool riscv_is_32bit(RISCVHartArrayState *harts)
> > > {
> > > -return harts->harts[0].env.misa_mxl_max == MXL_RV32;
> > > +return harts->harts[0].env.misa_mxl == MXL_RV32;
> > > }
> >
> > Assuming everyone agrees with what I've written above, then maybe we
> > should write something similar in a comment above this function.
> >
> > Thanks,
> > drew
>
> The corresponding commit in my series has a more elaborated message:
> https://patchew.org/QEMU/20240115-riscv-v9-0-ff171e1ae...@daynix.com/20240115-riscv-v9-1-ff171e1ae...@daynix.com/
I've pulled the message from that link and quoted it below
> A later commit requires one extra step to retrieve misa_mxl_max. As
> misa_mxl is semantically more correct and does not need such a extra
> step, refer to misa_mxl instead. Below is the explanation why misa_mxl
> is more semantically correct to refer to than misa_mxl_max in this case.
>
> Currently misa_mxl always equals to misa_mxl_max so it does not matter
That's true, but I think that's due to a bug in write_misa(), which
shouldn't be masking val with the extension mask until mxl has been
extracted.
> which of misa_mxl or misa_mxl_max to refer to. However, it is possible
> to have different values for misa_mxl and misa_mxl_max if QEMU gains a
> new feature to load a RV32 kernel on a RV64 system, for example. For
> such a behavior, the real system will need the firmware to switch MXL to
> RV32, and if QEMU implements the same behavior, mxl will represent the
> MXL that corresponds to the kernel being loaded. Therefore, it is more
> appropriate to refer to mxl instead of misa_mxl_max when
> misa_mxl != misa_mxl_max.
Right, but that doesn't say anything more than the original one line,
"The effective MXL value matters when booting."
What I'm looking for is a code comment explaining how riscv_is_32bit()
is always safe to use. Something like
/*
* Checking the effective mxl is always correct, because the effective
* mxl will be equal to the max mxl at initialization and also on reset,
* which are the times when it should check the maximum mxl. Later, if
* firmware writes misa with a smaller mxl, then that mxl should be
* used in checks.
*/
Thanks,
drew
Re: [PATCH v4 3/4] target/riscv: SMBIOS support for RISC-V virt machine
On Tue, Jan 23, 2024 at 07:42:28PM +0100, Heinrich Schuchardt wrote: > Generate SMBIOS tables for the RISC-V mach-virt. > Add CONFIG_SMBIOS=y to the RISC-V default config. > Set the default processor family in the type 4 table. > > The implementation is based on the corresponding ARM and Loongson code. > > With the patch the following firmware tables are provided: > > etc/smbios/smbios-anchor > etc/smbios/smbios-tables > > Signed-off-by: Heinrich Schuchardt > --- > v4: > remove a superfluous #ifdef > v3: > use misa_mxl_max to determine bitness > v2: > set processor family > --- > hw/riscv/Kconfig | 1 + > hw/riscv/virt.c | 42 ++++++ > 2 files changed, 43 insertions(+) > Reviewed-by: Andrew Jones
Re: [PATCH v3 3/4] target/riscv: SMBIOS support for RISC-V virt machine
On Mon, Jan 22, 2024 at 02:07:57PM +0100, Heinrich Schuchardt wrote:
> Generate SMBIOS tables for the RISC-V mach-virt.
> Add CONFIG_SMBIOS=y to the RISC-V default config.
> Set the default processor family in the type 4 table.
>
> The implementation is based on the corresponding ARM and Loongson code.
>
> With the patch the following firmware tables are provided:
>
> etc/smbios/smbios-anchor
> etc/smbios/smbios-tables
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v3:
> use misa_mxl_max to determine bitness
> v2:
> set processor family
> ---
> hw/riscv/Kconfig | 1 +
> hw/riscv/virt.c | 44
> 2 files changed, 45 insertions(+)
>
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index a50717be87..5d644eb7b1 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -41,6 +41,7 @@ config RISCV_VIRT
> select RISCV_IMSIC
> select SIFIVE_PLIC
> select SIFIVE_TEST
> +select SMBIOS
> select VIRTIO_MMIO
> select FW_CFG_DMA
> select PLATFORM_BUS
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index f9fd1341fc..1b333af4f0 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -36,6 +36,7 @@
> #include "hw/riscv/boot.h"
> #include "hw/riscv/numa.h"
> #include "kvm/kvm_riscv.h"
> +#include "hw/firmware/smbios.h"
> #include "hw/intc/riscv_aclint.h"
> #include "hw/intc/riscv_aplic.h"
> #include "hw/intc/sifive_plic.h"
> @@ -1263,6 +1264,47 @@ static void create_platform_bus(RISCVVirtState *s,
> DeviceState *irqchip)
> sysbus_mmio_get_region(sysbus, 0));
> }
>
> +static void virt_build_smbios(RISCVVirtState *s)
> +{
> +MachineClass *mc = MACHINE_GET_CLASS(s);
> +MachineState *ms = MACHINE(s);
> +uint8_t *smbios_tables, *smbios_anchor;
> +size_t smbios_tables_len, smbios_anchor_len;
> +struct smbios_phys_mem_area mem_array;
> +const char *product = "QEMU Virtual Machine";
> +
> +if (kvm_enabled()) {
> +product = "KVM Virtual Machine";
> +}
> +
> +smbios_set_defaults("QEMU", product, mc->name, false,
> +true, SMBIOS_ENTRY_POINT_TYPE_64);
> +
> +if (riscv_is_32bit(>soc[0])) {
I just saw [1], but I think riscv_is_32bit() is still appropriate,
since, at the time SMBIOS tables are built, the effective mxl will
be set to the max mxl.
[1] 20240122145610.413836-2-alex.ben...@linaro.org
> +smbios_set_default_processor_family(0x200);
> +#if defined(TARGET_RISCV64)
> +} else {
> +smbios_set_default_processor_family(0x201);
> +#endif
Despite the #ifdef being in riscv_cpu_validate_misa_mxl(), I'd drop it
here. I didn't see any riscv_is_32bit() call sites which do this.
Thanks,
drew
> +}
> +
> +/* build the array of physical mem area from base_memmap */
> +mem_array.address = s->memmap[VIRT_DRAM].base;
> +mem_array.length = ms->ram_size;
> +
> +smbios_get_tables(ms, _array, 1,
> + _tables, _tables_len,
> + _anchor, _anchor_len,
> + _fatal);
> +
> +if (smbios_anchor) {
> +fw_cfg_add_file(s->fw_cfg, "etc/smbios/smbios-tables",
> +smbios_tables, smbios_tables_len);
> +fw_cfg_add_file(s->fw_cfg, "etc/smbios/smbios-anchor",
> +smbios_anchor, smbios_anchor_len);
> +}
> +}
> +
> static void virt_machine_done(Notifier *notifier, void *data)
> {
> RISCVVirtState *s = container_of(notifier, RISCVVirtState,
> @@ -1351,6 +1393,8 @@ static void virt_machine_done(Notifier *notifier, void
> *data)
> riscv_setup_direct_kernel(kernel_entry, fdt_load_addr);
> }
>
> +virt_build_smbios(s);
> +
> if (virt_is_acpi_enabled(s)) {
> virt_acpi_setup(s);
> }
> --
> 2.43.0
>
Re: [PATCH v3 01/21] hw/riscv: Use misa_mxl instead of misa_mxl_max
On Mon, Jan 22, 2024 at 02:55:50PM +, Alex Bennée wrote:
> From: Akihiko Odaki
>
> The effective MXL value matters when booting.
I'd prefer this commit message get some elaboration. riscv_is_32bit()
is used in a variety of contexts, some where it should be reporting
the max misa.mxl. However, when used for booting an S-mode kernel it
should indeed report the effective mxl. I think we're fine with the
change, though, because at init and on reset the effective mxl is set
to the max mxl, so, in those contexts, where riscv_is_32bit() should
be reporting the max, it does.
>
> Signed-off-by: Akihiko Odaki
> Message-Id: <20240103173349.398526-23-alex.ben...@linaro.org>
> Message-Id: <20231213-riscv-v7-1-a760156a3...@daynix.com>
> Signed-off-by: Alex Bennée
> ---
> hw/riscv/boot.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> index 0ffca05189f..bc67c0bd189 100644
> --- a/hw/riscv/boot.c
> +++ b/hw/riscv/boot.c
> @@ -36,7 +36,7 @@
>
> bool riscv_is_32bit(RISCVHartArrayState *harts)
> {
> -return harts->harts[0].env.misa_mxl_max == MXL_RV32;
> +return harts->harts[0].env.misa_mxl == MXL_RV32;
> }
Assuming everyone agrees with what I've written above, then maybe we
should write something similar in a comment above this function.
Thanks,
drew
Re: Re: [PATCH v2 3/4] target/riscv: SMBIOS support for RISC-V virt machine
On Mon, Jan 22, 2024 at 01:28:18PM +0100, Heinrich Schuchardt wrote:
> On 22.01.24 10:57, Andrew Jones wrote:
> > On Fri, Dec 29, 2023 at 01:07:23PM +0100, Heinrich Schuchardt wrote:
...
> > > +#if defined(TARGET_RISCV32)
> > > +smbios_set_default_processor_family(0x200);
> > > +#elif defined(TARGET_RISCV64)
> > > +smbios_set_default_processor_family(0x201);
> > > +#endif
> >
> > I think we should use misa_mxl_max to determine the family, rather than
> > TARGET_*, because, iirc, we're slowly working our ways towards allowing
> > rv32 cpus to be instantiated with qemu-system-riscv64.
>
> Hello Andrew,
>
> thank you for reviewing. I guess you mean something like:
>
> if (riscv_is_32bit(>soc[0])) {
> smbios_set_default_processor_family(0x200);
> #if defined(TARGET_RISCV64)
> } else {
> smbios_set_default_processor_family(0x201);
> #endif
> }
Yes, but I'm not sure we need the #ifdef around the 64-bit part.
>
> riscv_is_32bit returns harts->harts[0].env.misa_mxl_max == MXL_RV32.
>
> Some real hardware has a 32bit hart and multiple 64bit harts. Will QEMU
> support mixing harts with different bitness on the virt machine in future?
> In that case we would have to revisit the code using misa_mxl_max in
> multiple places.
>
Never say never, but I don't think there has been much effort to support
these types of configurations with a single QEMU binary. My googling is
failing me right now, but I seem to recall that there may have been
efforts to implement Arm big.LITTLE with multiprocess QEMU [1]. IOW, I
think we're safe to use misa_mxl_max, since we'll have one for each QEMU
instance and we'll use a different QEMU instance for each hart bitness.
[1] docs/system/multi-process.rst
Thanks,
drew
Re: [PATCH v2 4/4] qemu-options: enable -smbios option on RISC-V
On Fri, Dec 29, 2023 at 01:07:24PM +0100, Heinrich Schuchardt wrote:
> With SMBIOS support added for RISC-V we also should enable the command line
> option.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> new patch
> ---
> qemu-options.hx | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 7bdb414345..5ed82df11f 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2705,7 +2705,7 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
> "specify SMBIOS type 17 fields\n"
> "-smbios
> type=41[,designation=str][,kind=str][,instance=%d][,pcidev=str]\n"
> "specify SMBIOS type 41 fields\n",
> -QEMU_ARCH_I386 | QEMU_ARCH_ARM | QEMU_ARCH_LOONGARCH)
> +QEMU_ARCH_I386 | QEMU_ARCH_ARM | QEMU_ARCH_LOONGARCH | QEMU_ARCH_RISCV)
> SRST
> ``-smbios file=binary``
> Load SMBIOS entry from binary file.
> --
> 2.43.0
>
>
Reviewed-by: Andrew Jones
Re: [PATCH v2 2/4] smbios: function to set default processor family
On Fri, Dec 29, 2023 at 01:07:22PM +0100, Heinrich Schuchardt wrote:
> Provide a function to set the default processor family.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> new patch
> ---
> hw/smbios/smbios.c | 7 +++
> include/hw/firmware/smbios.h | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 647bc6d603..03fe736565 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -989,6 +989,13 @@ void smbios_set_cpuid(uint32_t version, uint32_t
> features)
> field = value;\
> }
>
> +void smbios_set_default_processor_family(uint16_t processor_family)
> +{
> +if (type4.processor_family <= 0x01) {
> +type4.processor_family = processor_family;
> +}
> +}
> +
> void smbios_set_defaults(const char *manufacturer, const char *product,
> const char *version, bool legacy_mode,
> bool uuid_encoded, SmbiosEntryPointType ep_type)
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index 7f3259a630..6e514982d4 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -295,6 +295,7 @@ void smbios_set_cpuid(uint32_t version, uint32_t
> features);
> void smbios_set_defaults(const char *manufacturer, const char *product,
> const char *version, bool legacy_mode,
> bool uuid_encoded, SmbiosEntryPointType ep_type);
> +void smbios_set_default_processor_family(uint16_t processor_family);
> uint8_t *smbios_get_table_legacy(MachineState *ms, size_t *length);
> void smbios_get_tables(MachineState *ms,
> const struct smbios_phys_mem_area *mem_array,
> --
> 2.43.0
>
>
Reviewed-by: Andrew Jones
Re: [PATCH v2 1/4] smbios: add processor-family option
On Fri, Dec 29, 2023 at 01:07:21PM +0100, Heinrich Schuchardt wrote:
> For RISC-V the SMBIOS standard requires specific values of the processor
> family value depending on the bitness of the CPU.
>
> Add a processor-family option for SMBIOS table 4.
>
> The value of processor-family may exceed 255 and therefore must be provided
> in the Processor Family 2 field. Set the Processor Family field to 0xFE
> which signals that the Processor Family 2 is used.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> new patch
> ---
> hw/smbios/smbios.c | 13 +++--
> qemu-options.hx| 4 ++--
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index 2a90601ac5..647bc6d603 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -102,6 +102,7 @@ static struct {
> #define DEFAULT_CPU_SPEED 2000
>
> static struct {
> +uint16_t processor_family;
> const char *sock_pfx, *manufacturer, *version, *serial, *asset, *part;
> uint64_t max_speed;
> uint64_t current_speed;
> @@ -110,6 +111,7 @@ static struct {
> .max_speed = DEFAULT_CPU_SPEED,
> .current_speed = DEFAULT_CPU_SPEED,
> .processor_id = 0,
> +.processor_family = 0x01, /* Other */
> };
>
> struct type8_instance {
> @@ -337,6 +339,10 @@ static const QemuOptDesc qemu_smbios_type4_opts[] = {
> .name = "part",
> .type = QEMU_OPT_STRING,
> .help = "part number",
> +}, {
> +.name = "processor-family",
> +.type = QEMU_OPT_NUMBER,
> +.help = "processor family",
> }, {
> .name = "processor-id",
> .type = QEMU_OPT_NUMBER,
> @@ -726,7 +732,7 @@ static void smbios_build_type_4_table(MachineState *ms,
> unsigned instance)
> snprintf(sock_str, sizeof(sock_str), "%s%2x", type4.sock_pfx, instance);
> SMBIOS_TABLE_SET_STR(4, socket_designation_str, sock_str);
> t->processor_type = 0x03; /* CPU */
> -t->processor_family = 0x01; /* Other */
> +t->processor_family = 0xfe; /* use Processor Family 2 field */
> SMBIOS_TABLE_SET_STR(4, processor_manufacturer_str, type4.manufacturer);
> if (type4.processor_id == 0) {
> t->processor_id[0] = cpu_to_le32(smbios_cpuid_version);
> @@ -758,7 +764,7 @@ static void smbios_build_type_4_table(MachineState *ms,
> unsigned instance)
> t->thread_count = (threads_per_socket > 255) ? 0xFF : threads_per_socket;
>
> t->processor_characteristics = cpu_to_le16(0x02); /* Unknown */
> -t->processor_family2 = cpu_to_le16(0x01); /* Other */
> +t->processor_family2 = cpu_to_le16(type4.processor_family);
>
> if (tbl_len == SMBIOS_TYPE_4_LEN_V30) {
> t->core_count2 = t->core_enabled2 = cpu_to_le16(cores_per_socket);
> @@ -1402,6 +1408,9 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
> return;
> }
> save_opt(_pfx, opts, "sock_pfx");
> +type4.processor_family = qemu_opt_get_number(opts,
> + "processor-family",
> + 0x01 /* Other */);
> save_opt(, opts, "manufacturer");
> save_opt(, opts, "version");
> save_opt(, opts, "serial");
> diff --git a/qemu-options.hx b/qemu-options.hx
> index b66570ae00..7bdb414345 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2694,7 +2694,7 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
> "specify SMBIOS type 3 fields\n"
> "-smbios
> type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str]\n"
> "
> [,asset=str][,part=str][,max-speed=%d][,current-speed=%d]\n"
> -" [,processor-id=%d]\n"
> +" [,processor-family=%d,processor-id=%d]\n"
> "specify SMBIOS type 4 fields\n"
> "-smbios
> type=8[,external_reference=str][,internal_reference=str][,connector_type=%d][,port_type=%d]\n"
> "specify SMBIOS type 8 fields\n"
> @@ -2722,7 +2722,7 @@ SRST
> ``-smbios
> type=3[,manufacturer=str][,version=str][,serial=str][,asset=str][,sku=str]``
> Specify SMBIOS type 3 fields
>
> -``-smbios
> type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str][,asset=str][,part=str][,processor-id=%d]``
> +``-smbios
> type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str][,asset=str][,part=str][,processor-family=%d][,processor-id=%d]``
> Specify SMBIOS type 4 fields
>
> ``-smbios type=11[,value=str][,path=filename]``
> --
> 2.43.0
>
>
Reviewed-by: Andrew Jones
Re: [PATCH v2 3/4] target/riscv: SMBIOS support for RISC-V virt machine
On Fri, Dec 29, 2023 at 01:07:23PM +0100, Heinrich Schuchardt wrote:
> Generate SMBIOS tables for the RISC-V mach-virt.
> Add CONFIG_SMBIOS=y to the RISC-V default config.
> Set the default processor family in the type 4 table.
>
> The implementation is based on the corresponding ARM and Loongson code.
>
> With the patch the following firmware tables are provided:
>
> etc/smbios/smbios-anchor
> etc/smbios/smbios-tables
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> set processor family
> ---
> hw/riscv/Kconfig | 1 +
> hw/riscv/virt.c | 42 ++
> 2 files changed, 43 insertions(+)
>
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index b6a5eb4452..1e11ac9432 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -41,6 +41,7 @@ config RISCV_VIRT
> select RISCV_IMSIC
> select SIFIVE_PLIC
> select SIFIVE_TEST
> +select SMBIOS
> select VIRTIO_MMIO
> select FW_CFG_DMA
> select PLATFORM_BUS
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index d2eac24156..a876dd8f34 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -36,6 +36,7 @@
> #include "hw/riscv/boot.h"
> #include "hw/riscv/numa.h"
> #include "kvm/kvm_riscv.h"
> +#include "hw/firmware/smbios.h"
> #include "hw/intc/riscv_aclint.h"
> #include "hw/intc/riscv_aplic.h"
> #include "hw/intc/riscv_imsic.h"
> @@ -1249,6 +1250,45 @@ static void create_platform_bus(RISCVVirtState *s,
> DeviceState *irqchip)
> sysbus_mmio_get_region(sysbus, 0));
> }
>
> +static void virt_build_smbios(RISCVVirtState *s)
> +{
> +MachineClass *mc = MACHINE_GET_CLASS(s);
> +MachineState *ms = MACHINE(s);
> +uint8_t *smbios_tables, *smbios_anchor;
> +size_t smbios_tables_len, smbios_anchor_len;
> +struct smbios_phys_mem_area mem_array;
> +const char *product = "QEMU Virtual Machine";
> +
> +if (kvm_enabled()) {
> +product = "KVM Virtual Machine";
> +}
> +
> +smbios_set_defaults("QEMU", product, mc->name, false,
> +true, SMBIOS_ENTRY_POINT_TYPE_64);
> +
> +#if defined(TARGET_RISCV32)
> +smbios_set_default_processor_family(0x200);
> +#elif defined(TARGET_RISCV64)
> +smbios_set_default_processor_family(0x201);
> +#endif
I think we should use misa_mxl_max to determine the family, rather than
TARGET_*, because, iirc, we're slowly working our ways towards allowing
rv32 cpus to be instantiated with qemu-system-riscv64.
> +
> +/* build the array of physical mem area from base_memmap */
> +mem_array.address = s->memmap[VIRT_DRAM].base;
> +mem_array.length = ms->ram_size;
> +
> +smbios_get_tables(ms, _array, 1,
> + _tables, _tables_len,
> + _anchor, _anchor_len,
> + _fatal);
> +
> +if (smbios_anchor) {
> +fw_cfg_add_file(s->fw_cfg, "etc/smbios/smbios-tables",
> +smbios_tables, smbios_tables_len);
> +fw_cfg_add_file(s->fw_cfg, "etc/smbios/smbios-anchor",
> +smbios_anchor, smbios_anchor_len);
> +}
> +}
> +
> static void virt_machine_done(Notifier *notifier, void *data)
> {
> RISCVVirtState *s = container_of(notifier, RISCVVirtState,
> @@ -1337,6 +1377,8 @@ static void virt_machine_done(Notifier *notifier, void
> *data)
> riscv_setup_direct_kernel(kernel_entry, fdt_load_addr);
> }
>
> +virt_build_smbios(s);
> +
> if (virt_is_acpi_enabled(s)) {
> virt_acpi_setup(s);
> }
> --
> 2.43.0
>
>
Otherwise,
Reviewed-by: Andrew Jones
Thanks,
drew
Re: Re: [PATCH 0/2] Export debug triggers as an extension
On Mon, Jan 22, 2024 at 03:42:10PM +1000, Alistair Francis wrote: > > > From memory the "debug" property is for the original debug spec: > > > https://github.com/riscv/riscv-debug-spec/releases/tag/task_group_vote > > > > > > That was ratified and is an official extension. AFAIK this is what is > > > in physical hardware as well. > > > > > > The actual PDF says draft though, I'm not sure what's going on there. > > > > > > The debug spec doesn't have a Z* name, so it's just "debug", at least > > > AFAIK. > > > > > > "sdtrig" seems to be a new backwards-incompatible extension doing > > > basically the same thing. What a mess ... > > > > I've done a bit of digging and I agree things are quite messy. Here are > > my discoveries: > > > > The debug option and the code for triggers was added in these commits: > > > > c9711bd778 target/riscv: cpu: Enable native debug feature > > 38b4e781a4 target/riscv: machine: Add debug state description > > b6092544fc target/riscv: csr: Hook debug CSR read/write > > 1acdb3b013 target/riscv: cpu: Add a config option for native debug > > 95799e36c1 target/riscv: Add initial support for the Sdtrig extension > > > > In March 2022 - since the commit refers to the Sdtrig extension name > > and from the date this was an implementation not of the ratified 0.13 > > debug spec (which did not have Sdtrig as a separate extension) but > > rather a version of the in development 1.0 debug spec. > > Yeah... We used the "stable" from master. That is our mistake there. > > I'm pretty sure we targeted the 0.13. The "Sdtrig" was only added in > the v4 as the changelog says: "mention Sdtrig extension in the commit" > > > > > It's not trivial to tell if it's closer to the ratified 0.13 version or > > the (hopefully soon to be frozen) 1.0 version. > > > > As the only part of the debug specification to be implemented is the > > triggers then effectively the debug option is x-sdtrig. > > > > I don't think there is any way for code running on the machine to > > identify what version of the debug is implemented - the appropriate > > register is only available for external debug. Once 1.0 is frozen then > > the presence of Sdtrig isa string would indicate 1.0 trigger support is > > available. > > > > According to JIRA - https://jira.riscv.org/browse/RVS-981 the debug > > specification should freeze this month. > > > > How about considering this as a solution: > > > > - Add a new x-sdtrig option that defaults to false > > - Deprecate debug option - but retain it with default on > > We can't deprecate a ratified spec. The 0.13 just seems to call it > "debug" so that's what we are stuck with > > > - Add warning if triggers are used and x-sdtrig is not enabled > > - Update the trigger implementation to match frozen spec > > We will need to support two versions, as there are two ratified specs. > We'll likely want to be allowed to deprecate ratified extensions as riscv evolves. Despite best intentions, extensions may be designed and ratified which ultimately fail to be of much utility, and new extensions will supersede old extensions. If QEMU keeps every extension it adds, then we'll slow progress on new extensions by maintaining old extension code. The old extensions will also bitrot or waste CI resources getting tested for no reason. I don't know the history of 'debug' and 'sdtrig', other than what I've read above, but, to me, it looks like 'debug' might be one of the first extensions which should be deprecated. Assuming we have a long enough deprecation period, then I think it's always safe to attempt a deprecation. If somebody shouts, then it can always be taken back off the chopping block. Thanks, drew
Re: [PATCH v2 2/2] target/riscv: Export sdtrig in ISA string
On Wed, Jan 17, 2024 at 07:54:12PM +0530, Himanshu Chauhan wrote:
> This patch adds "x-sdtrig" in the ISA string when sdtrig extension is enabled.
> The sdtrig extension may or may not be implemented in a system. Therefore, the
> -cpu rv64,x-sdtrig=
> option can be used to dynamically turn sdtrig extension on or off.
>
> Signed-off-by: Himanshu Chauhan
> ---
> target/riscv/cpu.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index c770a7e506..860e520730 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -153,6 +153,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(svinval, PRIV_VERSION_1_12_0, ext_svinval),
> ISA_EXT_DATA_ENTRY(svnapot, PRIV_VERSION_1_12_0, ext_svnapot),
> ISA_EXT_DATA_ENTRY(svpbmt, PRIV_VERSION_1_12_0, ext_svpbmt),
> +ISA_EXT_DATA_ENTRY(x-sdtrig, PRIV_VERSION_1_12_0, ext_sdtrig),
> ISA_EXT_DATA_ENTRY(xtheadba, PRIV_VERSION_1_11_0, ext_xtheadba),
> ISA_EXT_DATA_ENTRY(xtheadbb, PRIV_VERSION_1_11_0, ext_xtheadbb),
> ISA_EXT_DATA_ENTRY(xtheadbs, PRIV_VERSION_1_11_0, ext_xtheadbs),
> --
> 2.34.1
>
>
We don't want the 'x-' part to show up in the ISA string. isa_edata_arr[]
should get an entry without x-, and the x- property should be added to
riscv_cpu_experimental_exts[].
Thanks,
drew
Re: Re: Re: [PATCH 1/3] target/riscv: Add infrastructure for 'B' MISA extension
On Thu, Jan 11, 2024 at 03:17:25PM +, Rob Bradford wrote: > + Ved > > On Thu, 2024-01-11 at 14:14 +0100, Andrew Jones wrote: > > On Thu, Jan 11, 2024 at 02:07:34PM +0100, Andrew Jones wrote: > > > On Tue, Jan 09, 2024 at 05:07:35PM +, Rob Bradford wrote: > > > > Add the infrastructure for the 'B' extension which is the union > > > > of the > > > > Zba, Zbb and Zbs instructions. > > > > > > > > Signed-off-by: Rob Bradford > > > > --- > > > > target/riscv/cpu.c | 5 +++-- > > > > target/riscv/cpu.h | 1 + > > > > target/riscv/tcg/tcg-cpu.c | 1 + > > > > 3 files changed, 5 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > > > > index b07a76ef6b..22f8e527ff 100644 > > > > --- a/target/riscv/cpu.c > > > > +++ b/target/riscv/cpu.c > > > > @@ -38,9 +38,9 @@ > > > > #include "tcg/tcg.h" > > > > > > > > /* RISC-V CPU definitions */ > > > > -static const char riscv_single_letter_exts[] = "IEMAFDQCPVH"; > > > > +static const char riscv_single_letter_exts[] = "IEMAFDQCBPVH"; > > > > > > Is there a corresponding proposed change to table 29.1 of the > > > nonpriv spec > > > which states B comes after C and before P? If so, can you provide a > > > link > > > to it? Otherwise, how do we know that? > > > > Oh, I see. The unpriv spec B chapter comes after the C chapter (and > > before > > J, P, ...). I still wonder if we'll have a 29.1 table update with the > > ratification of this extension though. > > > > > > I agree it's a bit confusing - but the order is established by the > table in the unprivileged spec and the table explanation also makes > this clear. > > """ > Table 27.1: Standard ISA extension names. The table also defines the > canonical order in which > extension names must appear in the name string, with top-to-bottom in > table indicating first-to-last > in the name string, e.g., RV32IMACV is legal, whereas RV32IMAVC is not. > """ Yes, this is the table I was referring to when I referenced "table 29.1 of the nonpriv spec". Since there's a chance I was looking at too old a spec I've now gone straight to the source, https://github.com/riscv/riscv-isa-manual/blob/main/src/naming.adoc but I still don't see B there. Do you see B in the table you're looking at? > > The proposed B specification does not make any remarks about the > ordering in the ISA definition string. [1] I would worry there would be > a lot of software churn if this ordering were to be changed. The ordering shouldn't change, but I can't see where it's documented (beyond the B chapter coming after the C chapter). Thanks, drew
Re: [PATCH 1/3] target/riscv: Add infrastructure for 'B' MISA extension
On Tue, Jan 09, 2024 at 05:07:35PM +, Rob Bradford wrote:
> Add the infrastructure for the 'B' extension which is the union of the
> Zba, Zbb and Zbs instructions.
>
> Signed-off-by: Rob Bradford
> ---
> target/riscv/cpu.c | 5 +++--
> target/riscv/cpu.h | 1 +
> target/riscv/tcg/tcg-cpu.c | 1 +
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index b07a76ef6b..22f8e527ff 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -38,9 +38,9 @@
> #include "tcg/tcg.h"
>
> /* RISC-V CPU definitions */
> -static const char riscv_single_letter_exts[] = "IEMAFDQCPVH";
> +static const char riscv_single_letter_exts[] = "IEMAFDQCBPVH";
> const uint32_t misa_bits[] = {RVI, RVE, RVM, RVA, RVF, RVD, RVV,
> - RVC, RVS, RVU, RVH, RVJ, RVG, 0};
> + RVC, RVS, RVU, RVH, RVJ, RVG, RVB, 0};
>
> /*
> * From vector_helper.c
> @@ -1251,6 +1251,7 @@ static const MISAExtInfo misa_ext_info_arr[] = {
> MISA_EXT_INFO(RVJ, "x-j", "Dynamic translated languages"),
> MISA_EXT_INFO(RVV, "v", "Vector operations"),
> MISA_EXT_INFO(RVG, "g", "General purpose (IMAFD_Zicsr_Zifencei)"),
> +MISA_EXT_INFO(RVB, "x-b", "Bit manipulation (Zba_Zbb_Zbs)")
> };
>
> static int riscv_validate_misa_info_idx(uint32_t bit)
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 2725528bb5..756a345513 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -69,6 +69,7 @@ typedef struct CPUArchState CPURISCVState;
> #define RVH RV('H')
> #define RVJ RV('J')
> #define RVG RV('G')
> +#define RVB RV('B')
>
> extern const uint32_t misa_bits[];
> const char *riscv_get_misa_ext_name(uint32_t bit);
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index 8a35683a34..fda54671d5 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -791,6 +791,7 @@ static const RISCVCPUMisaExtConfig misa_ext_cfgs[] = {
> MISA_CFG(RVJ, false),
> MISA_CFG(RVV, false),
> MISA_CFG(RVG, false),
> +MISA_CFG(RVB, false)
> };
>
> /*
> --
> 2.43.0
>
>
Reviewed-by: Andrew Jones
Re: Re: [PATCH 1/3] target/riscv: Add infrastructure for 'B' MISA extension
On Thu, Jan 11, 2024 at 02:07:34PM +0100, Andrew Jones wrote: > On Tue, Jan 09, 2024 at 05:07:35PM +, Rob Bradford wrote: > > Add the infrastructure for the 'B' extension which is the union of the > > Zba, Zbb and Zbs instructions. > > > > Signed-off-by: Rob Bradford > > --- > > target/riscv/cpu.c | 5 +++-- > > target/riscv/cpu.h | 1 + > > target/riscv/tcg/tcg-cpu.c | 1 + > > 3 files changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > > index b07a76ef6b..22f8e527ff 100644 > > --- a/target/riscv/cpu.c > > +++ b/target/riscv/cpu.c > > @@ -38,9 +38,9 @@ > > #include "tcg/tcg.h" > > > > /* RISC-V CPU definitions */ > > -static const char riscv_single_letter_exts[] = "IEMAFDQCPVH"; > > +static const char riscv_single_letter_exts[] = "IEMAFDQCBPVH"; > > Is there a corresponding proposed change to table 29.1 of the nonpriv spec > which states B comes after C and before P? If so, can you provide a link > to it? Otherwise, how do we know that? Oh, I see. The unpriv spec B chapter comes after the C chapter (and before J, P, ...). I still wonder if we'll have a 29.1 table update with the ratification of this extension though. Thanks, drew
Re: [PATCH 2/3] target/riscv: Add step to validate 'B' extension
On Tue, Jan 09, 2024 at 05:07:36PM +, Rob Bradford wrote:
> If the B extension is enabled warn if the user has disabled any of the
> required extensions that are part of the 'B' extension. Conversely
> enable the extensions that make up the 'B' extension if it is enabled.
>
> Signed-off-by: Rob Bradford
> ---
> target/riscv/tcg/tcg-cpu.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index fda54671d5..f10871d352 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -273,6 +273,35 @@ static void
> riscv_cpu_disable_priv_spec_isa_exts(RISCVCPU *cpu)
> }
> }
>
> +static void riscv_cpu_validate_b(RISCVCPU *cpu)
> +{
> +const char *warn_msg = "RVB mandates disabled extension %s";
> +
> +if (!cpu->cfg.ext_zba) {
> +if (!cpu_cfg_ext_is_user_set(CPU_CFG_OFFSET(ext_zba))) {
> +cpu->cfg.ext_zba = true;
> +} else {
> +warn_report(warn_msg, "zba");
> +}
> +}
> +
> +if (!cpu->cfg.ext_zbb) {
> +if (!cpu_cfg_ext_is_user_set(CPU_CFG_OFFSET(ext_zbb))) {
> +cpu->cfg.ext_zbb = true;
> +} else {
> +warn_report(warn_msg, "zbb");
> +}
> +}
> +
> +if (!cpu->cfg.ext_zbs) {
> +if (!cpu_cfg_ext_is_user_set(CPU_CFG_OFFSET(ext_zbs))) {
> +cpu->cfg.ext_zbs = true;
> +} else {
> +warn_report(warn_msg, "zbs");
> +}
> +}
> +}
> +
> /*
> * Check consistency between chosen extensions while setting
> * cpu->cfg accordingly.
> @@ -309,6 +338,10 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu,
> Error **errp)
> env->misa_ext_mask |= RVI | RVM | RVA | RVF | RVD;
> }
>
> +if (riscv_has_ext(env, RVB)) {
> + riscv_cpu_validate_b(cpu);
> +}
> +
> if (riscv_has_ext(env, RVI) && riscv_has_ext(env, RVE)) {
> error_setg(errp,
> "I and E extensions are incompatible");
> --
> 2.43.0
>
>
Reviewed-by: Andrew Jones
Re: [PATCH 1/3] target/riscv: Add infrastructure for 'B' MISA extension
On Tue, Jan 09, 2024 at 05:07:35PM +, Rob Bradford wrote:
> Add the infrastructure for the 'B' extension which is the union of the
> Zba, Zbb and Zbs instructions.
>
> Signed-off-by: Rob Bradford
> ---
> target/riscv/cpu.c | 5 +++--
> target/riscv/cpu.h | 1 +
> target/riscv/tcg/tcg-cpu.c | 1 +
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index b07a76ef6b..22f8e527ff 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -38,9 +38,9 @@
> #include "tcg/tcg.h"
>
> /* RISC-V CPU definitions */
> -static const char riscv_single_letter_exts[] = "IEMAFDQCPVH";
> +static const char riscv_single_letter_exts[] = "IEMAFDQCBPVH";
Is there a corresponding proposed change to table 29.1 of the nonpriv spec
which states B comes after C and before P? If so, can you provide a link
to it? Otherwise, how do we know that?
Thanks,
drew
> const uint32_t misa_bits[] = {RVI, RVE, RVM, RVA, RVF, RVD, RVV,
> - RVC, RVS, RVU, RVH, RVJ, RVG, 0};
> + RVC, RVS, RVU, RVH, RVJ, RVG, RVB, 0};
>
> /*
> * From vector_helper.c
> @@ -1251,6 +1251,7 @@ static const MISAExtInfo misa_ext_info_arr[] = {
> MISA_EXT_INFO(RVJ, "x-j", "Dynamic translated languages"),
> MISA_EXT_INFO(RVV, "v", "Vector operations"),
> MISA_EXT_INFO(RVG, "g", "General purpose (IMAFD_Zicsr_Zifencei)"),
> +MISA_EXT_INFO(RVB, "x-b", "Bit manipulation (Zba_Zbb_Zbs)")
> };
>
> static int riscv_validate_misa_info_idx(uint32_t bit)
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 2725528bb5..756a345513 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -69,6 +69,7 @@ typedef struct CPUArchState CPURISCVState;
> #define RVH RV('H')
> #define RVJ RV('J')
> #define RVG RV('G')
> +#define RVB RV('B')
>
> extern const uint32_t misa_bits[];
> const char *riscv_get_misa_ext_name(uint32_t bit);
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index 8a35683a34..fda54671d5 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -791,6 +791,7 @@ static const RISCVCPUMisaExtConfig misa_ext_cfgs[] = {
> MISA_CFG(RVJ, false),
> MISA_CFG(RVV, false),
> MISA_CFG(RVG, false),
> +MISA_CFG(RVB, false)
> };
>
> /*
> --
> 2.43.0
>
>
Re: Re: [PATCH 3/3] target/riscv: Enable 'B' extension on max CPU type
On Wed, Jan 10, 2024 at 03:32:21PM -0300, Daniel Henrique Barboza wrote: > > > On 1/9/24 14:07, Rob Bradford wrote: > > Signed-off-by: Rob Bradford > > --- > > target/riscv/tcg/tcg-cpu.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c > > index f10871d352..9705daec93 100644 > > --- a/target/riscv/tcg/tcg-cpu.c > > +++ b/target/riscv/tcg/tcg-cpu.c > > @@ -999,7 +999,8 @@ static void riscv_init_max_cpu_extensions(Object *obj) > > const RISCVCPUMultiExtConfig *prop; > > /* Enable RVG, RVJ and RVV that are disabled by default */ > > -riscv_cpu_set_misa(env, env->misa_mxl, env->misa_ext | RVG | RVJ | > > RVV); > > +riscv_cpu_set_misa(env, env->misa_mxl, > > + env->misa_ext | RVG | RVJ | RVV | RVB); > > I'm aware that we decided a while ago the 'max' CPU could only have > non-vendor and > non-experimental extensions enabled. RVB is experimental, so in theory we > shouldn't > enable it. > > But RVB is an alias for zba, zbb and zbs, extensions that the 'max' CPU is > already > enabling. In this case I think it's sensible to enable RVB here since it > would just > reflect stuff that it's already happening. It's also setting the B bit in misa, which, until this spec is at least frozen, is a reserved bit and reserved bits "must return zero when read". I don't want to stand in the way of progress and it seems 99.9% likely that the spec will be frozen and ratified, but, if we want to stick to our policies (which we should document), then even the 'max' cpu type should require x-b be added to the command line if it wants the B bit set in misa. Thanks, drew
Re: [PATCH v3 2/2] target/riscv: support new isa extension detection devicetree properties
MachineState *ms = MACHINE(s);
> uint32_t *clint_cells;
> uint32_t cpu_phandle, intc_phandle, phandle = 1;
> -char *name, *mem_name, *clint_name, *clust_name;
> +char *mem_name, *clint_name, *clust_name;
> char *core_name, *cpu_name, *intc_name;
> static const char * const clint_compat[2] = {
> "sifive,clint0", "riscv,clint0"
> @@ -113,9 +113,7 @@ static void create_fdt(SpikeState *s, const MemMapEntry
> *memmap,
> } else {
> qemu_fdt_setprop_string(fdt, cpu_name, "mmu-type",
> "riscv,sv48");
> }
> -name = riscv_isa_string(>soc[socket].harts[cpu]);
> -qemu_fdt_setprop_string(fdt, cpu_name, "riscv,isa", name);
> -g_free(name);
> +riscv_isa_write_fdt(>soc[socket].harts[cpu], fdt, cpu_name);
> qemu_fdt_setprop_string(fdt, cpu_name, "compatible", "riscv");
> qemu_fdt_setprop_string(fdt, cpu_name, "status", "okay");
> qemu_fdt_setprop_cell(fdt, cpu_name, "reg",
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index f9fd1341fc..c47b2d397a 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -215,7 +215,7 @@ static void create_fdt_socket_cpus(RISCVVirtState *s, int
> socket,
> int cpu;
> uint32_t cpu_phandle;
> MachineState *ms = MACHINE(s);
> -char *name, *cpu_name, *core_name, *intc_name, *sv_name;
> +char *cpu_name, *core_name, *intc_name, *sv_name;
> bool is_32_bit = riscv_is_32bit(>soc[0]);
> uint8_t satp_mode_max;
>
> @@ -236,9 +236,7 @@ static void create_fdt_socket_cpus(RISCVVirtState *s, int
> socket,
> g_free(sv_name);
> }
>
> -name = riscv_isa_string(cpu_ptr);
> -qemu_fdt_setprop_string(ms->fdt, cpu_name, "riscv,isa", name);
> -g_free(name);
> +riscv_isa_write_fdt(cpu_ptr, ms->fdt, cpu_name);
>
> if (cpu_ptr->cfg.ext_zicbom) {
> qemu_fdt_setprop_cell(ms->fdt, cpu_name, "riscv,cbom-block-size",
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 5b5da970f2..1c8c81ca4c 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -31,6 +31,7 @@
> #include "hw/qdev-properties.h"
> #include "migration/vmstate.h"
> #include "fpu/softfloat-helpers.h"
> +#include "sysemu/device_tree.h"
> #include "sysemu/kvm.h"
> #include "sysemu/tcg.h"
> #include "kvm/kvm_riscv.h"
> @@ -1875,6 +1876,58 @@ char *riscv_isa_string(RISCVCPU *cpu)
> return isa_str;
> }
>
> +#ifndef CONFIG_USER_ONLY
> +static char **riscv_isa_extensions_list(RISCVCPU *cpu, int *count)
> +{
> +int maxlen = ARRAY_SIZE(riscv_single_letter_exts) +
> ARRAY_SIZE(isa_edata_arr);
> +char **extensions = g_new(char *, maxlen);
> +
> +for (int i = 0; i < sizeof(riscv_single_letter_exts) - 1; i++) {
> +if (cpu->env.misa_ext & RV(riscv_single_letter_exts[i])) {
> +extensions[*count] = g_new(char, 2);
> +snprintf(extensions[*count], 2, "%c",
> + qemu_tolower(riscv_single_letter_exts[i]));
> +(*count)++;
> +}
> +}
> +
> +for (const RISCVIsaExtData *edata = isa_edata_arr; edata->name; edata++)
> {
> +if (isa_ext_is_enabled(cpu, edata->ext_enable_offset)) {
> +extensions[*count] = g_strdup(edata->name);
> +(*count)++;
> +}
> +}
> +
> +return extensions;
> +}
> +
> +void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename)
> +{
> +const size_t maxlen = sizeof("rv128i");
> +g_autofree char *isa_base = g_new(char, maxlen);
> +g_autofree char *riscv_isa;
> +char **isa_extensions;
> +int count = 0;
> +int xlen = 16 << cpu->env.misa_mxl_max;
> +
> +riscv_isa = riscv_isa_string(cpu);
> +qemu_fdt_setprop_string(fdt, nodename, "riscv,isa", riscv_isa);
> +
> +snprintf(isa_base, maxlen, "rv%di", xlen);
> +qemu_fdt_setprop_string(fdt, nodename, "riscv,isa-base", isa_base);
> +
> +isa_extensions = riscv_isa_extensions_list(cpu, );
> +qemu_fdt_setprop_string_array(fdt, nodename, "riscv,isa-extensions",
> + isa_extensions, count);
> +
> +for (int i = 0; i < count; i++) {
> +g_free(isa_extensions[i]);
> +}
> +
> +g_free(isa_extensions);
> +}
> +#endif
> +
> #define DEFINE_CPU(type_name, initfn) \
> { \
> .name = type_name, \
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 5f3955c38d..192d0c2d31 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -510,6 +510,7 @@ char *riscv_isa_string(RISCVCPU *cpu);
> #define cpu_mmu_index riscv_cpu_mmu_index
>
> #ifndef CONFIG_USER_ONLY
> +void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename);
> void riscv_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr,
> vaddr addr, unsigned size,
> MMUAccessType access_type,
> --
> 2.39.2
>
Reviewed-by: Andrew Jones
Re: [PATCH v3 1/2] target/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS
On Wed, Jan 10, 2024 at 10:25:36AM +, Conor Dooley wrote:
> From: Conor Dooley
>
> A cpu may not have the same xlen as the compile time target, and
> misa_mxl_max is the source of truth for what the hart supports.
>
> Reported-by: Andrew Jones
> Link:
> https://lore.kernel.org/qemu-riscv/20240108-efa3f83dcd3997dc0af458d7@orel/
> Signed-off-by: Conor Dooley
> ---
> Perhaps this misa_mxl_max -> width conversion should exist as a macro?
> There's now 3 individual conversions of this type - two I added and one
> in the gdb code.
A macro is a good idea. I had to go look at Table 3.1 of the priv spec to
understand the 16 shift stuff.
> ---
> target/riscv/cpu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 8cbfc7e781..5b5da970f2 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1860,7 +1860,9 @@ char *riscv_isa_string(RISCVCPU *cpu)
> int i;
> const size_t maxlen = sizeof("rv128") + sizeof(riscv_single_letter_exts);
> char *isa_str = g_new(char, maxlen);
> -char *p = isa_str + snprintf(isa_str, maxlen, "rv%d", TARGET_LONG_BITS);
> +int xlen = 16 << cpu->env.misa_mxl_max;
> +char *p = isa_str + snprintf(isa_str, maxlen, "rv%d", xlen);
> +
> for (i = 0; i < sizeof(riscv_single_letter_exts) - 1; i++) {
> if (cpu->env.misa_ext & RV(riscv_single_letter_exts[i])) {
> *p++ = qemu_tolower(riscv_single_letter_exts[i]);
> --
> 2.39.2
>
Reviewed-by: Andrew Jones
Re: Re: [PATCH v2] riscv: support new isa extension detection devicetree properties
On Mon, Dec 18, 2023 at 02:37:55PM +1000, Alistair Francis wrote:
...
> > +void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename)
> > +{
> > +const size_t maxlen = sizeof("rv128i");
> > +g_autofree char *isa_base = g_new(char, maxlen);
> > +g_autofree char *riscv_isa;
> > +char **isa_extensions;
> > +int count = 0;
> > +
> > +riscv_isa = riscv_isa_string(cpu);
> > +qemu_fdt_setprop_string(fdt, nodename, "riscv,isa", riscv_isa);
> > +
> > +snprintf(isa_base, maxlen, "rv%di", TARGET_LONG_BITS);
>
> This should dynamically come from misa_mxl_max not the compile time target
>
Need to also fix riscv_isa_string()
Thanks,
drew
Re: [PATCH v2] riscv: support new isa extension detection devicetree properties
sa = riscv_isa_string(cpu);
> +qemu_fdt_setprop_string(fdt, nodename, "riscv,isa", riscv_isa);
> +
> +snprintf(isa_base, maxlen, "rv%di", TARGET_LONG_BITS);
> +qemu_fdt_setprop_string(fdt, nodename, "riscv,isa-base", isa_base);
> +
> +isa_extensions = riscv_isa_extensions_list(cpu, );
> +qemu_fdt_setprop_string_array(fdt, nodename, "riscv,isa-extensions",
> + isa_extensions, count);
> +
> +for (int i = 0; i < count; i++) {
> +g_free(isa_extensions[i]);
> +}
Need g_free(isa_extensions) here.
> +}
> +#endif
> +
> static gint riscv_cpu_list_compare(gconstpointer a, gconstpointer b)
> {
> ObjectClass *class_a = (ObjectClass *)a;
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index bf58b0f0b5..5bbce607c4 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -496,6 +496,7 @@ void riscv_cpu_list(void);
> #define cpu_mmu_index riscv_cpu_mmu_index
>
> #ifndef CONFIG_USER_ONLY
> +void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename);
> void riscv_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr,
> vaddr addr, unsigned size,
> MMUAccessType access_type,
> --
> 2.39.2
>
>
Otherwise,
Reviewed-by: Andrew Jones
Thanks,
drew
Re: Re: [PATCH v13 00/26] riscv: RVA22 profiles support
On Tue, Jan 02, 2024 at 08:40:48AM -0300, Daniel Henrique Barboza wrote: > Hi, > > Drew brought to my attention the following post on the tech-unprivileged > mailing > list: > > "Architecture Review Committee meeting minutes, 12/19/23" > https://lists.riscv.org/g/tech-unprivileged/message/611 > > Second paragraph mentions: > > "In response to some recent discussion in the Apps and Tools HC about how > profiles should > be represented in GCC/LLVM, the ARC provides this answer: compilers should > use a single parameter > for an ISA string. An ISA string begins with either a base ISA name (e.g. > rv64i) or a profile name > (e.g. rva23u64) and is optionally followed by additional extensions (e.g. > rv64imac_zicond or > rva23u64_zfh_zicond). If the ISA string begins with a profile name, it is > equivalent to > replacing the profile name with its mandatory base ISA and its mandatory > extensions; any > optional extensions in a profile must be explicitly named if their inclusion > is desired. > ISAs are sets, and concatenating strings takes the union, so redundancy is > legal (e.g. > rva23u64, rva23u64_zicsr, and rva23u64_zicsr_zicsr are all valid and > equivalent)." > > The takeaways from it: > > - this implementation is compliant with how profiles are interpreted, i.e. a > profile is > considered a set of the mandatory base ISA and mandatory extensions, and any > additional/optional > extensions must be explicitly named; Yes, it's good QEMU's RISC-V CPU model command line will be consistent with the above paragraph (and then presumably with RISC-V compiler "ISA strings") > > - our ISA string format is also since we use the base ISA name + extensions > format already. > This series don't change/add anything in this regard. > > > If we have enough demand for it, I can do a follow-up to add support for the > ISA string > profile format. I.e. this: > > $ build/qemu-system-riscv64 -M virt -cpu rva22s64 (...) > > # cat /proc/device-tree/cpus/cpu@0/riscv,isa > rv64imafdc_zicbom_zicbop_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zfhmin_zca_zcd_zba_zbb_zbs_zkt_svinval_svpbmt > > Would become this: > > # cat /proc/device-tree/cpus/cpu@0/riscv,isa > rva22s64 We can't do that. The "ISA string" referred to in the above command line isn't the ISA string specified in "ISA Extension Naming Conventions" of the unpriv spec, it's the string given to the compiler to tell it which extensions it may assume when generating instructions. Thanks, drew
Re: [PATCH for-9.0 5/5] target/riscv/kvm: rename riscv_reg_id() to riscv_reg_id_ulong()
void kvm_riscv_read_multiext_legacy(RISCVCPU *cpu,
> KVMCPUConfig *multi_ext_cfg = _multi_ext_cfgs[i];
> struct kvm_one_reg reg;
>
> -reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_ISA_EXT,
> - multi_ext_cfg->kvm_reg_id);
> +reg.id = kvm_riscv_reg_id_ulong(env, KVM_REG_RISCV_ISA_EXT,
> +multi_ext_cfg->kvm_reg_id);
> reg.addr = (uint64_t)
> ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, );
> if (ret != 0) {
> @@ -925,8 +927,8 @@ static void kvm_riscv_init_multiext_cfg(RISCVCPU *cpu,
> KVMScratchCPU *kvmcpu)
>
> for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) {
> multi_ext_cfg = _multi_ext_cfgs[i];
> -reg_id = kvm_riscv_reg_id(>env, KVM_REG_RISCV_ISA_EXT,
> - multi_ext_cfg->kvm_reg_id);
> +reg_id = kvm_riscv_reg_id_ulong(>env, KVM_REG_RISCV_ISA_EXT,
> +multi_ext_cfg->kvm_reg_id);
> reg_search = bsearch(_id, reglist->reg, reglist->n,
> sizeof(uint64_t), uint64_cmp);
> if (!reg_search) {
> --
> 2.41.0
>
Reviewed-by: Andrew Jones
Re: [PATCH for-9.0 4/5] target/riscv/kvm: add RISCV_CONFIG_REG()
On Fri, Dec 08, 2023 at 03:38:34PM -0300, Daniel Henrique Barboza wrote:
> Create a RISCV_CONFIG_REG() macro, similar to what other regs use, to
> hide away some of the boilerplate.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 476e5d4b3d..11797338ec 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -88,6 +88,10 @@ static uint64_t kvm_riscv_reg_id_u64(uint64_t type,
> uint64_t idx)
> #define RISCV_CSR_REG(env, name) kvm_riscv_reg_id(env, KVM_REG_RISCV_CSR, \
> KVM_REG_RISCV_CSR_REG(name))
>
> +#define RISCV_CONFIG_REG(env, name) \
> +kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG, \
> + KVM_REG_RISCV_CONFIG_REG(name))
> +
> #define RISCV_TIMER_REG(name) kvm_riscv_reg_id_u64(KVM_REG_RISCV_TIMER, \
> KVM_REG_RISCV_TIMER_REG(name))
>
> @@ -756,24 +760,21 @@ static void kvm_riscv_init_machine_ids(RISCVCPU *cpu,
> KVMScratchCPU *kvmcpu)
> struct kvm_one_reg reg;
> int ret;
>
> -reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
> - KVM_REG_RISCV_CONFIG_REG(mvendorid));
> +reg.id = RISCV_CONFIG_REG(env, mvendorid);
> reg.addr = (uint64_t)>cfg.mvendorid;
> ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, );
> if (ret != 0) {
> error_report("Unable to retrieve mvendorid from host, error %d",
> ret);
> }
>
> -reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
> - KVM_REG_RISCV_CONFIG_REG(marchid));
> +reg.id = RISCV_CONFIG_REG(env, marchid);
> reg.addr = (uint64_t)>cfg.marchid;
> ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, );
> if (ret != 0) {
> error_report("Unable to retrieve marchid from host, error %d", ret);
> }
>
> -reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
> - KVM_REG_RISCV_CONFIG_REG(mimpid));
> +reg.id = RISCV_CONFIG_REG(env, mimpid);
> reg.addr = (uint64_t)>cfg.mimpid;
> ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, );
> if (ret != 0) {
> @@ -788,8 +789,7 @@ static void kvm_riscv_init_misa_ext_mask(RISCVCPU *cpu,
> struct kvm_one_reg reg;
> int ret;
>
> -reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
> - KVM_REG_RISCV_CONFIG_REG(isa));
> +reg.id = RISCV_CONFIG_REG(env, isa);
> reg.addr = (uint64_t)>misa_ext_mask;
> ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, );
>
> @@ -1094,8 +1094,7 @@ static int kvm_vcpu_set_machine_ids(RISCVCPU *cpu,
> CPUState *cs)
> uint64_t id;
> int ret;
>
> -id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
> - KVM_REG_RISCV_CONFIG_REG(mvendorid));
> +id = RISCV_CONFIG_REG(env, mvendorid);
> /*
> * cfg.mvendorid is an uint32 but a target_ulong will
> * be written. Assign it to a target_ulong var to avoid
> @@ -1107,15 +1106,13 @@ static int kvm_vcpu_set_machine_ids(RISCVCPU *cpu,
> CPUState *cs)
> return ret;
> }
>
> -id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
> - KVM_REG_RISCV_CONFIG_REG(marchid));
> +id = RISCV_CONFIG_REG(env, marchid);
> ret = kvm_set_one_reg(cs, id, >cfg.marchid);
> if (ret != 0) {
> return ret;
> }
>
> -id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
> - KVM_REG_RISCV_CONFIG_REG(mimpid));
> +id = RISCV_CONFIG_REG(env, mimpid);
> ret = kvm_set_one_reg(cs, id, >cfg.mimpid);
>
> return ret;
> --
> 2.41.0
>
Reviewed-by: Andrew Jones
Re: [PATCH for-9.0 3/5] target/riscv/kvm: change timer regs size to u64
On Fri, Dec 08, 2023 at 03:38:33PM -0300, Daniel Henrique Barboza wrote:
> KVM_REG_RISCV_TIMER regs are always u64 according to the KVM API, but at
> this moment we'll return u32 regs if we're running a RISCV32 target.
>
> Use the kvm_riscv_reg_id_u64() helper in RISCV_TIMER_REG() to fix it.
>
> Reported-by: Andrew Jones
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 34ed82ebe5..476e5d4b3d 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -88,7 +88,7 @@ static uint64_t kvm_riscv_reg_id_u64(uint64_t type,
> uint64_t idx)
> #define RISCV_CSR_REG(env, name) kvm_riscv_reg_id(env, KVM_REG_RISCV_CSR, \
> KVM_REG_RISCV_CSR_REG(name))
>
> -#define RISCV_TIMER_REG(env, name) kvm_riscv_reg_id(env,
> KVM_REG_RISCV_TIMER, \
> +#define RISCV_TIMER_REG(name) kvm_riscv_reg_id_u64(KVM_REG_RISCV_TIMER, \
> KVM_REG_RISCV_TIMER_REG(name))
>
> #define RISCV_FP_F_REG(idx) kvm_riscv_reg_id_u32(KVM_REG_RISCV_FP_F, idx)
> @@ -111,17 +111,17 @@ static uint64_t kvm_riscv_reg_id_u64(uint64_t type,
> uint64_t idx)
> } \
> } while (0)
>
> -#define KVM_RISCV_GET_TIMER(cs, env, name, reg) \
> +#define KVM_RISCV_GET_TIMER(cs, name, reg) \
> do { \
> -int ret = kvm_get_one_reg(cs, RISCV_TIMER_REG(env, name), ); \
> +int ret = kvm_get_one_reg(cs, RISCV_TIMER_REG(name), ); \
> if (ret) { \
> abort(); \
> } \
> } while (0)
>
> -#define KVM_RISCV_SET_TIMER(cs, env, name, reg) \
> +#define KVM_RISCV_SET_TIMER(cs, name, reg) \
> do { \
> -int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, name), ); \
> +int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(name), ); \
> if (ret) { \
> abort(); \
> } \
> @@ -649,10 +649,10 @@ static void kvm_riscv_get_regs_timer(CPUState *cs)
> return;
> }
>
> -KVM_RISCV_GET_TIMER(cs, env, time, env->kvm_timer_time);
> -KVM_RISCV_GET_TIMER(cs, env, compare, env->kvm_timer_compare);
> -KVM_RISCV_GET_TIMER(cs, env, state, env->kvm_timer_state);
> -KVM_RISCV_GET_TIMER(cs, env, frequency, env->kvm_timer_frequency);
> +KVM_RISCV_GET_TIMER(cs, time, env->kvm_timer_time);
> +KVM_RISCV_GET_TIMER(cs, compare, env->kvm_timer_compare);
> +KVM_RISCV_GET_TIMER(cs, state, env->kvm_timer_state);
> +KVM_RISCV_GET_TIMER(cs, frequency, env->kvm_timer_frequency);
>
> env->kvm_timer_dirty = true;
> }
> @@ -666,8 +666,8 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
> return;
> }
>
> -KVM_RISCV_SET_TIMER(cs, env, time, env->kvm_timer_time);
> -KVM_RISCV_SET_TIMER(cs, env, compare, env->kvm_timer_compare);
> +KVM_RISCV_SET_TIMER(cs, time, env->kvm_timer_time);
> +KVM_RISCV_SET_TIMER(cs, compare, env->kvm_timer_compare);
>
> /*
> * To set register of RISCV_TIMER_REG(state) will occur a error from KVM
> @@ -676,7 +676,7 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
> * TODO If KVM changes, adapt here.
> */
> if (env->kvm_timer_state) {
> -KVM_RISCV_SET_TIMER(cs, env, state, env->kvm_timer_state);
> +KVM_RISCV_SET_TIMER(cs, state, env->kvm_timer_state);
> }
>
> /*
> @@ -685,7 +685,7 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
> * during the migration.
> */
> if (migration_is_running(migrate_get_current()->state)) {
> -KVM_RISCV_GET_TIMER(cs, env, frequency, reg);
> +KVM_RISCV_GET_TIMER(cs, frequency, reg);
> if (reg != env->kvm_timer_frequency) {
> error_report("Dst Hosts timer frequency != Src Hosts");
> }
> --
> 2.41.0
>
Reviewed-by: Andrew Jones
Re: [PATCH for-9.0 2/5] target/riscv/kvm: change KVM_REG_RISCV_FP_D to u64
On Fri, Dec 08, 2023 at 03:38:32PM -0300, Daniel Henrique Barboza wrote:
> KVM_REG_RISCV_FP_D regs are always u64 size. Using kvm_riscv_reg_id() in
> RISCV_FP_D_REG() ends up encoding the wrong size if we're running with
> TARGET_RISCV32.
>
> Create a new helper that returns a KVM ID with u64 size and use it with
> RISCV_FP_D_REG().
>
> Reported-by: Andrew Jones
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 9bfbc4ac98..34ed82ebe5 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -77,6 +77,11 @@ static uint64_t kvm_riscv_reg_id_u32(uint64_t type,
> uint64_t idx)
> return KVM_REG_RISCV | KVM_REG_SIZE_U32 | type | idx;
> }
>
> +static uint64_t kvm_riscv_reg_id_u64(uint64_t type, uint64_t idx)
> +{
> +return KVM_REG_RISCV | KVM_REG_SIZE_U64 | type | idx;
> +}
> +
> #define RISCV_CORE_REG(env, name) kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE,
> \
> KVM_REG_RISCV_CORE_REG(name))
>
> @@ -88,7 +93,7 @@ static uint64_t kvm_riscv_reg_id_u32(uint64_t type,
> uint64_t idx)
>
> #define RISCV_FP_F_REG(idx) kvm_riscv_reg_id_u32(KVM_REG_RISCV_FP_F, idx)
>
> -#define RISCV_FP_D_REG(env, idx) kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_D,
> idx)
> +#define RISCV_FP_D_REG(idx) kvm_riscv_reg_id_u64(KVM_REG_RISCV_FP_D, idx)
>
> #define KVM_RISCV_GET_CSR(cs, env, csr, reg) \
> do { \
> @@ -579,7 +584,7 @@ static int kvm_riscv_get_regs_fp(CPUState *cs)
> if (riscv_has_ext(env, RVD)) {
> uint64_t reg;
> for (i = 0; i < 32; i++) {
> -ret = kvm_get_one_reg(cs, RISCV_FP_D_REG(env, i), );
> +ret = kvm_get_one_reg(cs, RISCV_FP_D_REG(i), );
> if (ret) {
> return ret;
> }
> @@ -613,7 +618,7 @@ static int kvm_riscv_put_regs_fp(CPUState *cs)
> uint64_t reg;
> for (i = 0; i < 32; i++) {
> reg = env->fpr[i];
> -ret = kvm_set_one_reg(cs, RISCV_FP_D_REG(env, i), );
> +ret = kvm_set_one_reg(cs, RISCV_FP_D_REG(i), );
> if (ret) {
> return ret;
> }
> --
> 2.41.0
>
Reviewed-by: Andrew Jones
afaict, we're also missing fcsr here. And watch out for D's fcsr, it's
32-bit, even though the rest of the registers are 64-bit.
Thanks,
drew
Re: [PATCH for-9.0 1/5] target/riscv/kvm: change KVM_REG_RISCV_FP_F to u32
On Fri, Dec 08, 2023 at 03:38:31PM -0300, Daniel Henrique Barboza wrote:
> KVM_REG_RISCV_FP_F regs have u32 size according to the API, but by using
> kvm_riscv_reg_id() in RISCV_FP_F_REG() we're returning u64 sizes when
> running with TARGET_RISCV64. The most likely reason why no one noticed
> this is because we're not implementing kvm_cpu_synchronize_state() in
> RISC-V yet.
>
> Create a new helper that returns a KVM ID with u32 size and use it in
> RISCV_FP_F_REG().
>
> Reported-by: Andrew Jones
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 45b6cf1cfa..9bfbc4ac98 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -72,6 +72,11 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env,
> uint64_t type,
> return id;
> }
>
> +static uint64_t kvm_riscv_reg_id_u32(uint64_t type, uint64_t idx)
> +{
> +return KVM_REG_RISCV | KVM_REG_SIZE_U32 | type | idx;
> +}
> +
> #define RISCV_CORE_REG(env, name) kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE,
> \
> KVM_REG_RISCV_CORE_REG(name))
>
> @@ -81,7 +86,7 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env,
> uint64_t type,
> #define RISCV_TIMER_REG(env, name) kvm_riscv_reg_id(env,
> KVM_REG_RISCV_TIMER, \
> KVM_REG_RISCV_TIMER_REG(name))
>
> -#define RISCV_FP_F_REG(env, idx) kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_F,
> idx)
> +#define RISCV_FP_F_REG(idx) kvm_riscv_reg_id_u32(KVM_REG_RISCV_FP_F, idx)
>
> #define RISCV_FP_D_REG(env, idx) kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_D,
> idx)
>
> @@ -586,7 +591,7 @@ static int kvm_riscv_get_regs_fp(CPUState *cs)
> if (riscv_has_ext(env, RVF)) {
> uint32_t reg;
> for (i = 0; i < 32; i++) {
> -ret = kvm_get_one_reg(cs, RISCV_FP_F_REG(env, i), );
> +ret = kvm_get_one_reg(cs, RISCV_FP_F_REG(i), );
> if (ret) {
> return ret;
> }
> @@ -620,7 +625,7 @@ static int kvm_riscv_put_regs_fp(CPUState *cs)
> uint32_t reg;
> for (i = 0; i < 32; i++) {
> reg = env->fpr[i];
> -ret = kvm_set_one_reg(cs, RISCV_FP_F_REG(env, i), );
> + ret = kvm_set_one_reg(cs, RISCV_FP_F_REG(i), );
> if (ret) {
> return ret;
> }
> --
> 2.41.0
>
This patch looks good, so
Reviewed-by: Andrew Jones
But... I don't see where we save/restore __riscv_f_ext_state.fcsr
Thanks,
drew
Re: [PATCH for-9.0 v2 7/8] target/riscv: add RVA22S64 profile
On Mon, Nov 27, 2023 at 08:37:51AM -0300, Daniel Henrique Barboza wrote: > 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 > --- > target/riscv/cpu.c | 32 > 1 file changed, 32 insertions(+) > Reviewed-by: Andrew Jones
Re: [PATCH for-9.0 v2 6/8] target/riscv: add 'parent' in profile description
On Mon, Nov 27, 2023 at 08:37:50AM -0300, Daniel Henrique Barboza wrote: > 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 > Signed-off-by: Daniel Henrique Barboza > --- > target/riscv/cpu.c | 1 + > target/riscv/cpu.h | 1 + > target/riscv/tcg/tcg-cpu.c | 14 +- > 3 files changed, 15 insertions(+), 1 deletion(-) > Reviewed-by: Andrew Jones
Re: [PATCH for-9.0 v2 2/8] target/riscv: add priv ver restriction to profiles
On Mon, Nov 27, 2023 at 08:37:46AM -0300, Daniel Henrique Barboza wrote: > 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 > --- > target/riscv/cpu.c | 1 + > target/riscv/cpu.h | 2 ++ > target/riscv/tcg/tcg-cpu.c | 31 +++ > 3 files changed, 34 insertions(+) > Reviewed-by: Andrew Jones
