Re: [PATCH v2] target: riscv: Add Svvptc extension support
On Thu, Jul 18, 2024 at 06:07:37PM GMT, 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.
>
> Since qemu already exposes Svvptc behaviour, let's enable it by default
> since it allows to drastically reduce the number of sfence.vma emitted
> by S-mode.
>
> Signed-off-by: Alexandre Ghiti
> ---
> Changes in v2:
> - Rebase on top of master
> - Enable Svvptc by default
>
> 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 c53b0d5b40..19421c8a45 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -192,6 +192,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),
Since Svvptc was just ratified then it isn't spec 1.12. We need another
patch adding later versions first (there is at least one [1]).
[1] https://lists.gnu.org/archive/html/qemu-riscv/2024-05/msg00045.html
This version field is annoying to keep accurate... Maybe we should
make it optional and only specify a version when there are wider
spread changes, such as envcfg bits, which need to be present too.
> 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),
> @@ -1499,6 +1500,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, true),
>
> 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 fb7eebde52..62612ae348 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -78,6 +78,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
>
>
Thanks,
drew
Re: [PATCH 0/8] aspeed: Add boot from eMMC support (AST2600)
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > Hello, > > This series enables boot from eMMC on the rainier-bmc machine, which > is the default behavior and also on the AST2600 EVB using a machine > option to change the default. > > It depends solely on the availability of an eMMC device model which is > currently being discussed upstream. Numerous patches have been merged > already and remaining ones [1] should be in 9.1 development cycle. > Since the changes of this series are small and localized, it would be > an interesting extension of the AST2600 SoC model for QEMU 9.1. > > First 6 patches adjust the machine setup and HW strapping to boot from > eMMC, the last 2 are for the AST2600 EVB and are optional. > > Thanks, > > C. > > [1] https://github.com/legoater/qemu/commits/aspeed-9.1 I built the series using the tree you linked above. It works well! In that context: Tested-by: Andrew Jeffery
Re: [PATCH 8/8] aspeed: Introduce a 'boot-emmc' machine option
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > The default behavior of some Aspeed machines is to boot from the eMMC > device, like the rainier-bmc. Others like ast2600-evb could also boot > from eMMC if the HW strapping boot-from-eMMC bit was set. Add a > property to set or unset this bit. This is useful to test boot images. > > For now, only activate this property on the ast2600-evb and rainier-bmc > machines for which eMMC images are available or can be built. > > Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery
Re: [PATCH 7/8] aspeed: Introduce a 'hw_strap1' machine attribute
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > To change default behavior of a machine and boot from eMMC, future > changes will add a machine option to let the user configure the > boot-from-eMMC HW strapping bit. Add a new machine attribute first. > > Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery
Re: [PATCH 6/8] aspeed: Add boot-from-eMMC HW strapping bit to rainier-bmc machine
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > This value is taken from a running Rainier machine. > > Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery
Re: [PATCH 5/8] aspeed: Set eMMC 'boot-config' property to reflect HW strapping
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote:
> From: Cédric Le Goater
>
> When the boot-from-eMMC HW strapping bit is set, use the 'boot-config'
> property to set the boot config register to boot from the first boot
> area partition of the eMMC device.
>
> Signed-off-by: Cédric Le Goater
> ---
> hw/arm/aspeed.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 756deb91efd1..135f4eb72215 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -327,7 +327,8 @@ void aspeed_board_init_flashes(AspeedSMCState *s, const
> char *flashtype,
> }
> }
>
> -static void sdhci_attach_drive(SDHCIState *sdhci, DriveInfo *dinfo, bool
> emmc)
> +static void sdhci_attach_drive(SDHCIState *sdhci, DriveInfo *dinfo, bool
> emmc,
> + bool boot_emmc)
> {
> DeviceState *card;
>
> @@ -335,6 +336,9 @@ static void sdhci_attach_drive(SDHCIState *sdhci,
> DriveInfo *dinfo, bool emmc)
> return;
> }
> card = qdev_new(emmc ? TYPE_EMMC : TYPE_SD_CARD);
> +if (emmc) {
> +qdev_prop_set_uint8(card, "boot-config", boot_emmc ? 0x48 : 0x0);
0x48 feels a little bit magic. I poked around a bit and there are some
boot-config macros, but not the ones you need and they're all in an
"internal" header anyway. I guess this is fine for now?
Reviewed-by: Andrew Jeffery
Re: [PATCH 4/8] aspeed: Introduce a AspeedSoCClass 'boot_from_emmc' handler
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > Report support on the AST2600 SoC if the boot-from-eMMC HW strapping > bit is set at the board level. AST2700 also has support but it is not > yet ready in QEMU and others SoCs do not have support, so return false > always for these. > > Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery
Re: [PATCH 3/8] aspeed/scu: Add boot-from-eMMC HW strapping bit for AST2600 SoC
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > Bit SCU500[2] of the AST2600 controls the boot device of the SoC. > > Future changes will configure this bit to boot from eMMC disk images > specially built for this purpose. > > Signed-off-by: Joel Stanley > Signed-off-by: Cédric Le Goater > --- > include/hw/misc/aspeed_scu.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/include/hw/misc/aspeed_scu.h b/include/hw/misc/aspeed_scu.h > index 58db28db45aa..c9f98c20ffd9 100644 > --- a/include/hw/misc/aspeed_scu.h > +++ b/include/hw/misc/aspeed_scu.h > @@ -349,6 +349,10 @@ uint32_t aspeed_scu_get_apb_freq(AspeedSCUState *s); > #define SCU_AST2600_H_PLL_BYPASS_EN(0x1 << 24) > #define SCU_AST2600_H_PLL_OFF (0x1 << 23) > > +/* STRAP1 SCU500 */ > +#define AST2600_HW_STRAP_BOOT_SRC_EMMC(0x1 << 2) > +#define AST2600_HW_STRAP_BOOT_SRC_SPI (0x0 << 2) Maybe these should have a `SCU_` prefix for consistency? Anyway: Reviewed-by: Andrew Jeffery
Re: [PATCH 2/8] aspeed: Load eMMC first boot area as a boot rom
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > The first boot area partition (64K) of the eMMC device should contain > an initial boot loader (u-boot SPL). Load it as a ROM only if an eMMC > device is available to boot from but no flash device is. > > Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery
Re: [PATCH 1/8] aspeed: Change type of eMMC device
On Thu, 2024-07-04 at 07:36 +0200, Cédric Le Goater wrote: > From: Cédric Le Goater > > The QEMU device representing the eMMC device of machine is currently > created with type SD_CARD. Change the type to EMMC now that it is > available. > > Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery
Re: [SPAM] [RFC PATCH v42 90/98] hw/sd/sdcard: Add experimental 'x-aspeed-emmc-kludge' property
On Tue, 2024-07-02 at 18:15 +0200, Philippe Mathieu-Daudé wrote: > On 2/7/24 07:06, Andrew Jeffery wrote: > > On Fri, 2024-06-28 at 11:16 +0200, Cédric Le Goater wrote: > > > On 6/28/24 9:02 AM, Philippe Mathieu-Daudé wrote: > > > > When booting U-boot/Linux on Aspeed boards via eMMC, > > > > some commands don't behave as expected from the spec. > > > > > > > > Add the 'x-aspeed-emmc-kludge' property to allow non > > > > standard uses until we figure out the reasons. > > > > > > I am not aware of any singularity in the eMMC logic provided by Aspeed. > > > U-Boot and Linux drivers seem very generic. May be others can tell. > > > > I'm not aware of any command kludges. The main problem I had when I > > wrote the Linux driver for the Aspeed controller was the phase tuning, > > but that doesn't sound related. > > Yeah I don't think anything Aspeed nor U-boot related, we > model CSD/CID registers per the SD spec, not MMC. Various > fields are identical, but few differ, this might be the > problem. > > I rather respect the spec by default, so until we figure > the issue, are you OK to use a 'x-emmc-kludge' property > and set it on the Aspeed boards? Dropping the implication that it's the fault of the Aspeed controller seems reasonable (without further evidence that it's true). Andrew
Re: [SPAM] [RFC PATCH v42 90/98] hw/sd/sdcard: Add experimental 'x-aspeed-emmc-kludge' property
On Fri, 2024-06-28 at 11:16 +0200, Cédric Le Goater wrote: > On 6/28/24 9:02 AM, Philippe Mathieu-Daudé wrote: > > When booting U-boot/Linux on Aspeed boards via eMMC, > > some commands don't behave as expected from the spec. > > > > Add the 'x-aspeed-emmc-kludge' property to allow non > > standard uses until we figure out the reasons. > > I am not aware of any singularity in the eMMC logic provided by Aspeed. > U-Boot and Linux drivers seem very generic. May be others can tell. I'm not aware of any command kludges. The main problem I had when I wrote the Linux driver for the Aspeed controller was the phase tuning, but that doesn't sound related. Andrew
Re: [PATCH v8] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Tue, Jun 25, 2024 at 06:02:54PM GMT, 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), because 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 return an error.
>
> Added SBI related return code's defines.
>
> Signed-off-by: Alexei Filippov
> Fixes: 4eb47125 ("target/riscv: Handle KVM_EXIT_RISCV_SBI exit")
> ---
> Changes since v7:
> - Fix error handling according to Andrew Jones suggestion.
> target/riscv/kvm/kvm-cpu.c | 9 +
> target/riscv/sbi_ecall_interface.h | 12
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 235e2cdaca..1afbabe19f 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -1515,19 +1515,20 @@ 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;
> +} else if (ret == 0) {
> +run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
> } else {
> -run->riscv_sbi.ret[0] = -1;
> +ret = -1;
> }
> -ret = 0;
It should be
diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index 235e2cdaca1a..9946afb4eade 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -1515,10 +1515,12 @@ 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;
-} else {
+ret = 0;
+} else if (ret == 0) {
run->riscv_sbi.ret[0] = -1;
+} else {
+ret = -1;
}
-ret = 0;
break;
case SBI_EXT_DBCN:
kvm_riscv_handle_sbi_dbcn(cs, run);
I misled you on that first 'ret = 0' addition, we need that, but I've
pointed out a few times that we should use '-1' instead of SBI_ERR_FAILURE
and why.
Thanks,
drew
> break;
> case SBI_EXT_DBCN:
> kvm_riscv_handle_sbi_dbcn(cs, run);
> 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 7dfe5f72c6..4df0accd78 100644
> --- a/target/riscv/sbi_ecall_interface.h
> +++ b/target/riscv/sbi_ecall_interface.h
> @@ -86,4 +86,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 v1] memory tier: consolidate the initialization of memory tiers
On Fri, 21 Jun 2024 04:48:30 + "Ho-Ren (Jack) Chuang" wrote: > If we simply move the set_node_memory_tier() from memory_tier_init() to > late_initcall(), it will result in HMAT not registering the > mt_adistance_algorithm callback function, Immediate reaction: then don't do that! > because set_node_memory_tier() > is not performed during the memory tiering initialization phase, > leading to a lack of correct default_dram information. > > Therefore, we introduced a nodemask to pass the information of the > default DRAM nodes. The reason for not choosing to reuse > default_dram_type->nodes is that it is not clean enough. So in the end, > we use a __initdata variable, which is a variable that is released once > initialization is complete, including both CPU and memory nodes for HMAT > to iterate through. > > Besides, since default_dram_type may be checked/used during the > initialization process of HMAT and drivers, it is better to keep the > allocation of default_dram_type in memory_tier_init(). What is this patch actually aiming to do? Is it merely a code cleanup, or are there functional changes? > Signed-off-by: Ho-Ren (Jack) Chuang > --- > Hi all, > > The current memory tier initialization process is distributed across two > different functions, memory_tier_init() and memory_tier_late_init(). This > design is hard to maintain. Thus, this patch is proposed to reduce the > possible code paths by consolidating different initialization patches into > one. Ah, there it is. Please make this the opening paragraph, not an aside buried below the ^---$. I'll await review input before proceeding with this, thanks.
Re: [PATCH v4] hw/gpio/aspeed: Add reg_table_count to AspeedGPIOClass
On Thu, 2024-06-20 at 16:02 +0200, Zheyu Ma wrote: > ASan detected a global-buffer-overflow error in the aspeed_gpio_read() > function. This issue occurred when reading beyond the bounds of the > reg_table. > > To enhance the safety and maintainability of the Aspeed GPIO code, this commit > introduces a reg_table_count member to the AspeedGPIOClass structure. This > change ensures that the size of the GPIO register table is explicitly tracked > and initialized, reducing the risk of errors if new register tables are > introduced in the future. > > Reproducer: > cat << EOF | qemu-system-aarch64 -display none \ > -machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio > readq 0x7e780272 > EOF > > ASAN log indicating the issue: > ==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address > 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88 > READ of size 2 at 0x55a5da29e128 thread T0 > #0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14 > #1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11 > #2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18 > #3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16 > #4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9 > #5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18 > #6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19 > #7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12 > > Signed-off-by: Zheyu Ma Reviewed-by: Andrew Jeffery
Re: [PATCH v3] hw/gpio/aspeed: Add reg_table_size to AspeedGPIOClass
On Wed, 2024-06-19 at 20:36 +0200, Zheyu Ma wrote:
> ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
> function. This issue occurred when reading beyond the bounds of the
> reg_table.
>
> To enhance the safety and maintainability of the Aspeed GPIO code, this commit
> introduces a reg_table_size member to the AspeedGPIOClass structure. This
> change ensures that the size of the GPIO register table is explicitly tracked
> and initialized, reducing the risk of errors if new register tables are
> introduced in the future.
>
> Reproducer:
> cat << EOF | qemu-system-aarch64 -display none \
> -machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio
> readq 0x7e780272
> EOF
>
> ASAN log indicating the issue:
> ==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
> READ of size 2 at 0x55a5da29e128 thread T0
> #0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
> #1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
> #2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
> #3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
> #4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
> #5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
> #6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
> #7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
>
> Signed-off-by: Zheyu Ma
Reviewed-by: Andrew Jeffery
> ---
> Changes in v3:
> - Add the reproducer
>
> Changes in v2:
> - Introduce the reg_table_size to AspeedGPIOClass
> ---
> hw/gpio/aspeed_gpio.c | 17 +
> include/hw/gpio/aspeed_gpio.h | 1 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
> index c1781e2ba3..fd4912edae 100644
> --- a/hw/gpio/aspeed_gpio.c
> +++ b/hw/gpio/aspeed_gpio.c
> @@ -559,6 +559,12 @@ static uint64_t aspeed_gpio_read(void *opaque, hwaddr
> offset, uint32_t size)
> return debounce_value;
> }
>
> +if (idx >= agc->reg_table_size) {
> +qemu_log_mask(LOG_GUEST_ERROR, "%s: idx 0x%" PRIx64 " out of
> bounds\n",
> + __func__, idx);
> +return 0;
> +}
> +
> reg = >reg_table[idx];
> if (reg->set_idx >= agc->nr_gpio_sets) {
> qemu_log_mask(LOG_GUEST_ERROR, "%s: no getter for offset 0x%"
> @@ -785,6 +791,12 @@ static void aspeed_gpio_write(void *opaque, hwaddr
> offset, uint64_t data,
> return;
> }
>
> +if (idx >= agc->reg_table_size) {
> +qemu_log_mask(LOG_GUEST_ERROR, "%s: idx 0x%" PRIx64 " out of
> bounds\n",
> + __func__, idx);
> +return;
> +}
> +
> reg = >reg_table[idx];
> if (reg->set_idx >= agc->nr_gpio_sets) {
> qemu_log_mask(LOG_GUEST_ERROR, "%s: no setter for offset 0x%"
> @@ -1117,6 +1129,7 @@ static void aspeed_gpio_ast2400_class_init(ObjectClass
> *klass, void *data)
> agc->nr_gpio_pins = 216;
> agc->nr_gpio_sets = 7;
> agc->reg_table = aspeed_3_3v_gpios;
> +agc->reg_table_size = GPIO_3_3V_REG_ARRAY_SIZE;
> }
>
> static void aspeed_gpio_2500_class_init(ObjectClass *klass, void *data)
> @@ -1127,6 +1140,7 @@ static void aspeed_gpio_2500_class_init(ObjectClass
> *klass, void *data)
> agc->nr_gpio_pins = 228;
> agc->nr_gpio_sets = 8;
> agc->reg_table = aspeed_3_3v_gpios;
> +agc->reg_table_size = GPIO_3_3V_REG_ARRAY_SIZE;
> }
>
> static void aspeed_gpio_ast2600_3_3v_class_init(ObjectClass *klass, void
> *data)
> @@ -1137,6 +1151,7 @@ static void
> aspeed_gpio_ast2600_3_3v_class_init(ObjectClass *klass, void *data)
> agc->nr_gpio_pins = 208;
> agc->nr_gpio_sets = 7;
> agc->reg_table = aspeed_3_3v_gpios;
> +agc->reg_table_size = GPIO_3_3V_REG_ARRAY_SIZE;
> }
>
> static void aspeed_gpio_ast2600_1_8v_class_init(ObjectClass *klass, void
> *data)
> @@ -1147,6 +1162,7 @@ static void
> aspeed_gpio_ast2600_1_8v_class_init(ObjectClass *klass, void *data)
> agc->nr_gpio_pins = 36;
> agc->nr_gpio_sets = 2;
> agc->reg_table = aspeed_1_8v_gpios;
> +agc->reg_table_size = GPIO_1_8V_REG_ARRAY_SIZE;
> }
>
> static void aspeed_gpio_1030_class_init(ObjectClass *klass, void *data)
> @@ -1157,6 +1173,7 @@ static void aspeed_gpio_1030_class_init(ObjectClass
> *kla
Re: [PATCH] hw/gpio/aspeed: Add bounds checking for register table access
Hello Zheyu Ma,
On Tue, 2024-06-18 at 15:09 +0200, Zheyu Ma wrote:
> Added bounds checking in the aspeed_gpio_read() and aspeed_gpio_write()
> functions to ensure the index idx is within the valid range of the
> reg_table array.
>
> The correct size of reg_table is determined dynamically based on whether
> it is aspeed_3_3v_gpios or aspeed_1_8v_gpios. If idx exceeds the
> size of reg_table, an error is logged, and the function returns.
>
> AddressSanitizer log indicating the issue:
>
> ==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88
> READ of size 2 at 0x55a5da29e128 thread T0
> #0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14
> #1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11
> #2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18
> #3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16
> #4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9
> #5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18
> #6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19
> #7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12
I'm mildly interested in what you were doing to trigger this. Certainly
we could do with a guard in the model to prevent it, but I'm curious
all the same.
>
> Signed-off-by: Zheyu Ma
> ---
> hw/gpio/aspeed_gpio.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
> index c1781e2ba3..1441046f6c 100644
> --- a/hw/gpio/aspeed_gpio.c
> +++ b/hw/gpio/aspeed_gpio.c
> @@ -550,6 +550,7 @@ static uint64_t aspeed_gpio_read(void *opaque, hwaddr
> offset, uint32_t size)
> GPIOSets *set;
> uint32_t value = 0;
> uint64_t debounce_value;
> +uint32_t reg_table_size;
>
> idx = offset >> 2;
> if (idx >= GPIO_DEBOUNCE_TIME_1 && idx <= GPIO_DEBOUNCE_TIME_3) {
> @@ -559,6 +560,18 @@ static uint64_t aspeed_gpio_read(void *opaque, hwaddr
> offset, uint32_t size)
> return debounce_value;
> }
>
> +if (agc->reg_table == aspeed_3_3v_gpios) {
> +reg_table_size = GPIO_3_3V_REG_ARRAY_SIZE;
> +} else {
> +reg_table_size = GPIO_1_8V_REG_ARRAY_SIZE;
> +}
I think I'd prefer we add reg_table_size as a member of AspeedGPIOClass
and initialise it at the same time as we initialise reg_table. I feel
it would help maintain safety in the face of future changes (i.e. if
another reg table were introduced). With that approach the hunk above
can be dropped.
> +
> +if (idx >= reg_table_size) {
This condition would then become:
```
if (idx >= agc->reg_table_size) {
```
Thoughts?
Andrew
答复: [PATCH] hw/net: cadence_gem: fix: type2_compare_x_word_0 error
Yes, Need to check whether the "offset" exceeds the "size" argument of gem_receive() in get_queue_from_screen() function; -邮件原件- 发件人: Peter Maydell 发送时间: 2024年6月6日 20:06 收件人: Edgar E. Iglesias 抄送: andrew Yuan ; luc.mic...@amd.com; alist...@alistair23.me; jasow...@redhat.com; qemu-...@nongnu.org; qemu-devel@nongnu.org 主题: Re: [PATCH] hw/net: cadence_gem: fix: type2_compare_x_word_0 error External Mail: This email originated from OUTSIDE of the organization! Do not click links, open attachments or provide ANY information unless you recognize the sender and know the content is safe. On Thu, 6 Jun 2024 at 12:04, Edgar E. Iglesias wrote: > > On Thu, Jun 6, 2024 at 12:00 PM Andrew.Yuan > wrote: >> >> In the Cadence IP for Gigabit Ethernet MAC Part Number: IP7014 IP >> Rev: R1p12 - Doc Rev: 1.3 User Guide, the specification for the >> type2_compare_x_word_0 register is as follows: >> The byte stored in bits [23:16] is compared against the byte in the >> received frame from the selected offset+0, and the byte stored in bits >> [31:24] is compared against the byte in >> the received frame from the selected offset+1. >> >> However, there is an implementation error in the cadence_gem model >> in qemu： >> the byte stored in bits [31:24] is compared against the byte >> in the received frame from the selected offset+0 >> >> Now, the error code is as follows: >> rx_cmp = rxbuf_ptr[offset] << 8 | rxbuf_ptr[offset]; >> >> and needs to be corrected to： >> rx_cmp = rxbuf_ptr[offset + 1] << 8 | rxbuf_ptr[offset]; >> >> Signed-off-by: Andrew.Yuan > > > > LGTM: > Reviewed-by: Edgar E. Iglesias > > At some point it would be nice to add the missing logic for the > DISABLE_MASK bit that extends the compare range from 16 to 32-bits. I had a look at this device's code, and I'm trying to figure out how we know at this point that there really are two bytes pointed to by rxbuf_ptr. * The get_queue_from_screen() function takes a rxbufsize argument, but it never uses it... * the callsite in gem_receive() will (in the "strip FCS" case) pass its buf argument as rxbuf_ptr, but it will use a rxbufsize argument which has been raised to at least GEM_DMACFG_RBUFSZ_MUL, even if the input size argument is smaller, so even if get_queue_from_screen() honoured its rxbufsize argument it wouldn't help Would somebody who understands the device like to have a look ? This is a separate issue from the incorrect array offset argument this patch fixes, though. thanks -- PMM
答复: [PATCH] hw/net: cadence_gem: fix: type2_compare_x_word_0 error
OK，I will send another patch for the missing logic for the DISABLE_MASK bit; 发件人: Edgar E. Iglesias 发送时间: 2024年6月6日 19:04 收件人: andrew Yuan 抄送: luc.mic...@amd.com; alist...@alistair23.me; peter.mayd...@linaro.org; jasow...@redhat.com; qemu-...@nongnu.org; qemu-devel@nongnu.org 主题: Re: [PATCH] hw/net: cadence_gem: fix: type2_compare_x_word_0 error External Mail: This email originated from OUTSIDE of the organization! Do not click links, open attachments or provide ANY information unless you recognize the sender and know the content is safe. On Thu, Jun 6, 2024 at 12:00 PM Andrew.Yuan mailto:andrew.y...@jaguarmicro.com>> wrote: In the Cadence IP for Gigabit Ethernet MAC Part Number: IP7014 IP Rev: R1p12 - Doc Rev: 1.3 User Guide, the specification for the type2_compare_x_word_0 register is as follows: The byte stored in bits [23:16] is compared against the byte in the received frame from the selected offset+0, and the byte stored in bits [31:24] is compared against the byte in the received frame from the selected offset+1. However, there is an implementation error in the cadence_gem model in qemu： the byte stored in bits [31:24] is compared against the byte in the received frame from the selected offset+0 Now, the error code is as follows: rx_cmp = rxbuf_ptr[offset] << 8 | rxbuf_ptr[offset]; and needs to be corrected to： rx_cmp = rxbuf_ptr[offset + 1] << 8 | rxbuf_ptr[offset]; Signed-off-by: Andrew.Yuan mailto:andrew.y...@jaguarmicro.com>> LGTM: Reviewed-by: Edgar E. Iglesias mailto:edgar.igles...@amd.com>> At some point it would be nice to add the missing logic for the DISABLE_MASK bit that extends the compare range from 16 to 32-bits. Cheers, Edgar --- hw/net/cadence_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c index ec7bf562e5..9c73ded0d3 100644 --- a/hw/net/cadence_gem.c +++ b/hw/net/cadence_gem.c @@ -946,7 +946,7 @@ static int get_queue_from_screen(CadenceGEMState *s, uint8_t *rxbuf_ptr, break; } -rx_cmp = rxbuf_ptr[offset] << 8 | rxbuf_ptr[offset]; +rx_cmp = rxbuf_ptr[offset + 1] << 8 | rxbuf_ptr[offset]; mask = FIELD_EX32(cr0, TYPE2_COMPARE_0_WORD_0, MASK_VALUE); compare = FIELD_EX32(cr0, TYPE2_COMPARE_0_WORD_0, COMPARE_VALUE); -- 2.37.0.windows.1
Re: [PATCH v3 00/13] riscv: QEMU RISC-V IOMMU Support
used >> in riscv_iommu_ctx_fetch() >> - added a new riscv_iommu_update_ipsr() helper to handle IPSR updates >> in riscv_iommu_mmio_write() >> - riscv_iommmu_msi_write() now reports a fault in all error paths >> - check for fctl.WSI before issuing a MSI interrupt in riscv_iommu_notify() >> - change riscv-iommu region name to 'riscv-iommu' >> - change address_space_init() name for PCI devices to 'name' instead of >> using TYPE_RISCV_IOMMU_PCI >> - changed riscv_iommu_mmio_ops min_access_size to 4 >> - do not check for min and max sizes on riscv_iommu_mmio_write() >> - changed riscv_iommu_trap_ops min_access_size to 4 >> - removed IOMMU qemu_thread thread: >> - riscv_iommu_mmio_write() will now execute a riscv_iommu_process_fn by >> holding >> 'core_lock' >> - init FSCR as zero explicitly >> - check for bus->iommu_opaque == NULL before calling pci_setup_iommu() >> >> - patch 4 (new): >> - add Red-Hat PCI RISC-V IOMMU ID >> >> - patch 5 (former 4): >> - create vendor-id and device-id properties >> - set Red-hat PCI RISC-V IOMMU ID as default ID >> >> - patch 8: >> - use IOMMU_NONE instead of '0' in relevant 'iot->perm = 0' instances >> >> - patch 9: >> - add s-stage and g-stage steps in riscv_iommu_validate_device_ctx() >> - removed 'gpa' boolean from riscv_iommu_spa_fetch() >> - 'en_s' is no longer used for early MSI address match >> >> - patch 10: >> - add ATS steps in riscv_iommu_validate_device_ctx() >> - check for 's->enable_ats' before adding RISCV_IOMMU_DC_TC_EN_ATS in >> device context >> - check for 's->enable_ats' before processing ATS commands in >> riscv_iommu_process_cq_tail() >> - remove ambiguous trace_riscv_iommu_ats() from riscv_iommu_translate() >> >> - patch 11: >> - removed unused bits >> - added RISCV_IOMMU_TR_REQ_CTL_NW and RISCV_IOMMU_TR_RESPONSE_S >> bits >> - set IOMMUTLBEntry 'perm' using RISCV_IOMMU_TR_REQ_CTL_NW in >> riscv_iommu_process_dbg() >> - clear RISCV_IOMMU_TR_RESPONSE_S in riscv_iommu_process_dbg(). Added a >> comment talking about the (lack of) superpage support >> >> [1] >> https://lore.kernel.org/qemu-riscv/20240307160319.675044-1-dbarb...@ventanamicro.com/ >> [2] https://github.com/vlsunil/qemu/commits/acpi_rimt_poc_v1/ >> >> Andrew Jones (1): >> hw/riscv/riscv-iommu: Add another irq for mrif notifications >> >> Daniel Henrique Barboza (3): >> pci-ids.rst: add Red Hat pci-id for RISC-V IOMMU device >> test/qtest: add riscv-iommu-pci tests >> qtest/riscv-iommu-test: add init queues test >> >> Tomasz Jeznach (9): >> exec/memtxattr: add process identifier to the transaction attributes >> hw/riscv: add riscv-iommu-bits.h >> hw/riscv: add RISC-V IOMMU base emulation >> hw/riscv: add riscv-iommu-pci reference device >> hw/riscv/virt.c: support for RISC-V IOMMU PCIDevice hotplug >> hw/riscv/riscv-iommu: add Address Translation Cache (IOATC) >> hw/riscv/riscv-iommu: add s-stage and g-stage support >> hw/riscv/riscv-iommu: add ATS support >> hw/riscv/riscv-iommu: add DBG support >> >> docs/specs/pci-ids.rst |2 + >> hw/riscv/Kconfig |4 + >> hw/riscv/meson.build |1 + >> hw/riscv/riscv-iommu-bits.h | 416 ++ >> hw/riscv/riscv-iommu-pci.c | 177 +++ >> hw/riscv/riscv-iommu.c | 2283 ++ >> hw/riscv/riscv-iommu.h | 146 ++ >> hw/riscv/trace-events| 15 + >> hw/riscv/trace.h |1 + >> hw/riscv/virt.c | 33 +- >> include/exec/memattrs.h |5 + >> include/hw/pci/pci.h |1 + >> include/hw/riscv/iommu.h | 36 + >> meson.build |1 + >> tests/qtest/libqos/meson.build |4 + >> tests/qtest/libqos/riscv-iommu.c | 76 + >> tests/qtest/libqos/riscv-iommu.h | 100 ++ >> tests/qtest/meson.build |1 + >> tests/qtest/riscv-iommu-test.c | 234 +++ >> 19 files changed, 3535 insertions(+), 1 deletion(-) >> create mode 100644 hw/riscv/riscv-iommu-bits.h >> create mode 100644 hw/riscv/riscv-iommu-pci.c >> create mode 100644 hw/riscv/riscv-iommu.c >> create mode 100644 hw/riscv/riscv-iommu.h >> create mode 100644 hw/riscv/trace-events >> create mode 100644 hw/riscv/trace.h >> create mode 100644 include/hw/riscv/iommu.h >> create mode 100644 tests/qtest/libqos/riscv-iommu.c >> create mode 100644 tests/qtest/libqos/riscv-iommu.h >> create mode 100644 tests/qtest/riscv-iommu-test.c >> >> -- >> 2.44.0 >> >>
Re: [PATCH] MAINTAINERS: Add reviewers for ASPEED BMCs
On Wed, 2024-06-05 at 14:03 +0800, Jamin Lin via wrote: > Add ASPEED members "Steven Lee", "Troy Lee" and "Jamin Lin" > to be reviewers of ASPEED BMCs. > > Signed-off-by: Jamin Lin > Signed-off-by: Troy Lee > Signed-off-by: Steven Lee I'm not very active wrt qemu these days but am still interested in Aspeed-related patches. For what it's worth: Reviewed-by: Andrew Jeffery > --- > MAINTAINERS | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 951556224a..0f63bcdc7d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1158,6 +1158,9 @@ F: docs/system/arm/emcraft-sf2.rst > ASPEED BMCs > M: Cédric Le Goater > M: Peter Maydell > +R: Steven Lee > +R: Troy Lee > +R: Jamin Lin > R: Andrew Jeffery > R: Joel Stanley > L: qemu-...@nongnu.org
Re: [PATCH] hw/riscv/virt.c: add address-cells in create_fdt_one_aplic()
On Thu, May 30, 2024 at 01:05:41PM GMT, Andrew Jones wrote:
> On Thu, May 30, 2024 at 05:49:49AM GMT, Daniel Henrique Barboza wrote:
> > We need #address-cells properties in all interrupt controllers that are
> > referred by an interrupt-map [1]. For the RISC-V machine, both PLIC and
> > APLIC controllers must have this property.
> >
> > PLIC already sets it in create_fdt_socket_plic(). Set the property for
> > APLIC in create_fdt_one_aplic().
> >
> > [1]
> > https://lore.kernel.org/linux-arm-kernel/cal_jsqje15d-xxxmelsmud+jqhzzxgzdxvikchn6kfwqk6n...@mail.gmail.com/
>
> There are other issues[2] with the DT nodes that we should address at the
> same time.
>
> [2] https://lore.kernel.org/all/20240529-rust-tile-a05517a6260f@spud/
I meant to CC Conor. Doing that now.
>
> Thanks,
> drew
>
> >
> > Suggested-by: Anup Patel
> > Fixes: e6faee65855b ("hw/riscv: virt: Add optional AIA APLIC support to
> > virt machine")
> > Signed-off-by: Daniel Henrique Barboza
> > ---
> > hw/riscv/virt.c | 2 ++
> > include/hw/riscv/virt.h | 1 +
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index 4fdb660525..1a7e1e73c5 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -609,6 +609,8 @@ static void create_fdt_one_aplic(RISCVVirtState *s, int
> > socket,
> > aplic_name = g_strdup_printf("/soc/aplic@%lx", aplic_addr);
> > qemu_fdt_add_subnode(ms->fdt, aplic_name);
> > qemu_fdt_setprop_string(ms->fdt, aplic_name, "compatible",
> > "riscv,aplic");
> > +qemu_fdt_setprop_cell(ms->fdt, aplic_name, "#address-cells",
> > + FDT_APLIC_ADDR_CELLS);
> > qemu_fdt_setprop_cell(ms->fdt, aplic_name,
> >"#interrupt-cells", FDT_APLIC_INT_CELLS);
> > qemu_fdt_setprop(ms->fdt, aplic_name, "interrupt-controller", NULL, 0);
> > diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
> > index 3db839160f..c0dc41ff9a 100644
> > --- a/include/hw/riscv/virt.h
> > +++ b/include/hw/riscv/virt.h
> > @@ -118,6 +118,7 @@ enum {
> > #define FDT_PLIC_ADDR_CELLS 0
> > #define FDT_PLIC_INT_CELLS1
> > #define FDT_APLIC_INT_CELLS 2
> > +#define FDT_APLIC_ADDR_CELLS 0
> > #define FDT_IMSIC_INT_CELLS 0
> > #define FDT_MAX_INT_CELLS 2
> > #define FDT_MAX_INT_MAP_WIDTH (FDT_PCI_ADDR_CELLS + FDT_PCI_INT_CELLS + \
> > --
> > 2.45.1
> >
> >
Re: [PATCH] hw/riscv/virt.c: add address-cells in create_fdt_one_aplic()
On Thu, May 30, 2024 at 05:49:49AM GMT, Daniel Henrique Barboza wrote:
> We need #address-cells properties in all interrupt controllers that are
> referred by an interrupt-map [1]. For the RISC-V machine, both PLIC and
> APLIC controllers must have this property.
>
> PLIC already sets it in create_fdt_socket_plic(). Set the property for
> APLIC in create_fdt_one_aplic().
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/cal_jsqje15d-xxxmelsmud+jqhzzxgzdxvikchn6kfwqk6n...@mail.gmail.com/
There are other issues[2] with the DT nodes that we should address at the
same time.
[2] https://lore.kernel.org/all/20240529-rust-tile-a05517a6260f@spud/
Thanks,
drew
>
> Suggested-by: Anup Patel
> Fixes: e6faee65855b ("hw/riscv: virt: Add optional AIA APLIC support to virt
> machine")
> Signed-off-by: Daniel Henrique Barboza
> ---
> hw/riscv/virt.c | 2 ++
> include/hw/riscv/virt.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 4fdb660525..1a7e1e73c5 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -609,6 +609,8 @@ static void create_fdt_one_aplic(RISCVVirtState *s, int
> socket,
> aplic_name = g_strdup_printf("/soc/aplic@%lx", aplic_addr);
> qemu_fdt_add_subnode(ms->fdt, aplic_name);
> qemu_fdt_setprop_string(ms->fdt, aplic_name, "compatible",
> "riscv,aplic");
> +qemu_fdt_setprop_cell(ms->fdt, aplic_name, "#address-cells",
> + FDT_APLIC_ADDR_CELLS);
> qemu_fdt_setprop_cell(ms->fdt, aplic_name,
>"#interrupt-cells", FDT_APLIC_INT_CELLS);
> qemu_fdt_setprop(ms->fdt, aplic_name, "interrupt-controller", NULL, 0);
> diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
> index 3db839160f..c0dc41ff9a 100644
> --- a/include/hw/riscv/virt.h
> +++ b/include/hw/riscv/virt.h
> @@ -118,6 +118,7 @@ enum {
> #define FDT_PLIC_ADDR_CELLS 0
> #define FDT_PLIC_INT_CELLS1
> #define FDT_APLIC_INT_CELLS 2
> +#define FDT_APLIC_ADDR_CELLS 0
> #define FDT_IMSIC_INT_CELLS 0
> #define FDT_MAX_INT_CELLS 2
> #define FDT_MAX_INT_MAP_WIDTH (FDT_PCI_ADDR_CELLS + FDT_PCI_INT_CELLS + \
> --
> 2.45.1
>
>
Re: [RESEND PATCH v2 0/5] target/riscv: Support RISC-V privilege 1.13 spec
On Thu, May 30, 2024 at 11:30:28AM GMT, Fea Wang wrote: > Hi Daniel, > thank you for your help. > > I found that only the cover is without many maintainers. I used to send > patches by git send-email --dry-run --to 'qemu-devel@nongnu.org, > qemu-ri...@nongnu.org' --cc-cmd='scripts/get_maintainer.pl -i' patches/*. > Do you have a better script for me? > Thank you. Some maintainers frown on that because they prefer the whole series, even if only a few patches touch code they maintain. And, the cover letter is quite important to get the context. Also, depending on mail client and filter configurations, CC's that are per patch can mess up the threading, making a mess of the mailbox. I tend to use scripts/get_maintainer.pl to pull together a set of people/lists to CC as an independent step, dump the contents into a file and then do 'git send-email $(cat my-series.to-list) patches/my-series' git-publish can help with that too by capturing the "to list" and maintaining it for you. Thanks, drew > > Sincerely, > Fea > > On Mon, May 27, 2024 at 5:21 PM Daniel Henrique Barboza < > dbarb...@ventanamicro.com> wrote: > > > Fea, > > > > Please try to also add all RISC-V QEMU maintainers and reviewers when > > sending > > patches. It will get your patches reviewed and queued faster. Otherwise the > > maintainers can miss you your series due to high ML traffic. > > > > You can fetch who you want to CC using the get_maintainer.pl script with > > the > > patch files or any source file in particular, e.g.: > > > > $ ./scripts/get_maintainer.pl -f target/riscv/cpu.c > > Palmer Dabbelt (supporter:RISC-V TCG CPUs) > > Alistair Francis (supporter:RISC-V TCG CPUs) > > Bin Meng (supporter:RISC-V TCG CPUs) > > Weiwei Li (reviewer:RISC-V TCG CPUs) > > Daniel Henrique Barboza (reviewer:RISC-V TCG > > CPUs) > > Liu Zhiwei (reviewer:RISC-V TCG CPUs) > > qemu-ri...@nongnu.org (open list:RISC-V TCG CPUs) > > qemu-devel@nongnu.org (open list:All patches CC here) > > > > > > I added the extra folk in the CC for this reply so don't worry about it. > > > > > > Alistair, please queue this series. It's already fully acked and I would > > like to add > > some bits on top of the priv_spec 1.13 support. > > > > > > Thanks, > > > > > > Daniel > > > > On 5/15/24 05:05, Fea.Wang wrote: > > > Based on the change log for the RISC-V privilege 1.13 spec, add the > > > support for ss1p13. > > > > > > Ref: > > https://github.com/riscv/riscv-isa-manual/blob/a7d93c9/src/priv-preface.adoc?plain=1#L40-L72 > > > > > > Lists what to do without clarification or document format. > > > * Redefined misa.MXL to be read-only, making MXLEN a constant.(Skip, > > implementation ignored) > > > * Added the constraint that SXLEN≥UXLEN.(Skip, implementation ignored) > > > * Defined the misa.V field to reflect that the V extension has been > > implemented.(Skip, existed) > > > * Defined the RV32-only medelegh and hedelegh CSRs.(Done in these > > patches) > > > * Defined the misaligned atomicity granule PMA, superseding the proposed > > Zam extension..(Skip, implementation ignored) > > > * Allocated interrupt 13 for Sscofpmf LCOFI interrupt.(Skip, existed) > > > * Defined hardware error and software check exception codes.(Done in > > these patches) > > > * Specified synchronization requirements when changing the PBMTE fields > > in menvcfg and henvcfg.(Skip, implementation ignored) > > > * Incorporated Svade and Svadu extension specifications.(Skip, existed) > > > > > > > > > Fea.Wang (4): > > >target/riscv: Support the version for ss1p13 > > >target/riscv: Add 'P1P13' bit in SMSTATEEN0 > > >target/riscv: Add MEDELEGH, HEDELEGH csrs for RV32 > > >target/riscv: Reserve exception codes for sw-check and hw-err > > > > > > Jim Shu (1): > > >target/riscv: Reuse the conversion function of priv_spec > > > > > > target/riscv/cpu.c | 8 ++-- > > > target/riscv/cpu.h | 5 - > > > target/riscv/cpu_bits.h| 5 + > > > target/riscv/cpu_cfg.h | 1 + > > > target/riscv/csr.c | 39 ++ > > > target/riscv/tcg/tcg-cpu.c | 17 - > > > 6 files changed, 63 insertions(+), 12 deletions(-) > > > > >
Re: [PATCH RESEND v2 1/3] target/riscv/kvm: add software breakpoints support
On Tue, May 28, 2024 at 08:07:57AM GMT, Chao Du wrote:
> This patch implements insert/remove software breakpoint process.
>
> For RISC-V, GDB treats single-step similarly to breakpoint: add a
> breakpoint at the next step address, then continue. So this also
> works for single-step debugging.
>
> Implement kvm_arch_update_guest_debug(): Set the control flag
> when there are active breakpoints. This will help KVM to know
> the status in the userspace.
>
> Add some stubs which are necessary for building, and will be
> implemented later.
>
> Signed-off-by: Chao Du
> ---
> target/riscv/kvm/kvm-cpu.c | 69 ++
> 1 file changed, 69 insertions(+)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 235e2cdaca..c50f058aff 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -1969,3 +1969,72 @@ static const TypeInfo riscv_kvm_cpu_type_infos[] = {
> };
>
> DEFINE_TYPES(riscv_kvm_cpu_type_infos)
> +
> +static const uint32_t ebreak_insn = 0x00100073;
> +static const uint16_t c_ebreak_insn = 0x9002;
> +
> +int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
> +{
> +if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)>saved_insn, 2, 0)) {
> +return -EINVAL;
> +}
> +
> +if ((bp->saved_insn & 0x3) == 0x3) {
> +if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)>saved_insn, 4, 0)
> +|| cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)_insn, 4,
> 1)) {
> +return -EINVAL;
> +}
> +} else {
> +if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)_ebreak_insn, 2,
> 1)) {
> +return -EINVAL;
> +}
> +}
> +
> +return 0;
> +}
> +
> +int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
> +{
> +uint32_t ebreak;
> +uint16_t c_ebreak;
> +
> +if ((bp->saved_insn & 0x3) == 0x3) {
> +if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *), 4, 0) ||
> +ebreak != ebreak_insn ||
> +cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)>saved_insn, 4,
> 1)) {
> +return -EINVAL;
> +}
> +} else {
> +if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)_ebreak, 2, 0) ||
> +c_ebreak != c_ebreak_insn ||
> +cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)>saved_insn, 2,
> 1)) {
> +return -EINVAL;
> +}
> +}
> +
> +return 0;
> +}
> +
> +int kvm_arch_insert_hw_breakpoint(vaddr addr, vaddr len, int type)
> +{
> +/* TODO; To be implemented later. */
> +return -EINVAL;
> +}
> +
> +int kvm_arch_remove_hw_breakpoint(vaddr addr, vaddr len, int type)
> +{
> +/* TODO; To be implemented later. */
> +return -EINVAL;
> +}
> +
> +void kvm_arch_remove_all_hw_breakpoints(void)
> +{
> +/* TODO; To be implemented later. */
> +}
> +
> +void kvm_arch_update_guest_debug(CPUState *cs, struct kvm_guest_debug *dbg)
> +{
> +if (kvm_sw_breakpoints_active(cs)) {
> +dbg->control |= KVM_GUESTDBG_ENABLE;
> +}
> +}
> --
> 2.17.1
>
Reviewed-by: Andrew Jones
Re: [PATCH v1 4/4] target/riscv/kvm: define TARGET_KVM_HAVE_GUEST_DEBUG
On Mon, May 27, 2024 at 02:19:16AM GMT, Chao Du wrote: > To enable the KVM GUEST DEBUG for RISC-V at QEMU side. > > Signed-off-by: Chao Du > --- > configs/targets/riscv64-softmmu.mak | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/targets/riscv64-softmmu.mak > b/configs/targets/riscv64-softmmu.mak > index 7c0e7eeb42..f938cc1ee6 100644 > --- a/configs/targets/riscv64-softmmu.mak > +++ b/configs/targets/riscv64-softmmu.mak > @@ -1,5 +1,6 @@ > TARGET_ARCH=riscv64 > TARGET_BASE_ARCH=riscv > TARGET_SUPPORTS_MTTCG=y > +TARGET_KVM_HAVE_GUEST_DEBUG=y > TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml > gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-virtual.xml > TARGET_NEED_FDT=y > -- > 2.17.1 > > Reviewed-by: Andrew Jones
Re: [PATCH v1 3/4] target/riscv/kvm: handle the exit with debug reason
On Mon, May 27, 2024 at 02:19:15AM GMT, Chao Du wrote:
> If the breakpoint belongs to the userspace then set the ret value.
>
> Signed-off-by: Chao Du
> ---
> target/riscv/kvm/kvm-cpu.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 0bc3348b91..0c45e520b2 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -1555,6 +1555,21 @@ static int kvm_riscv_handle_csr(CPUState *cs, struct
> kvm_run *run)
> return ret;
> }
>
> +static bool kvm_riscv_handle_debug(CPUState *cs)
> +{
> +RISCVCPU *cpu = RISCV_CPU(cs);
> +CPURISCVState *env = >env;
> +
> +/* Ensure PC is synchronised */
> +kvm_cpu_synchronize_state(cs);
> +
> +if (kvm_find_sw_breakpoint(cs, env->pc)) {
> +return true;
> +}
> +
> +return false;
> +}
> +
> int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
> {
> int ret = 0;
> @@ -1565,6 +1580,11 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run
> *run)
> case KVM_EXIT_RISCV_CSR:
> ret = kvm_riscv_handle_csr(cs, run);
> break;
> +case KVM_EXIT_DEBUG:
> +if (kvm_riscv_handle_debug(cs)) {
> +ret = EXCP_DEBUG;
> +}
> +break;
> default:
> qemu_log_mask(LOG_UNIMP, "%s: un-handled exit reason %d\n",
>__func__, run->exit_reason);
> --
> 2.17.1
>
>
Reviewed-by: Andrew Jones
Re: [PATCH v1 2/4] target/riscv/kvm: implement kvm_arch_update_guest_debug()
On Mon, May 27, 2024 at 02:19:14AM GMT, Chao Du wrote:
> Set the control flag when there are active breakpoints. This will
> help KVM to know the status in the userspace.
>
> Signed-off-by: Chao Du
> ---
> target/riscv/kvm/kvm-cpu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index cba55c552d..0bc3348b91 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -2039,5 +2039,7 @@ void kvm_arch_remove_all_hw_breakpoints(void)
>
> void kvm_arch_update_guest_debug(CPUState *cs, struct kvm_guest_debug *dbg)
> {
> -/* TODO; To be implemented later. */
> +if (kvm_sw_breakpoints_active(cs)) {
> +dbg->control |= KVM_GUESTDBG_ENABLE;
> +}
> }
> --
> 2.17.1
>
>
Should squash this into the previous patch.
Thanks,
drew
Re: [PATCH v1 1/4] target/riscv/kvm: add software breakpoints support
On Mon, May 27, 2024 at 02:19:13AM GMT, Chao Du wrote:
> This patch implements insert/remove software breakpoint process:
>
> Add an input parameter for kvm_arch_insert_sw_breakpoint() and
> kvm_arch_remove_sw_breakpoint() to pass the length information,
> which helps us to know whether it is a RVC instruction.
> For some remove cases, we do not have the length info, so we need
> to judge by ourselves.
>
> For RISC-V, GDB treats single-step similarly to breakpoint: add a
> breakpoint at the next step address, then continue. So this also
> works for single-step debugging.
>
> Add some stubs which are necessary for building, and will be
> implemented later.
>
> Signed-off-by: Chao Du
> ---
> accel/kvm/kvm-all.c| 8 ++--
> include/sysemu/kvm.h | 6 ++-
> target/arm/kvm.c | 6 ++-
> target/i386/kvm/kvm.c | 6 ++-
> target/mips/kvm.c | 6 ++-
> target/ppc/kvm.c | 6 ++-
> target/riscv/kvm/kvm-cpu.c | 79 ++
> target/s390x/kvm/kvm.c | 6 ++-
> 8 files changed, 107 insertions(+), 16 deletions(-)
>
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index c0be9f5eed..d27e77dbb2 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -3357,7 +3357,7 @@ int kvm_insert_breakpoint(CPUState *cpu, int type,
> vaddr addr, vaddr len)
> bp = g_new(struct kvm_sw_breakpoint, 1);
> bp->pc = addr;
> bp->use_count = 1;
> -err = kvm_arch_insert_sw_breakpoint(cpu, bp);
> +err = kvm_arch_insert_sw_breakpoint(cpu, bp, len);
> if (err) {
> g_free(bp);
> return err;
> @@ -3396,7 +3396,7 @@ int kvm_remove_breakpoint(CPUState *cpu, int type,
> vaddr addr, vaddr len)
> return 0;
> }
>
> -err = kvm_arch_remove_sw_breakpoint(cpu, bp);
> +err = kvm_arch_remove_sw_breakpoint(cpu, bp, len);
> if (err) {
> return err;
> }
> @@ -3426,10 +3426,10 @@ void kvm_remove_all_breakpoints(CPUState *cpu)
> CPUState *tmpcpu;
>
> QTAILQ_FOREACH_SAFE(bp, >kvm_sw_breakpoints, entry, next) {
> -if (kvm_arch_remove_sw_breakpoint(cpu, bp) != 0) {
> +if (kvm_arch_remove_sw_breakpoint(cpu, bp, 0) != 0) {
> /* Try harder to find a CPU that currently sees the breakpoint.
> */
> CPU_FOREACH(tmpcpu) {
> -if (kvm_arch_remove_sw_breakpoint(tmpcpu, bp) == 0) {
> +if (kvm_arch_remove_sw_breakpoint(tmpcpu, bp, 0) == 0) {
It's not nice to need to add 'len' to all arch insert/remove sw breakpoint
implementations, and the fact we have to pass zero sometimes implies it's
not the right approach.
> break;
> }
> }
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index c31d9c7356..340e094ffb 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -391,9 +391,11 @@ struct kvm_sw_breakpoint
> *kvm_find_sw_breakpoint(CPUState *cpu,
> int kvm_sw_breakpoints_active(CPUState *cpu);
>
> int kvm_arch_insert_sw_breakpoint(CPUState *cpu,
> - struct kvm_sw_breakpoint *bp);
> + struct kvm_sw_breakpoint *bp,
> + vaddr len);
> int kvm_arch_remove_sw_breakpoint(CPUState *cpu,
> - struct kvm_sw_breakpoint *bp);
> + struct kvm_sw_breakpoint *bp,
> + vaddr len);
> int kvm_arch_insert_hw_breakpoint(vaddr addr, vaddr len, int type);
> int kvm_arch_remove_hw_breakpoint(vaddr addr, vaddr len, int type);
> void kvm_arch_remove_all_hw_breakpoints(void);
> diff --git a/target/arm/kvm.c b/target/arm/kvm.c
> index 7cf5cf31de..84593db544 100644
> --- a/target/arm/kvm.c
> +++ b/target/arm/kvm.c
> @@ -2402,7 +2402,8 @@ void kvm_arch_on_sigbus_vcpu(CPUState *c, int code,
> void *addr)
> /* C6.6.29 BRK instruction */
> static const uint32_t brk_insn = 0xd420;
>
> -int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
> +int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp,
> + vaddr len)
> {
> if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)>saved_insn, 4, 0) ||
> cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)_insn, 4, 1)) {
> @@ -2411,7 +2412,8 @@ int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct
> kvm_sw_breakpoint *bp)
> return 0;
> }
>
> -int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
> +int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp,
> + vaddr len)
> {
> static uint32_t brk;
>
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index c5943605ee..6449f796d0 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -4992,7 +4992,8 @@
Re: [PATCH v7] target/riscv/kvm/kvm-cpu.c: kvm_riscv_handle_sbi() fail with vendor-specific SBI
On Mon, May 27, 2024 at 04:48:11PM GMT, 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), because 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 return an error.
>
> Added SBI related return code's defines.
>
> Signed-off-by: Alexei Filippov
> Fixes: 4eb47125 ("target/riscv: Handle KVM_EXIT_RISCV_SBI exit")
> ---
> Changes since v6:
> - Add appropriate commit message.
> - Fix error handling according to Andrew Jones suggestion.
> target/riscv/kvm/kvm-cpu.c | 11 +++
> target/riscv/sbi_ecall_interface.h | 12
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index f9dbc18a76..a84bcda9d9 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -1173,16 +1173,19 @@ 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;
ret is already zero here, so this assignment isn't necessary.
> } else {
> -run->riscv_sbi.ret[0] = -1;
> +if (ret == 0) {
> +run->riscv_sbi.ret[0] = SBI_ERR_FAILURE;
> +}
> +ret = -1;
> }
> -ret = 0;
> break;
v6 was closer to being correct than this. It should be
@@ -1515,21 +1516,24 @@ 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;
-} else {
+} else if (ret == 0) {
run->riscv_sbi.ret[0] = -1;
+} else {
+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
>
Thanks,
drew
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
Re: [PATCH v2 1/1] ebpf: Added traces back. Changed source set for eBPF to 'system'.
Hello, everyone.
Was added missed "trace.h"
Best regards.
On Mon, Apr 22, 2024 at 5:17 PM Andrew Melnychenko wrote:
>
> There was an issue with Qemu build with "--disable-system".
> The traces could be generated and the build fails.
> The traces were 'cut out' for previous patches, and overall,
> the 'system' source set should be used like in pre-'eBPF blob' patches.
>
> Signed-off-by: Andrew Melnychenko
> ---
> ebpf/ebpf_rss.c | 7 +++
> ebpf/meson.build | 2 +-
> ebpf/trace.h | 1 +
> 3 files changed, 9 insertions(+), 1 deletion(-)
> create mode 100644 ebpf/trace.h
>
> diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
> index d102f3dd092..87f0714910e 100644
> --- a/ebpf/ebpf_rss.c
> +++ b/ebpf/ebpf_rss.c
> @@ -25,6 +25,8 @@
> #include "ebpf/rss.bpf.skeleton.h"
> #include "ebpf/ebpf.h"
>
> +#include "trace.h"
> +
> void ebpf_rss_init(struct EBPFRSSContext *ctx)
> {
> if (ctx != NULL) {
> @@ -55,18 +57,21 @@ static bool ebpf_rss_mmap(struct EBPFRSSContext *ctx)
> PROT_READ | PROT_WRITE, MAP_SHARED,
> ctx->map_configuration, 0);
> if (ctx->mmap_configuration == MAP_FAILED) {
> +trace_ebpf_error("eBPF RSS", "can not mmap eBPF configuration
> array");
> return false;
> }
> ctx->mmap_toeplitz_key = mmap(NULL, qemu_real_host_page_size(),
> PROT_READ | PROT_WRITE, MAP_SHARED,
> ctx->map_toeplitz_key, 0);
> if (ctx->mmap_toeplitz_key == MAP_FAILED) {
> +trace_ebpf_error("eBPF RSS", "can not mmap eBPF toeplitz key");
> goto toeplitz_fail;
> }
> ctx->mmap_indirections_table = mmap(NULL, qemu_real_host_page_size(),
> PROT_READ | PROT_WRITE, MAP_SHARED,
> ctx->map_indirections_table, 0);
> if (ctx->mmap_indirections_table == MAP_FAILED) {
> +trace_ebpf_error("eBPF RSS", "can not mmap eBPF indirection table");
> goto indirection_fail;
> }
>
> @@ -108,12 +113,14 @@ bool ebpf_rss_load(struct EBPFRSSContext *ctx)
>
> rss_bpf_ctx = rss_bpf__open();
> if (rss_bpf_ctx == NULL) {
> +trace_ebpf_error("eBPF RSS", "can not open eBPF RSS object");
> goto error;
> }
>
> bpf_program__set_type(rss_bpf_ctx->progs.tun_rss_steering_prog,
> BPF_PROG_TYPE_SOCKET_FILTER);
>
> if (rss_bpf__load(rss_bpf_ctx)) {
> +trace_ebpf_error("eBPF RSS", "can not load RSS program");
> goto error;
> }
>
> diff --git a/ebpf/meson.build b/ebpf/meson.build
> index c5bf9295a20..bff6156f518 100644
> --- a/ebpf/meson.build
> +++ b/ebpf/meson.build
> @@ -1 +1 @@
> -common_ss.add(when: libbpf, if_true: files('ebpf.c', 'ebpf_rss.c'),
> if_false: files('ebpf_rss-stub.c'))
> +system_ss.add(when: libbpf, if_true: files('ebpf.c', 'ebpf_rss.c'),
> if_false: files('ebpf_rss-stub.c'))
> diff --git a/ebpf/trace.h b/ebpf/trace.h
> new file mode 100644
> index 000..abefc46ab10
> --- /dev/null
> +++ b/ebpf/trace.h
> @@ -0,0 +1 @@
> +#include "trace/trace-ebpf.h"
> --
> 2.44.0
>
[PATCH v2 1/1] ebpf: Added traces back. Changed source set for eBPF to 'system'.
There was an issue with Qemu build with "--disable-system".
The traces could be generated and the build fails.
The traces were 'cut out' for previous patches, and overall,
the 'system' source set should be used like in pre-'eBPF blob' patches.
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf_rss.c | 7 +++
ebpf/meson.build | 2 +-
ebpf/trace.h | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
create mode 100644 ebpf/trace.h
diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
index d102f3dd092..87f0714910e 100644
--- a/ebpf/ebpf_rss.c
+++ b/ebpf/ebpf_rss.c
@@ -25,6 +25,8 @@
#include "ebpf/rss.bpf.skeleton.h"
#include "ebpf/ebpf.h"
+#include "trace.h"
+
void ebpf_rss_init(struct EBPFRSSContext *ctx)
{
if (ctx != NULL) {
@@ -55,18 +57,21 @@ static bool ebpf_rss_mmap(struct EBPFRSSContext *ctx)
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_configuration, 0);
if (ctx->mmap_configuration == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF configuration array");
return false;
}
ctx->mmap_toeplitz_key = mmap(NULL, qemu_real_host_page_size(),
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_toeplitz_key, 0);
if (ctx->mmap_toeplitz_key == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF toeplitz key");
goto toeplitz_fail;
}
ctx->mmap_indirections_table = mmap(NULL, qemu_real_host_page_size(),
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_indirections_table, 0);
if (ctx->mmap_indirections_table == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF indirection table");
goto indirection_fail;
}
@@ -108,12 +113,14 @@ bool ebpf_rss_load(struct EBPFRSSContext *ctx)
rss_bpf_ctx = rss_bpf__open();
if (rss_bpf_ctx == NULL) {
+trace_ebpf_error("eBPF RSS", "can not open eBPF RSS object");
goto error;
}
bpf_program__set_type(rss_bpf_ctx->progs.tun_rss_steering_prog,
BPF_PROG_TYPE_SOCKET_FILTER);
if (rss_bpf__load(rss_bpf_ctx)) {
+trace_ebpf_error("eBPF RSS", "can not load RSS program");
goto error;
}
diff --git a/ebpf/meson.build b/ebpf/meson.build
index c5bf9295a20..bff6156f518 100644
--- a/ebpf/meson.build
+++ b/ebpf/meson.build
@@ -1 +1 @@
-common_ss.add(when: libbpf, if_true: files('ebpf.c', 'ebpf_rss.c'), if_false:
files('ebpf_rss-stub.c'))
+system_ss.add(when: libbpf, if_true: files('ebpf.c', 'ebpf_rss.c'), if_false:
files('ebpf_rss-stub.c'))
diff --git a/ebpf/trace.h b/ebpf/trace.h
new file mode 100644
index 000..abefc46ab10
--- /dev/null
+++ b/ebpf/trace.h
@@ -0,0 +1 @@
+#include "trace/trace-ebpf.h"
--
2.44.0
[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: [External] Re: [PATCH v11 1/2] memory tier: dax/kmem: introduce an abstract layer for finding, allocating, and putting memory types
On Tue, 9 Apr 2024 12:00:06 -0700 "Ho-Ren (Jack) Chuang" wrote: > Hi Jonathan, > > On Fri, Apr 5, 2024 at 6:56 AM Jonathan Cameron > wrote: > > > > On Fri, 5 Apr 2024 00:07:05 + > > "Ho-Ren (Jack) Chuang" wrote: > > > > > Since different memory devices require finding, allocating, and putting > > > memory types, these common steps are abstracted in this patch, > > > enhancing the scalability and conciseness of the code. > > > > > > Signed-off-by: Ho-Ren (Jack) Chuang > > > Reviewed-by: "Huang, Ying" > > Reviewed-by: Jonathan Cameron > > > Thank you for reviewing and for adding your "Reviewed-by"! > I was wondering if I need to send a v12 and manually add > this to the commit description, or if this is sufficient. I had added Jonathan's r-b to the mm.git copy of this patch.
[PATCH 1/1] ebpf: Added traces back. Changed source set for eBPF to 'system'.
There was an issue with Qemu build with "--disable-system".
The traces could be generated and the build fails.
The traces were 'cut out' for previous patches, and overall,
the 'system' source set should be used like in pre-'eBPF blob' patches.
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf_rss.c | 7 +++
ebpf/meson.build | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
index 2e506f97435..c8a68da2c56 100644
--- a/ebpf/ebpf_rss.c
+++ b/ebpf/ebpf_rss.c
@@ -25,6 +25,8 @@
#include "ebpf/rss.bpf.skeleton.h"
#include "ebpf/ebpf.h"
+#include "trace.h"
+
void ebpf_rss_init(struct EBPFRSSContext *ctx)
{
if (ctx != NULL) {
@@ -55,18 +57,21 @@ static bool ebpf_rss_mmap(struct EBPFRSSContext *ctx)
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_configuration, 0);
if (ctx->mmap_configuration == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF configuration array");
return false;
}
ctx->mmap_toeplitz_key = mmap(NULL, qemu_real_host_page_size(),
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_toeplitz_key, 0);
if (ctx->mmap_toeplitz_key == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF toeplitz key");
goto toeplitz_fail;
}
ctx->mmap_indirections_table = mmap(NULL, qemu_real_host_page_size(),
PROT_READ | PROT_WRITE, MAP_SHARED,
ctx->map_indirections_table, 0);
if (ctx->mmap_indirections_table == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF indirection table");
goto indirection_fail;
}
@@ -108,12 +113,14 @@ bool ebpf_rss_load(struct EBPFRSSContext *ctx)
rss_bpf_ctx = rss_bpf__open();
if (rss_bpf_ctx == NULL) {
+trace_ebpf_error("eBPF RSS", "can not open eBPF RSS object");
goto error;
}
bpf_program__set_type(rss_bpf_ctx->progs.tun_rss_steering_prog,
BPF_PROG_TYPE_SOCKET_FILTER);
if (rss_bpf__load(rss_bpf_ctx)) {
+trace_ebpf_error("eBPF RSS", "can not load RSS program");
goto error;
}
diff --git a/ebpf/meson.build b/ebpf/meson.build
index c5bf9295a20..bff6156f518 100644
--- a/ebpf/meson.build
+++ b/ebpf/meson.build
@@ -1 +1 @@
-common_ss.add(when: libbpf, if_true: files('ebpf.c', 'ebpf_rss.c'), if_false:
files('ebpf_rss-stub.c'))
+system_ss.add(when: libbpf, if_true: files('ebpf.c', 'ebpf_rss.c'), if_false:
files('ebpf_rss-stub.c'))
--
2.43.0
Re: [PATCH v2 2/2] ebpf: Fix indirections table setting
Hi all,
I've reviewed and checked - this patch is necessary!
Acked-by: and...@daynix.com
On Thu, Mar 28, 2024 at 11:39 AM Yuri Benditovich
wrote:
>
> Hi Andrew,
> Can you please check the indirection table copy and ack on the patch
> if the fix is correct
>
> Thanks,
> Yuri
>
> On Wed, Mar 27, 2024 at 4:05 AM Akihiko Odaki
> wrote:
> >
> > The kernel documentation says:
> > > The value stored can be of any size, however, all array elements are
> > > aligned to 8 bytes.
> > https://www.kernel.org/doc/html/v6.8/bpf/map_array.html
> >
> > Fixes: 333b3e5fab75 ("ebpf: Added eBPF map update through mmap.")
> > Signed-off-by: Akihiko Odaki
> > ---
> > ebpf/ebpf_rss.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
> > index 2e506f974357..d102f3dd0929 100644
> > --- a/ebpf/ebpf_rss.c
> > +++ b/ebpf/ebpf_rss.c
> > @@ -185,13 +185,18 @@ static bool ebpf_rss_set_indirections_table(struct
> > EBPFRSSContext *ctx,
> > uint16_t *indirections_table,
> > size_t len)
> > {
> > +char *cursor = ctx->mmap_indirections_table;
> > +
> > if (!ebpf_rss_is_loaded(ctx) || indirections_table == NULL ||
> > len > VIRTIO_NET_RSS_MAX_TABLE_LEN) {
> > return false;
> > }
> >
> > -memcpy(ctx->mmap_indirections_table, indirections_table,
> > -sizeof(*indirections_table) * len);
> > +for (size_t i = 0; i < len; i++) {
> > +*(uint16_t *)cursor = indirections_table[i];
> > +cursor += 8;
> > +}
> > +
> > return true;
> > }
> >
> >
> > --
> > 2.44.0
> >
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] misc/pca955*: Move models under hw/gpio
On Mon, 2024-03-25 at 14:48 +0100, Cédric Le Goater wrote: > The PCA9552 and PCA9554 devices are both I2C GPIO controllers and the > PCA9552 also can drive LEDs. Do all the necessary adjustments to move > the models under hw/gpio. > > Cc: Glenn Miles > Signed-off-by: Cédric Le Goater Acked-by: Andrew Jeffery
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 v9 4/5] qmp: Added new command to retrieve eBPF blob.
Hi all, I've checked - apparently, qapi/ebpf.json should be added to MAINTAINERS - I'll fix it. On Fri, Mar 8, 2024 at 10:14 AM Jason Wang wrote: > > On Tue, Feb 6, 2024 at 12:55 AM Andrew Melnychenko wrote: > > > > Now, the binary objects may be retrieved by id. > > It would require for future qmp commands that may require specific > > eBPF blob. > > > > Added command "request-ebpf". This command returns > > eBPF program encoded base64. The program taken from the > > skeleton and essentially is an ELF object that can be > > loaded in the future with libbpf. > > > > The reason to use the command to provide the eBPF object > > instead of a separate artifact was to avoid issues related > > to finding the eBPF itself. eBPF object is an ELF binary > > that contains the eBPF program and eBPF map description(BTF). > > Overall, eBPF object should contain the program and enough > > metadata to create/load eBPF with libbpf. As the eBPF > > maps/program should correspond to QEMU, the eBPF can't > > be used from different QEMU build. > > > > The first solution was a helper that comes with QEMU > > and loads appropriate eBPF objects. And the issue is > > to find a proper helper if the system has several > > different QEMUs installed and/or built from the source, > > which helpers may not be compatible. > > > > Another issue is QEMU updating while there is a running > > QEMU instance. With an updated helper, it may not be > > possible to hotplug virtio-net device to the already > > running QEMU. Overall, requesting the eBPF object from > > QEMU itself solves possible failures with acceptable effort. > > > > Links: > > [PATCH 3/5] qmp: Added the helper stamp check. > > https://lore.kernel.org/all/20230219162100.174318-4-and...@daynix.com/ > > > > Signed-off-by: Andrew Melnychenko > > --- > > ebpf/ebpf.c | 69 +++ > > Let's add ebpf.c to MAINTAINERS otherwise CI may warn like: > > https://gitlab.com/jasowang/qemu/-/jobs/6349138969 > > Thanks >
Re: [PATCH v9 0/5] eBPF RSS through QMP support.
Hi all, Apparently, eBPF code from ebpf/* can't be a part of the 'common' library - that breaks non-system/user build. I'll change it to be a 'system' library. On Fri, Mar 8, 2024 at 10:06 AM Jason Wang wrote: > > On Fri, Mar 8, 2024 at 2:30 PM Jason Wang wrote: > > > > On Mon, Feb 26, 2024 at 6:23 PM Andrew Melnichenko > > wrote: > > > > > > Hi all, > > > Jason, can you please review the patch set, thank you. > > > > Queued. > > > > Thanks > > This seems to fail CI at: > > https://gitlab.com/jasowang/qemu/-/jobs/6348725269 > > Please fix this. > > Thanks >
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 v9 0/5] eBPF RSS through QMP support.
Hi all, Jason, can you please review the patch set, thank you. On Mon, Feb 5, 2024 at 6:54 PM Andrew Melnychenko wrote: > > This series of patches provides the ability to retrieve eBPF program > through qmp, so management application may load bpf blob with proper > capabilities. > Now, virtio-net devices can accept eBPF programs and maps through properties > as external file descriptors. Access to the eBPF map is direct through mmap() > call, so it should not require additional capabilities to bpf* calls. > eBPF file descriptors can be passed to QEMU from parent process or by unix > socket with sendfd() qmp command. > > Changes since v8: > * rebased and refactored QMP interface > * license SPDX id only for new files > > Changes since v7: > * rebased and refactored > * used SPDX license identifier > * used DEFINE_PROP_ARRAY() for virtio-net "ebpf-rss-fds" property > > Changes since v6: > * added comments to ebpf.json > * added libbpf version requirements to meson script with BPF_F_MMAPABLE check > > Changes since v5: > * refactored ebpf.json > > Changes since v4: > * refactored commit hunks > * added explicit BPF_F_MMAPABLE declaration > > Changes since v3: > * fixed issue with the build if bpf disabled > * rebased to the last master > * refactored according to review > > Changes since v2: > * moved/refactored QMP command > * refactored virtio-net > > Changes since v1: > * refactored virtio-net > * moved hunks for ebpf mmap() > * added qmp enum for eBPF id. > > Andrew Melnychenko (5): > ebpf: Added eBPF map update through mmap. > ebpf: Added eBPF initialization by fds. > virtio-net: Added property to load eBPF RSS with fds. > qmp: Added new command to retrieve eBPF blob. > ebpf: Updated eBPF program and skeleton. > > ebpf/ebpf.c| 69 ++ > ebpf/ebpf.h| 29 + > ebpf/ebpf_rss-stub.c |6 + > ebpf/ebpf_rss.c| 150 +++- > ebpf/ebpf_rss.h| 10 + > ebpf/meson.build |2 +- > ebpf/rss.bpf.skeleton.h| 1343 > hw/net/virtio-net.c| 54 +- > include/hw/virtio/virtio-net.h |2 + > meson.build| 10 +- > qapi/ebpf.json | 66 ++ > qapi/meson.build |1 + > qapi/qapi-schema.json |1 + > tools/ebpf/rss.bpf.c |7 +- > 14 files changed, 1047 insertions(+), 703 deletions(-) > create mode 100644 ebpf/ebpf.c > create mode 100644 ebpf/ebpf.h > create mode 100644 qapi/ebpf.json > > -- > 2.43.0 >
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
>
>
[PATCH v9 4/5] qmp: Added new command to retrieve eBPF blob.
Now, the binary objects may be retrieved by id.
It would require for future qmp commands that may require specific
eBPF blob.
Added command "request-ebpf". This command returns
eBPF program encoded base64. The program taken from the
skeleton and essentially is an ELF object that can be
loaded in the future with libbpf.
The reason to use the command to provide the eBPF object
instead of a separate artifact was to avoid issues related
to finding the eBPF itself. eBPF object is an ELF binary
that contains the eBPF program and eBPF map description(BTF).
Overall, eBPF object should contain the program and enough
metadata to create/load eBPF with libbpf. As the eBPF
maps/program should correspond to QEMU, the eBPF can't
be used from different QEMU build.
The first solution was a helper that comes with QEMU
and loads appropriate eBPF objects. And the issue is
to find a proper helper if the system has several
different QEMUs installed and/or built from the source,
which helpers may not be compatible.
Another issue is QEMU updating while there is a running
QEMU instance. With an updated helper, it may not be
possible to hotplug virtio-net device to the already
running QEMU. Overall, requesting the eBPF object from
QEMU itself solves possible failures with acceptable effort.
Links:
[PATCH 3/5] qmp: Added the helper stamp check.
https://lore.kernel.org/all/20230219162100.174318-4-and...@daynix.com/
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf.c | 69 +++
ebpf/ebpf.h | 29 ++
ebpf/ebpf_rss.c | 6
ebpf/meson.build | 2 +-
qapi/ebpf.json| 66 +
qapi/meson.build | 1 +
qapi/qapi-schema.json | 1 +
7 files changed, 173 insertions(+), 1 deletion(-)
create mode 100644 ebpf/ebpf.c
create mode 100644 ebpf/ebpf.h
create mode 100644 qapi/ebpf.json
diff --git a/ebpf/ebpf.c b/ebpf/ebpf.c
new file mode 100644
index 00..2d73beb479
--- /dev/null
+++ b/ebpf/ebpf.c
@@ -0,0 +1,69 @@
+/*
+ * QEMU eBPF binary declaration routine.
+ *
+ * Developed by Daynix Computing LTD (http://www.daynix.com)
+ *
+ * Authors:
+ * Andrew Melnychenko
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/queue.h"
+#include "qapi/error.h"
+#include "qapi/qapi-commands-ebpf.h"
+#include "ebpf/ebpf.h"
+
+typedef struct ElfBinaryDataEntry {
+int id;
+const void *data;
+size_t datalen;
+
+QSLIST_ENTRY(ElfBinaryDataEntry) node;
+} ElfBinaryDataEntry;
+
+static QSLIST_HEAD(, ElfBinaryDataEntry) ebpf_elf_obj_list =
+QSLIST_HEAD_INITIALIZER();
+
+void ebpf_register_binary_data(int id, const void *data, size_t datalen)
+{
+struct ElfBinaryDataEntry *dataentry = NULL;
+
+dataentry = g_new0(struct ElfBinaryDataEntry, 1);
+dataentry->data = data;
+dataentry->datalen = datalen;
+dataentry->id = id;
+
+QSLIST_INSERT_HEAD(_elf_obj_list, dataentry, node);
+}
+
+const void *ebpf_find_binary_by_id(int id, size_t *sz, Error **errp)
+{
+struct ElfBinaryDataEntry *it = NULL;
+QSLIST_FOREACH(it, _elf_obj_list, node) {
+if (id == it->id) {
+*sz = it->datalen;
+return it->data;
+}
+}
+
+error_setg(errp, "can't find eBPF object with id: %d", id);
+
+return NULL;
+}
+
+EbpfObject *qmp_request_ebpf(EbpfProgramID id, Error **errp)
+{
+EbpfObject *ret = NULL;
+size_t size = 0;
+const void *data = ebpf_find_binary_by_id(id, , errp);
+if (!data) {
+return NULL;
+}
+
+ret = g_new0(EbpfObject, 1);
+ret->object = g_base64_encode(data, size);
+
+return ret;
+}
diff --git a/ebpf/ebpf.h b/ebpf/ebpf.h
new file mode 100644
index 00..378d4e9c70
--- /dev/null
+++ b/ebpf/ebpf.h
@@ -0,0 +1,29 @@
+/*
+ * QEMU eBPF binary declaration routine.
+ *
+ * Developed by Daynix Computing LTD (http://www.daynix.com)
+ *
+ * Authors:
+ * Andrew Melnychenko
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef EBPF_H
+#define EBPF_H
+
+
+void ebpf_register_binary_data(int id, const void *data,
+ size_t datalen);
+const void *ebpf_find_binary_by_id(int id, size_t *sz,
+ struct Error **errp);
+
+#define ebpf_binary_init(id, fn) \
+static void __attribute__((constructor)) ebpf_binary_init_ ## fn(void) \
+{ \
+size_t datalen = 0;\
+const void *data = fn(); \
+ebpf_register_binary_data(id, data, datalen); \
+}
+
+#endif /* EBPF_H */
diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
index 150aa40813..c8a68d
[PATCH v9 2/5] ebpf: Added eBPF initialization by fds.
It allows using file descriptors of eBPF provided
outside of QEMU.
QEMU may be run without capabilities for eBPF and run
RSS program provided by management tool(g.e. libvirt).
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf_rss-stub.c | 6 ++
ebpf/ebpf_rss.c | 27 +++
ebpf/ebpf_rss.h | 5 +
3 files changed, 38 insertions(+)
diff --git a/ebpf/ebpf_rss-stub.c b/ebpf/ebpf_rss-stub.c
index e71e229190..8d7fae2ad9 100644
--- a/ebpf/ebpf_rss-stub.c
+++ b/ebpf/ebpf_rss-stub.c
@@ -28,6 +28,12 @@ bool ebpf_rss_load(struct EBPFRSSContext *ctx)
return false;
}
+bool ebpf_rss_load_fds(struct EBPFRSSContext *ctx, int program_fd,
+ int config_fd, int toeplitz_fd, int table_fd)
+{
+return false;
+}
+
bool ebpf_rss_set_all(struct EBPFRSSContext *ctx, struct EBPFRSSConfig *config,
uint16_t *indirections_table, uint8_t *toeplitz_key)
{
diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
index f774d9636b..150aa40813 100644
--- a/ebpf/ebpf_rss.c
+++ b/ebpf/ebpf_rss.c
@@ -146,6 +146,33 @@ error:
return false;
}
+bool ebpf_rss_load_fds(struct EBPFRSSContext *ctx, int program_fd,
+ int config_fd, int toeplitz_fd, int table_fd)
+{
+if (ebpf_rss_is_loaded(ctx)) {
+return false;
+}
+
+if (program_fd < 0 || config_fd < 0 || toeplitz_fd < 0 || table_fd < 0) {
+return false;
+}
+
+ctx->program_fd = program_fd;
+ctx->map_configuration = config_fd;
+ctx->map_toeplitz_key = toeplitz_fd;
+ctx->map_indirections_table = table_fd;
+
+if (!ebpf_rss_mmap(ctx)) {
+ctx->program_fd = -1;
+ctx->map_configuration = -1;
+ctx->map_toeplitz_key = -1;
+ctx->map_indirections_table = -1;
+return false;
+}
+
+return true;
+}
+
static bool ebpf_rss_set_config(struct EBPFRSSContext *ctx,
struct EBPFRSSConfig *config)
{
diff --git a/ebpf/ebpf_rss.h b/ebpf/ebpf_rss.h
index ab08a7266d..239242b0d2 100644
--- a/ebpf/ebpf_rss.h
+++ b/ebpf/ebpf_rss.h
@@ -14,6 +14,8 @@
#ifndef QEMU_EBPF_RSS_H
#define QEMU_EBPF_RSS_H
+#define EBPF_RSS_MAX_FDS 4
+
struct EBPFRSSContext {
void *obj;
int program_fd;
@@ -41,6 +43,9 @@ bool ebpf_rss_is_loaded(struct EBPFRSSContext *ctx);
bool ebpf_rss_load(struct EBPFRSSContext *ctx);
+bool ebpf_rss_load_fds(struct EBPFRSSContext *ctx, int program_fd,
+ int config_fd, int toeplitz_fd, int table_fd);
+
bool ebpf_rss_set_all(struct EBPFRSSContext *ctx, struct EBPFRSSConfig *config,
uint16_t *indirections_table, uint8_t *toeplitz_key);
--
2.43.0
[PATCH v9 0/5] eBPF RSS through QMP support.
This series of patches provides the ability to retrieve eBPF program through qmp, so management application may load bpf blob with proper capabilities. Now, virtio-net devices can accept eBPF programs and maps through properties as external file descriptors. Access to the eBPF map is direct through mmap() call, so it should not require additional capabilities to bpf* calls. eBPF file descriptors can be passed to QEMU from parent process or by unix socket with sendfd() qmp command. Changes since v8: * rebased and refactored QMP interface * license SPDX id only for new files Changes since v7: * rebased and refactored * used SPDX license identifier * used DEFINE_PROP_ARRAY() for virtio-net "ebpf-rss-fds" property Changes since v6: * added comments to ebpf.json * added libbpf version requirements to meson script with BPF_F_MMAPABLE check Changes since v5: * refactored ebpf.json Changes since v4: * refactored commit hunks * added explicit BPF_F_MMAPABLE declaration Changes since v3: * fixed issue with the build if bpf disabled * rebased to the last master * refactored according to review Changes since v2: * moved/refactored QMP command * refactored virtio-net Changes since v1: * refactored virtio-net * moved hunks for ebpf mmap() * added qmp enum for eBPF id. Andrew Melnychenko (5): ebpf: Added eBPF map update through mmap. ebpf: Added eBPF initialization by fds. virtio-net: Added property to load eBPF RSS with fds. qmp: Added new command to retrieve eBPF blob. ebpf: Updated eBPF program and skeleton. ebpf/ebpf.c| 69 ++ ebpf/ebpf.h| 29 + ebpf/ebpf_rss-stub.c |6 + ebpf/ebpf_rss.c| 150 +++- ebpf/ebpf_rss.h| 10 + ebpf/meson.build |2 +- ebpf/rss.bpf.skeleton.h| 1343 hw/net/virtio-net.c| 54 +- include/hw/virtio/virtio-net.h |2 + meson.build| 10 +- qapi/ebpf.json | 66 ++ qapi/meson.build |1 + qapi/qapi-schema.json |1 + tools/ebpf/rss.bpf.c |7 +- 14 files changed, 1047 insertions(+), 703 deletions(-) create mode 100644 ebpf/ebpf.c create mode 100644 ebpf/ebpf.h create mode 100644 qapi/ebpf.json -- 2.43.0
[PATCH v9 5/5] ebpf: Updated eBPF program and skeleton.
Updated section name, so libbpf should init/gues proper
program type without specifications during open/load.
Also, added map_flags with explicitly declared BPF_F_MMAPABLE.
Added check for BPF_F_MMAPABLE flag to meson script and
requirements to libbpf version.
Also changed fragmentation flag check - some TCP/UDP packets
may be considered fragmented if DF flag is set.
Signed-off-by: Andrew Melnychenko
---
ebpf/rss.bpf.skeleton.h | 1343 ---
meson.build | 10 +-
tools/ebpf/rss.bpf.c|7 +-
3 files changed, 687 insertions(+), 673 deletions(-)
diff --git a/ebpf/rss.bpf.skeleton.h b/ebpf/rss.bpf.skeleton.h
index 18eb2adb12..aed4ef9a03 100644
--- a/ebpf/rss.bpf.skeleton.h
+++ b/ebpf/rss.bpf.skeleton.h
@@ -176,642 +176,647 @@ err:
static inline const void *rss_bpf__elf_bytes(size_t *sz)
{
- *sz = 20440;
+ *sz = 20600;
return (const void *)"\
\x7f\x45\x4c\x46\x02\x01\x01\0\0\0\0\0\0\0\0\0\x01\0\xf7\0\x01\0\0\0\0\0\0\0\0\
-\0\0\0\0\0\0\0\0\0\0\0\x98\x4c\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x0d\0\
-\x01\0\xbf\x19\0\0\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\x54\xff\0\0\0\0\xbf\xa7\
-\0\0\0\0\0\0\x07\x07\0\0\x54\xff\xff\xff\x18\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
+\0\0\0\0\0\0\0\0\0\0\0\x38\x4d\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x0d\0\
+\x01\0\xbf\x19\0\0\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\x4c\xff\0\0\0\0\xbf\xa7\
+\0\0\0\0\0\0\x07\x07\0\0\x4c\xff\xff\xff\x18\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x06\0\0\0\0\0\0\x18\x01\0\0\0\0\0\
-\0\0\0\0\0\0\0\0\0\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x08\0\0\0\0\0\0\
-\x18\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x15\x06\x67\x02\0\0\0\0\xbf\x87\0\0\
-\0\0\0\0\x15\x07\x65\x02\0\0\0\0\x71\x61\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\
-\0\x5e\x02\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xc8\xff\0\0\0\0\x7b\x1a\xc0\xff\
-\0\0\0\0\x7b\x1a\xb8\xff\0\0\0\0\x7b\x1a\xb0\xff\0\0\0\0\x7b\x1a\xa8\xff\0\0\0\
-\0\x63\x1a\xa0\xff\0\0\0\0\x7b\x1a\x98\xff\0\0\0\0\x7b\x1a\x90\xff\0\0\0\0\x7b\
-\x1a\x88\xff\0\0\0\0\x7b\x1a\x80\xff\0\0\0\0\x7b\x1a\x78\xff\0\0\0\0\x7b\x1a\
-\x70\xff\0\0\0\0\x7b\x1a\x68\xff\0\0\0\0\x7b\x1a\x60\xff\0\0\0\0\x7b\x1a\x58\
-\xff\0\0\0\0\x15\x09\x4d\x02\0\0\0\0\x6b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\
-\0\x07\x03\0\0\xd0\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x02\0\0\x0c\0\0\0\xb7\
+\0\0\0\0\0\0\0\0\0\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x07\0\0\0\0\0\0\
+\x18\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x15\x06\x61\x02\0\0\0\0\xbf\x78\0\0\
+\0\0\0\0\x15\x08\x5f\x02\0\0\0\0\x71\x61\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\
+\0\x58\x02\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xc0\xff\0\0\0\0\x7b\x1a\xb8\xff\
+\0\0\0\0\x7b\x1a\xb0\xff\0\0\0\0\x7b\x1a\xa8\xff\0\0\0\0\x7b\x1a\xa0\xff\0\0\0\
+\0\x63\x1a\x98\xff\0\0\0\0\x7b\x1a\x90\xff\0\0\0\0\x7b\x1a\x88\xff\0\0\0\0\x7b\
+\x1a\x80\xff\0\0\0\0\x7b\x1a\x78\xff\0\0\0\0\x7b\x1a\x70\xff\0\0\0\0\x7b\x1a\
+\x68\xff\0\0\0\0\x7b\x1a\x60\xff\0\0\0\0\x7b\x1a\x58\xff\0\0\0\0\x7b\x1a\x50\
+\xff\0\0\0\0\x15\x09\x47\x02\0\0\0\0\x6b\x1a\xc8\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\
+\0\x07\x03\0\0\xc8\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x02\0\0\x0c\0\0\0\xb7\
\x04\0\0\x02\0\0\0\xb7\x05\0\0\0\0\0\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\
-\x77\0\0\0\x20\0\0\0\x55\0\x42\x02\0\0\0\0\xb7\x02\0\0\x10\0\0\0\x69\xa1\xd0\
+\x77\0\0\0\x20\0\0\0\x55\0\x3c\x02\0\0\0\0\xb7\x02\0\0\x10\0\0\0\x69\xa1\xc8\
\xff\0\0\0\0\xbf\x13\0\0\0\0\0\0\xdc\x03\0\0\x10\0\0\0\x15\x03\x02\0\0\x81\0\0\
\x55\x03\x0b\0\xa8\x88\0\0\xb7\x02\0\0\x14\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\
-\0\xd0\xff\xff\xff\xbf\x91\0\0\0\0\0\0\xb7\x04\0\0\x02\0\0\0\xb7\x05\0\0\0\0\0\
-\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\0\x77\0\0\0\x20\0\0\0\x55\0\x32\x02\0\
-\0\0\0\x69\xa1\xd0\xff\0\0\0\0\x15\x01\x30\x02\0\0\0\0\x7b\x7a\x38\xff\0\0\0\0\
-\x7b\x9a\x40\xff\0\0\0\0\x15\x01\x55\0\x86\xdd\0\0\x55\x01\x39\0\x08\0\0\0\xb7\
-\x07\0\0\x01\0\0\0\x73\x7a\x58\xff\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xe0\xff\
-\0\0\0\0\x7b\x1a\xd8\xff\0\0\0\0\x7b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\0\
-\x07\x03\0\0\xd0\xff\xff\xff\x79\xa1\x40\xff\0\0\0\0\xb7\x02\0\0\0\0\0\0\xb7\
-\x04\0\0\x14\0\0\0\xb7\x05\0\0\x01\0\0\0\x85\0\0\0\x44\0\0\0\x67\0\0\0\x20\0\0\
-\0\x77\0\0\0\x20\0\0\0\x55\0\x1c\x02\0\0\0\0\x69\xa1\xd6\xff\0\0\0\0\x55\x01\
-\x01\0\0\0\0\0\xb7\x07\0\0\0\0\0\0\x61\xa1\xdc\xff\0\0\0\0\x63\x1a\x64\xff\0\0\
-\0\0\x61\xa1\xe0\xff\0\0\0\0\x63\x1a\x68\xff\0\0\0\0\x71\xa9\xd9\xff\0\0\0\0\
-\x73\x7a\x5e\xff\0\0\0\0\x71\xa1\xd0\xff\0\0\0\0\x67\x01\0\0\x02\0\0\0\x57\x01\
-\0\0\x3c\0\0\0\x7b\x1a\x48\xff\0\0\0\0\xbf\x91\0\0\0\0\0\0\x57\x01\0\0\xff\0\0\
-\0\x15\x01\x19\0\0\0\0\0\x57\x07\0\0\xff\0\0\0\x55\x07\x17\0\0\0\0\0\x57\x09\0\
-\0\xff\0\0\0\x15\x09\x5a\x01\x11\0\0\0\x55\x09\x14\0\x06\0\0\0\xb7\x01\0\0\x01\
-\0\0\0\x73\x1a\x5b\xff\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xe0\xff\0\0\0\0\x7b\
-\x1a\xd8\xff\0\0\0\0\x7b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\0\x07\x03\0\0\
-\xd0\xff\xff\xff\x79\xa1\x40\xff\0\0\0\0\x7
[PATCH v9 3/5] virtio-net: Added property to load eBPF RSS with fds.
eBPF RSS program and maps may now be passed during initialization.
Initially was implemented for libvirt to launch qemu without permissions,
and initialized eBPF program through the helper.
Signed-off-by: Andrew Melnychenko
---
hw/net/virtio-net.c| 54 ++
include/hw/virtio/virtio-net.h | 2 ++
2 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 5a79bc3a3a..d6dc5ff2ea 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -42,6 +42,7 @@
#include "sysemu/sysemu.h"
#include "trace.h"
#include "monitor/qdev.h"
+#include "monitor/monitor.h"
#include "hw/pci/pci_device.h"
#include "net_rx_pkt.h"
#include "hw/virtio/vhost.h"
@@ -1328,14 +1329,53 @@ static void virtio_net_detach_epbf_rss(VirtIONet *n)
virtio_net_attach_ebpf_to_backend(n->nic, -1);
}
-static bool virtio_net_load_ebpf(VirtIONet *n)
+static bool virtio_net_load_ebpf_fds(VirtIONet *n, Error **errp)
{
-if (!virtio_net_attach_ebpf_to_backend(n->nic, -1)) {
-/* backend doesn't support steering ebpf */
-return false;
+int fds[EBPF_RSS_MAX_FDS] = { [0 ... EBPF_RSS_MAX_FDS - 1] = -1};
+int ret = true;
+int i = 0;
+
+ERRP_GUARD();
+
+if (n->nr_ebpf_rss_fds != EBPF_RSS_MAX_FDS) {
+error_setg(errp,
+ "Expected %d file descriptors but got %d",
+ EBPF_RSS_MAX_FDS, n->nr_ebpf_rss_fds);
+ return false;
+ }
+
+for (i = 0; i < n->nr_ebpf_rss_fds; i++) {
+fds[i] = monitor_fd_param(monitor_cur(), n->ebpf_rss_fds[i], errp);
+if (*errp) {
+ret = false;
+goto exit;
+}
+}
+
+ret = ebpf_rss_load_fds(>ebpf_rss, fds[0], fds[1], fds[2], fds[3]);
+
+exit:
+if (!ret || *errp) {
+for (i = 0; i < n->nr_ebpf_rss_fds && fds[i] != -1; i++) {
+close(fds[i]);
+}
}
-return ebpf_rss_load(>ebpf_rss);
+return ret;
+}
+
+static bool virtio_net_load_ebpf(VirtIONet *n, Error **errp)
+{
+bool ret = false;
+
+if (virtio_net_attach_ebpf_to_backend(n->nic, -1)) {
+if (!(n->ebpf_rss_fds
+&& virtio_net_load_ebpf_fds(n, errp))) {
+ret = ebpf_rss_load(>ebpf_rss);
+}
+}
+
+return ret;
}
static void virtio_net_unload_ebpf(VirtIONet *n)
@@ -3767,7 +3807,7 @@ static void virtio_net_device_realize(DeviceState *dev,
Error **errp)
net_rx_pkt_init(>rx_pkt);
if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
-virtio_net_load_ebpf(n);
+virtio_net_load_ebpf(n, errp);
}
}
@@ -3929,6 +3969,8 @@ static Property virtio_net_properties[] = {
VIRTIO_NET_F_RSS, false),
DEFINE_PROP_BIT64("hash", VirtIONet, host_features,
VIRTIO_NET_F_HASH_REPORT, false),
+DEFINE_PROP_ARRAY("ebpf-rss-fds", VirtIONet, nr_ebpf_rss_fds,
+ ebpf_rss_fds, qdev_prop_string, char*),
DEFINE_PROP_BIT64("guest_rsc_ext", VirtIONet, host_features,
VIRTIO_NET_F_RSC_EXT, false),
DEFINE_PROP_UINT32("rsc_interval", VirtIONet, rsc_timeout,
diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
index 55977f01f0..566ec53e7e 100644
--- a/include/hw/virtio/virtio-net.h
+++ b/include/hw/virtio/virtio-net.h
@@ -225,6 +225,8 @@ struct VirtIONet {
VirtioNetRssData rss_data;
struct NetRxPkt *rx_pkt;
struct EBPFRSSContext ebpf_rss;
+uint32_t nr_ebpf_rss_fds;
+char **ebpf_rss_fds;
};
size_t virtio_net_handle_ctrl_iov(VirtIODevice *vdev,
--
2.43.0
[PATCH v9 1/5] ebpf: Added eBPF map update through mmap.
Changed eBPF map updates through mmaped array.
Mmaped arrays provide direct access to map data.
It should omit using bpf_map_update_elem() call,
which may require capabilities that are not present.
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf_rss.c | 117 ++--
ebpf/ebpf_rss.h | 5 +++
2 files changed, 99 insertions(+), 23 deletions(-)
diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c
index cee658c158..f774d9636b 100644
--- a/ebpf/ebpf_rss.c
+++ b/ebpf/ebpf_rss.c
@@ -27,19 +27,83 @@ void ebpf_rss_init(struct EBPFRSSContext *ctx)
{
if (ctx != NULL) {
ctx->obj = NULL;
+ctx->program_fd = -1;
+ctx->map_configuration = -1;
+ctx->map_toeplitz_key = -1;
+ctx->map_indirections_table = -1;
+
+ctx->mmap_configuration = NULL;
+ctx->mmap_toeplitz_key = NULL;
+ctx->mmap_indirections_table = NULL;
}
}
bool ebpf_rss_is_loaded(struct EBPFRSSContext *ctx)
{
-return ctx != NULL && ctx->obj != NULL;
+return ctx != NULL && (ctx->obj != NULL || ctx->program_fd != -1);
+}
+
+static bool ebpf_rss_mmap(struct EBPFRSSContext *ctx)
+{
+if (!ebpf_rss_is_loaded(ctx)) {
+return false;
+}
+
+ctx->mmap_configuration = mmap(NULL, qemu_real_host_page_size(),
+ PROT_READ | PROT_WRITE, MAP_SHARED,
+ ctx->map_configuration, 0);
+if (ctx->mmap_configuration == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF configuration array");
+return false;
+}
+ctx->mmap_toeplitz_key = mmap(NULL, qemu_real_host_page_size(),
+ PROT_READ | PROT_WRITE, MAP_SHARED,
+ ctx->map_toeplitz_key, 0);
+if (ctx->mmap_toeplitz_key == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF toeplitz key");
+goto toeplitz_fail;
+}
+ctx->mmap_indirections_table = mmap(NULL, qemu_real_host_page_size(),
+ PROT_READ | PROT_WRITE, MAP_SHARED,
+ ctx->map_indirections_table, 0);
+if (ctx->mmap_indirections_table == MAP_FAILED) {
+trace_ebpf_error("eBPF RSS", "can not mmap eBPF indirection table");
+goto indirection_fail;
+}
+
+return true;
+
+indirection_fail:
+munmap(ctx->mmap_toeplitz_key, qemu_real_host_page_size());
+ctx->mmap_toeplitz_key = NULL;
+toeplitz_fail:
+munmap(ctx->mmap_configuration, qemu_real_host_page_size());
+ctx->mmap_configuration = NULL;
+
+ctx->mmap_indirections_table = NULL;
+return false;
+}
+
+static void ebpf_rss_munmap(struct EBPFRSSContext *ctx)
+{
+if (!ebpf_rss_is_loaded(ctx)) {
+return;
+}
+
+munmap(ctx->mmap_indirections_table, qemu_real_host_page_size());
+munmap(ctx->mmap_toeplitz_key, qemu_real_host_page_size());
+munmap(ctx->mmap_configuration, qemu_real_host_page_size());
+
+ctx->mmap_configuration = NULL;
+ctx->mmap_toeplitz_key = NULL;
+ctx->mmap_indirections_table = NULL;
}
bool ebpf_rss_load(struct EBPFRSSContext *ctx)
{
struct rss_bpf *rss_bpf_ctx;
-if (ctx == NULL) {
+if (ebpf_rss_is_loaded(ctx)) {
return false;
}
@@ -66,10 +130,18 @@ bool ebpf_rss_load(struct EBPFRSSContext *ctx)
ctx->map_toeplitz_key = bpf_map__fd(
rss_bpf_ctx->maps.tap_rss_map_toeplitz_key);
+if (!ebpf_rss_mmap(ctx)) {
+goto error;
+}
+
return true;
error:
rss_bpf__destroy(rss_bpf_ctx);
ctx->obj = NULL;
+ctx->program_fd = -1;
+ctx->map_configuration = -1;
+ctx->map_toeplitz_key = -1;
+ctx->map_indirections_table = -1;
return false;
}
@@ -77,15 +149,11 @@ error:
static bool ebpf_rss_set_config(struct EBPFRSSContext *ctx,
struct EBPFRSSConfig *config)
{
-uint32_t map_key = 0;
-
if (!ebpf_rss_is_loaded(ctx)) {
return false;
}
-if (bpf_map_update_elem(ctx->map_configuration,
-_key, config, 0) < 0) {
-return false;
-}
+
+memcpy(ctx->mmap_configuration, config, sizeof(*config));
return true;
}
@@ -93,27 +161,19 @@ static bool ebpf_rss_set_indirections_table(struct
EBPFRSSContext *ctx,
uint16_t *indirections_table,
size_t len)
{
-uint32_t i = 0;
-
if (!ebpf_rss_is_loaded(ctx) || indirections_table == NULL ||
len > VIRTIO_NET_RSS_MAX_TABLE_LEN) {
return false;
}
-for (; i < len; ++i) {
-if (bpf_map_update_elem(ctx->map_indirections_table, ,
-indirections_tabl
Re: [PATCH v8 1/5] ebpf: Added eBPF map update through mmap.
Hi all, I'll revert the license changes and leave SPDX ids only for new files. On Tue, Jan 30, 2024 at 12:38 PM Daniel P. Berrangé wrote: > > On Thu, Jan 25, 2024 at 03:06:50PM +0200, Andrew Melnychenko wrote: > > Changed eBPF map updates through mmaped array. > > Mmaped arrays provide direct access to map data. > > It should omit using bpf_map_update_elem() call, > > which may require capabilities that are not present. > > > > Signed-off-by: Andrew Melnychenko > > --- > > ebpf/ebpf_rss.c | 120 ++-- > > ebpf/ebpf_rss.h | 8 +++- > > 2 files changed, 101 insertions(+), 27 deletions(-) > > > > diff --git a/ebpf/ebpf_rss.c b/ebpf/ebpf_rss.c > > index cee658c158..c6e10265a7 100644 > > --- a/ebpf/ebpf_rss.c > > +++ b/ebpf/ebpf_rss.c > > @@ -7,8 +7,7 @@ > > * Andrew Melnychenko > > * Yuri Benditovich > > * > > - * This work is licensed under the terms of the GNU GPL, version 2. See > > - * the COPYING file in the top-level directory. > > + * SPDX-License-Identifier: GPL-2.0-or-later > > > > diff --git a/ebpf/ebpf_rss.h b/ebpf/ebpf_rss.h > > index bf3f2572c7..404cf53613 100644 > > --- a/ebpf/ebpf_rss.h > > +++ b/ebpf/ebpf_rss.h > > @@ -7,8 +7,7 @@ > > * Andrew Melnychenko > > * Yuri Benditovich > > * > > - * This work is licensed under the terms of the GNU GPL, version 2. See > > - * the COPYING file in the top-level directory. > > + * SPDX-License-Identifier: GPL-2.0-or-later > > */ > > > > #ifndef QEMU_EBPF_RSS_H > > Thee are changing the file license. This *must* be done as a > standalone commit and show agreement from all contributors > who could hold copyright over the code. Fortunately I only > see one other contributor to these file, and the scope of > their change isn't copyrightable IMHO. > > > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| >
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 > >
