I wanted to share an update regarding the patch I've been working on. It
seems that the patch is not yet fully ready as it encountered some
issues during the check-qtest builds.
This is my first attempt at writing a test case related to migration,
and I'm aware that there may be areas where I
On 09/02/24 1:33 pm, Het Gala wrote:
I wanted to share an update regarding the patch I've been working on.
It seems that the patch is not yet fully ready as it encountered some
issues during the check-qtest builds.
Test fails with error:
55/59 qemu:qtest+qtest-x86_64 / qtest-x86_64/migration
Hello Jamin,
On 2/7/24 21:02, Jamin Lin via wrote:
The Aspeed datasheet refers to the UART controllers
as UART1 - UART13 for the ast10x0, ast2600, ast2500
and ast2400 SoCs and the Aspeed ast2700 introduces an UART0
and the UART controllers as UART0 - UART12.
To keep the naming in the QEMU model
On 2/7/24 20:52, Jamin Lin wrote:
In the previous design of ASPEED SOCs QEMU model, it set the boot
address at "0" which was the hardcode setting for ast10x0, ast2600,
ast2500 and ast2400.
According to the design of ast2700, it has bootmcu which is used for
executing SPL and initialize DRAM, the
Desperate attempt to enable access from ITU to SAAR registers, by
taking missing part of commits c9340491cc ("target-mips: implement
SAARI/SAAR registers") and c1af807054 ("target-mips: add I6500 core
configuration") from [*] which were partly committed as 5fb2dcd179
("target/mips: Provide R/W acce
On 2/8/24 21:43, Richard Henderson wrote:
On 2/7/24 08:20, del...@kernel.org wrote:
#define PSW_E 0x0400
+#define PSW_E_BIT 37 /* PA2.0 only */
#define PSW_W 0x0800 /* PA2.0 only */
+#define PSW_W_BIT 36 /* PA2.0 only */
...
+targ
Previous commits removed the MT*C0(SAAR) helpers which
were using CPUMIPSState::itu, we can now remove it too.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/cpu.h | 1 -
hw/mips/cps.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index ef2
Alternative to:
https://lore.kernel.org/qemu-devel/20240209085347.8446-1-phi...@linaro.org/
If the I6500 can not be tested or its support is incomplete,
there is no point in wasting energy maintaining it.
Philippe Mathieu-Daudé (11):
target/mips: Remove helpers accessing SAAR registers
hw/misc
This field is never set, so remove the unreachable code.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/cpu.h | 1 -
hw/misc/mips_itu.c | 6 --
2 files changed, 7 deletions(-)
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index 6ec2ff4b97..3b93591f7e 100644
--- a/target/mips/cp
Previous commit removed the MT*C0(SAAR) helpers which
were the only calls to itc_reconfigure() out of hw/,
we can reduce its scope and declare it statically.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/misc/mips_itu.h | 2 --
hw/misc/mips_itu.c | 2 +-
2 files changed, 1 inserti
This field is not set. Remove it along with the dead
code it was guarding.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/misc/mips_itu.h | 3 ---
hw/misc/mips_itu.c | 22 +++---
2 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/include/hw/misc/mips_i
DisasContext::saar boolean is never set, so this code
is not reachable. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/tcg/sysemu_helper.h.inc | 5 ---
target/mips/tcg/sysemu/cp0_helper.c | 55 -
target/mips/tcg/translate.c | 42
DisasContext::saar boolean is never set, so this code
is not reachable. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/tcg/sysemu_helper.h.inc | 1 -
target/mips/tcg/sysemu/cp0_helper.c | 8
target/mips/tcg/translate.c | 20
3 files chang
Remove the unused CP0_SAARI register.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/cpu.h| 1 -
target/mips/sysemu/machine.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index e621196ae1..c65e5fa162 100644
--- a/t
Remove the unused CP0_SAAR[2] registers.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/cpu.h| 1 -
target/mips/sysemu/machine.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index 3b93591f7e..e621196ae1 100644
---
I6500 support is incomplete as it lacks SAAR (Special Address
Access Register) and DSPRAM (Data Scratch Pad RAM) features.
Signed-off-by: Philippe Mathieu-Daudé
---
docs/about/removed-features.rst | 5 +
tests/qtest/machine-none-test.c | 2 +-
target/mips/cpu-defs.c.inc | 40 -
DisasContext::saar is not used, remove it.
Reported-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/tcg/translate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/mips/tcg/translate.h b/target/mips/tcg/translate.h
index 93a78b8121..2b6646b339 100644
--- a/targ
Since previous commit the MIPSITUState::cpu0 field is not
used anymore. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/misc/mips_itu.h | 1 -
hw/mips/cps.c | 2 --
hw/misc/mips_itu.c | 5 -
3 files changed, 8 deletions(-)
diff --git a/include/hw/misc/mi
On 9/2/24 08:22, Philippe Mathieu-Daudé wrote:
On 8/2/24 09:26, Paolo Bonzini wrote:
On Wed, Feb 7, 2024 at 8:12 PM Philippe Mathieu-Daudé
wrote:
Hi Paolo,
On 7/2/24 12:14, Paolo Bonzini wrote:
itc_reconfigure() is referenced from TCG, provide a stub if needed.
This makes it possible to bui
On 8/2/24 23:03, Bernhard Beschow wrote:
Resolves redundant code in the piix and q35 machines.
Signed-off-by: Bernhard Beschow
---
include/hw/i386/pc.h | 2 --
hw/i386/pc.c | 9 +++--
hw/i386/pc_piix.c| 2 --
hw/i386/pc_q35.c | 2 --
4 files changed, 3 insertions(+), 1
On 02/02/24 5:33 am, Alex Williamson wrote:
On Thu, 1 Feb 2024 13:10:48 -0500
"Michael S. Tsirkin" wrote:
On Thu, Feb 01, 2024 at 11:08:58PM +0530, Vinayak Kale wrote:
On 31/01/24 11:08 pm, Alex Williamson wrote:
On Wed, 31 Jan 2024 15:22:59 +0530
Vinayak Kale wrote:
On 31/01/24 12:2
On 2/6/24 23:33, Helge Deller wrote:
On 2/5/24 20:47, Sven Schnelle wrote:
Netbsd isn't able to detect a link on the emulated tulip card. That's
because netbsd reads the Chip Status Register of the Phy (address
0x14). The default phy data in the qemu tulip driver is all zero,
which means no link
On 2/8/24 05:30, Peter Xu wrote:
On Wed, Feb 07, 2024 at 02:33:35PM +0100, Cédric Le Goater wrote:
diff --git a/migration/ram.c b/migration/ram.c
index
136c237f4079f68d4e578cf1c72eec2efc815bc8..8dac9bac2fe8b8c19e102c771a7ef6e976252906
100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3498
On Fri, Feb 09, 2024 at 08:02:49AM +0100, Thomas Huth wrote:
> On 08/02/2024 20.23, Richard Schmitt wrote:
> > In an attempt to build qemu with hardened gcc compiler options, we
> > specified the -ftrapv switch rather than the -fwrapv switch. The
> > switches define the behavior of integer overflo
An access fault is raised when the Access Flag is not set in the
looked-up PTE and the AFFD field is not set in the corresponding context
descriptor. This was already implemented for stage 2. Implement it for
stage 1 as well.
Signed-off-by: Luc Michel
---
hw/arm/smmuv3-internal.h | 1 +
inc
On 2/8/24 06:48, Peter Xu wrote:
On Wed, Feb 07, 2024 at 02:33:36PM +0100, Cédric Le Goater wrote:
@@ -2936,14 +2940,14 @@ void memory_global_dirty_log_start(unsigned int flags)
trace_global_dirty_changed(global_dirty_tracking);
if (!old_flags) {
-MEMORY_LISTENER_CALL_GLO
On Fri, 9 Feb 2024 at 00:06, BALATON Zoltan wrote:
>
> This file is only used by system/physmem.c so move them together.
>
> Signed-off-by: BALATON Zoltan
> ---
> memory_ldst.c.inc => system/memory_ldst.c.inc | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename memory_ldst.c.inc => s
Am 07.02.2024 um 18:58 hat Michael Tokarev geschrieben:
> This is an incomplete first attempt only, there's a lot left to do.
>
> All the options in qemu-img is a complete mess, - no, inconsistent or
> incomplete syntax in documentation, many undocumented options, option
> names are used inconsist
v-to-apply-20240209
for you to fetch changes up to deb0ff0c777d20602ecc5b6f74f18cb7ecc0b91f:
target/riscv: add rv32i, rv32e and rv64e CPUs (2024-02-09 20:49:41 +1000)
RISC-V PR for 9.0
* Check for 'A' extension on all
From: Daniel Henrique Barboza
We'll use this function in target/riscv/cpu.c to implement setters that
won't allow vendor CPU options to be changed.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
Message-ID: <20240105230546.265053-3-dbarb...@vent
From: Rob Bradford
If the B extension is enabled warn if the user has disabled any of the
required extensions that are part of the 'B' extension. Conversely
enable the extensions that make up the 'B' extension if it is enabled.
Signed-off-by: Rob Bradford
Reviewed-by: Daniel Henrique Barboza
R
From: Daniel Henrique Barboza
Every property in riscv_cpu_options[] will be migrated to
riscv_cpu_properties[]. This will make their default values init
earlier, allowing cpu_init() functions to overwrite them. We'll also
implement common getters and setters that both accelerators will use,
allow
From: Daniel Henrique Barboza
user_spec, bext_spec and bext_ver aren't being used.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
Message-ID: <20240105230546.265053-2-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
target/riscv/
From: Daniel Henrique Barboza
Do the same thing we did with 'vlen' in the previous patch with 'elen'.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
Message-ID: <20240105230546.265053-10-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
From: Daniel Henrique Barboza
The same rework did in 'priv_spec' is done for 'vext_spec'. This time is
simpler, since we only accept one value ("v1.0") and we'll always have
env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to
convert string to 'vext_ver' back and forth like we
From: Rob Bradford
Add the infrastructure for the 'B' extension which is the union of the
Zba, Zbb and Zbs instructions.
Signed-off-by: Rob Bradford
Reviewed-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
Reviewed-by: Alistair Francis
Message-ID: <2024061644.33630-2-rbradf...@rivo
From: Alvin Chang
The debug Sdtrig extension defines an CSR "mcontext". This commit
implements its predicate and read/write operations into CSR table.
Its value is reset as 0 when the trigger module is reset.
Signed-off-by: Alvin Chang
Reviewed-by: Alistair Francis
Reviewed-by: Daniel Henrique
From: Daniel Henrique Barboza
Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it
that forbids 'pmp' to be changed in vendor CPUs, like we did with the
'mmu' option.
We'll also have to manually set 'pmp = true' to generic CPUs that were
still relying on the previous default to s
From: Daniel Henrique Barboza
Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'.
We're using 'vlenb' most of the time, having to do 'vlen >> 3' or
'vlen / 8' in every instance.
In hindsight we would be better if the 'vlenb' property was introduced
instead of 'vlen'. That's no
From: Daniel Henrique Barboza
After adding a KVM finalize() implementation, turn cbom_blocksize into a
class property. Follow the same design we used with 'vlen' and 'elen'.
The duplicated 'cbom_blocksize' KVM property can be removed from
kvm_riscv_add_cpu_user_properties().
Signed-off-by: Dani
From: Rob Bradford
Add requirement that 'A' is enabled for all atomic instructions that
lack the check. This makes the 64-bit versions consistent with the
32-bit versions in the same file.
Signed-off-by: Rob Bradford
Reviewed-by: Alistair Francis
Reviewed-by: Daniel Henrique Barboza
Message-I
From: Daniel Henrique Barboza
To turn cbom_blocksize and cboz_blocksize into class properties we need
KVM specific changes.
KVM is creating its own version of these options with a customized
setter() that prevents users from picking an invalid value during init()
time. This comes at the cost of
From: Daniel Henrique Barboza
Use s->cfg_ptr->vlenb instead of s->cfg_ptr->vlen / 8.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-7-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
target/
From: Daniel Henrique Barboza
Use the new 'vlenb' CPU config to validate fractional LMUL. The original
comparison is done with 'vlen' and 'sew', both in bits. Adjust the shift
to use vlenb.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Mes
From: Daniel Henrique Barboza
Use s->cfg_ptr->vlenb instead of "s->cfg_ptr->vlen / 8" and
"s->cfg_ptr->vlen >> 3".
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-6-dbarb...@ventanamicro.com>
Signed-off-by:
From: Akihiko Odaki
misa_mxl_max is common for all instances of a RISC-V CPU class so they
are better put into class.
Signed-off-by: Akihiko Odaki
Reviewed-by: Alistair Francis
Message-ID: <20240203-riscv-v11-2-a23f4848a...@daynix.com>
Signed-off-by: Alistair Francis
---
target/riscv/cpu.h
From: Daniel Henrique Barboza
vregs[] have variable size that depends on the current vlenb set by the
host, meaning we can't use our regular kvm_riscv_reg_id() to retrieve
it.
Create a generic kvm_encode_reg_size_id() helper to encode any given
size in bytes into a given kvm reg id. kvm_riscv_ve
From: Daniel Henrique Barboza
Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from
riscv_cpu_init()") already did some of the work by making some
cpu_init() functions to explictly enable their own 'mmu' default.
The generic CPUs didn't get update by that commit, so they are still
relyi
From: Daniel Henrique Barboza
Calculate the maximum vector size possible, 'max_sz', which is the size
in bytes 'vlenb' multiplied by the max value of LMUL (LMUL = 8, when
s->lmul = 3).
'max_sz' is then shifted right by 'scale', expressed as '3 - s->lmul',
which is clearer than doing 'scale = lmu
From: Daniel Henrique Barboza
Use 'cpu->cfg.vlenb' instead of 'cpu->cfg.vlen >> 3'.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-8-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
target/r
From: Daniel Henrique Barboza
The field isn't big enough to hold an uint64_t kvm register and Vector
registers will end up overflowing it.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Message-ID: <20240123161714.160149-2-dbarb...@ventanamicro.com>
Signed-off-by: Alistai
From: Daniel Henrique Barboza
Rename the existing 'sew' variable to 'vsew' for extra clarity.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-11-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
target/riscv/cpu.h | 11 +
From: Daniel Henrique Barboza
Turning 'vlen' into a class property will allow its default value to be
overwritten by cpu_init() later on, solving the issue we have now where
CPU specific settings are getting overwritten by the default.
Common validation bits are moved from riscv_cpu_validate_v()
From: Daniel Henrique Barboza
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-4-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
target/riscv/gdbstub.c | 6 +++---
1 file changed, 3 insertions
From: Daniel Henrique Barboza
We have a lot of cases where a char or an uint32_t pointer is used once
to alloc a string/array, read/written during the function, and then
g_free() at the end. There's no pointer re-use - a single alloc, a
single g_free().
Use 'g_autofree' to avoid the g_free() cal
From: Daniel Henrique Barboza
'priv_spec' and 'vext_spec' are two string options used as a fancy way
of setting integers in the CPU state (cpu->env.priv_ver and
cpu->env.vext_ver). It requires us to deal with string parsing and to
store them in cpu_cfg.
We must support these string options, but
From: LIU Zhiwei
vxrm and vxsat have been moved into a special register vcsr since
RVV v1.0. So remove them from FCSR for vector 1.0.
Signed-off-by: LIU Zhiwei
Reviewed-by: Daniel Henrique Barboza
Message-ID: <20240130110945.486-1-zhiwei_...@linux.alibaba.com>
Signed-off-by: Alistair Francis
From: Daniel Henrique Barboza
The 'isa' char pointer isn't being freed after use.
Issue detected by Valgrind:
==38752== 128 bytes in 1 blocks are definitely lost in loss record 3,190 of
3,884
==38752==at 0x484280F: malloc (vg_replace_malloc.c:442)
==38752==by 0x5189619: g_malloc (gmem.
From: Daniel Henrique Barboza
As a bonus, we're being more idiomatic using cpu->cfg.vlenb when
reading CSR_VLENB.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-3-dbarb...@ventanamicro.com>
Signed-off-by: A
From: Akihiko Odaki
misa_mxl_max is now a class member and initialized only once for each
class. This also moves the initialization of gdb_core_xml_file which
will be referenced before realization in the future.
Signed-off-by: Akihiko Odaki
Reviewed-by: Alistair Francis
Message-ID: <20240203-r
From: Heinrich Schuchardt
Provide a function to set the default processor family.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Andrew Jones
Message-ID: <20240123184229.10415-3-heinrich.schucha...@canonical.com>
Signed-off-by: Alistair Francis
---
include/hw/firmware/smbios.h | 1 +
hw/smb
From: Conor Dooley
A few months ago I submitted a patch to various lists, deprecating
"riscv,isa" with a lengthy commit message [0] that is now commit
aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux
kernel tree. Primarily, the goal was to replace "riscv,isa" with a new
set o
From: Conor Dooley
A cpu may not have the same xlen as the compile time target, and
misa_mxl_max is the source of truth for what the hart supports.
The conversion from misa_mxl_max to xlen already has one user, so
introduce a helper and use that to populate the isa string.
Link: https://lore.ke
From: Heinrich Schuchardt
For RISC-V the SMBIOS standard requires specific values of the processor
family value depending on the bitness of the CPU.
Add a processor-family option for SMBIOS table 4.
The value of processor-family may exceed 255 and therefore must be provided
in the Processor Fam
From: LIU Zhiwei
According to xtheadsync[1][2] documentation, it can be used in user mode and
the behavior is same with other priviledges.
[1]:https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadsync/sync.adoc
[2]:https://github.com/T-head-Semi/thead-extension-spec/blob/master/
From: Daniel Henrique Barboza
A bare bones 32 bit RVI CPU, rv32i, will make users lives easier when a
full customized 32 bit CPU is desired, and users won't need to disable
defaults by hand as they would with the rv32 CPU. [1] has an example of
a situation that would be avoided with rv32i.
In fa
From: Rob Bradford
Expose the newly added extensions to the guest and allow their control
through the CPU properties.
Signed-off-by: Rob Bradford
Reviewed-by: Daniel Henrique Barboza
Message-ID: <20240123111030.15074-4-rbradf...@rivosinc.com>
Signed-off-by: Alistair Francis
---
target/riscv/
From: Daniel Henrique Barboza
There is no need to keep both 'vlen' and 'vlenb'. All existing code
that requires 'vlen' is retrieving it via 'vlenb << 3'.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-14-db
From: Rob Bradford
Following the pattern for 'M' and Zmmul check if either the 'A'
extension is enabled or the appropriate split extension for the
instruction.
Signed-off-by: Rob Bradford
Reviewed-by: Daniel Henrique Barboza
Message-ID: <20240123111030.15074-3-rbradf...@rivosinc.com>
Signed-of
在 2024/2/9 09:05, Philippe Mathieu-Daudé 写道:
Alternative to:
https://lore.kernel.org/qemu-devel/20240209085347.8446-1-phi...@linaro.org/
If the I6500 can not be tested or its support is incomplete,
there is no point in wasting energy maintaining it.
Actually all SAAR and ITU stuff are option
From: Daniel Henrique Barboza
Move 'soc_name' to the loop, and give it g_autofree, to avoid the manual
g_free().
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Message-ID: <2024011529.86562-7-dbarb...@ventanamicro.com>
Signed-off-b
From: Akihiko Odaki
It is initialized with a simple assignment and there is little room for
error. In fact, the validation is even more complex.
Signed-off-by: Akihiko Odaki
Acked-by: LIU Zhiwei
Reviewed-by: Daniel Henrique Barboza
Acked-by: Alistair Francis
Message-ID: <20240203-riscv-v11-1
From: Daniel Henrique Barboza
Use ctx->cfg_ptr->vlenb instead of ctx->cfg_ptr->vlen / 8.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-5-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
tar
From: Daniel Henrique Barboza
The array is empty and can be removed.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-6-dbarb...@ventanamicro.com
From: Daniel Henrique Barboza
Move 'clust_name' inside the loop, and g_autofree, to avoid having to
g_free() manually in each loop iteration.
'intc_phandles' is also g_autofreed to avoid another manual g_free().
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Message-ID:
From: Daniel Henrique Barboza
Next patch will add more bare CPUs. Their cpu_init() functions would be
glorified copy/pastes of rv64i_bare_cpu_init(), differing only by a
riscv_cpu_set_misa() call.
Add a new .instance_init for the TYPE_RISCV_BARE_CPU typ to avoid this
code repetition. While we're
From: Daniel Henrique Barboza
Keep all class properties in riscv_cpu_properties[].
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-9-dbarb...@ve
From: Daniel Henrique Barboza
Use g_autofree in 'dist_matrix' to avoid the manual g_free().
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Message-ID: <2024011529.86562-3-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
hw/riscv/numa.c | 4 ++--
1 file
From: Daniel Henrique Barboza
KVM will check for the correct 'reg_size' when accessing the vector
registers, erroring with EINVAL if we encode the wrong size in reg ID.
Vector registers varies in size with the vector length in bytes, or
'vlenb'. This means that we need the current 'vlenb' being u
From: Daniel Henrique Barboza
And remove the now unused kvm_cpu_set_cbomz_blksize() setter.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-5-db
From: Daniel Henrique Barboza
Do the same we did with 'cbom_blocksize' in the previous patch.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-4-
From: Daniel Henrique Barboza
Put 'name' declaration inside the loop, with g_autofree, to avoid
manually doing g_free() in each iteration.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Message-ID: <2024011529.86562-6-dbarb...@vent
From: Daniel Henrique Barboza
Move all char pointers to the loop. Use g_autofree in all of them to
avoid the g_free() calls.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Message-ID: <2024011529.86562-4-dbarb...@ventanamicro.com>
From: Daniel Henrique Barboza
Use the helper instead of calculating vlmax by hand.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Message-ID: <20240122161107.26737-13-dbarb...@ventanamicro.com>
Signed-off-by: Alistair Francis
---
target/riscv/insn_trans/trans_rvv.c.inc
From: Daniel Henrique Barboza
We'll re-use the logic froim vext_get_vlmax() in 2 other occurrences in
the next patch, but first we need to make it independent of both 'cpu'
and 'vtype'. To do that, add 'vlenb', 'vsew' and 'lmul' as parameters
instead.
Adapt the two existing callers. In cpu_get_t
From: Heinrich Schuchardt
With SMBIOS support added for RISC-V we also should enable the command line
option.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Daniel Henrique Barboza
Acked-by: Alistair Francis
Reviewed-by: Andrew Jones
Message-ID: <20240123184229.10415-5-heinrich.schucha...@c
From: LIU Zhiwei
The real return value type has been converted to RISCVException,
but some function declarations still not. This patch makes all
csr operation declarations use RISCVExcetion.
Signed-off-by: LIU Zhiwei
Reviewed-by: Alistair Francis
Reviewed-by: Daniel Henrique Barboza
Message-I
From: Heinrich Schuchardt
Generate SMBIOS tables for the RISC-V mach-virt.
Add CONFIG_SMBIOS=y to the RISC-V default config.
Set the default processor family in the type 4 table.
The implementation is based on the corresponding ARM and Loongson code.
With the patch the following firmware tables
From: Daniel Henrique Barboza
Keep all class properties in riscv_cpu_properties[].
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-8-dbarb...@ve
From: Rob Bradford
These extensions represent the atomic operations from A (Zaamo) and the
Load-Reserved/Store-Conditional operations from A (Zalrsc)
Signed-off-by: Rob Bradford
Reviewed-by: Daniel Henrique Barboza
Message-ID: <20240123111030.15074-2-rbradf...@rivosinc.com>
Signed-off-by: Alis
From: Daniel Henrique Barboza
Keep all class properties in riscv_cpu_properties[].
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Tested-by: Vladimir Isaev
tested-by tags added, rebased with Alistair's riscv-to-apply.next.
Message-ID: <20240112140201.127083-7-dbarb...@ve
On Wed, 7 Feb 2024 at 21:57, Kevin Wolf wrote:
>
> The following changes since commit 39a6e4f87e7b75a45b08d6dc8b8b7c2954c87440:
>
> Merge tag 'pull-qapi-2024-02-03' of https://repo.or.cz/qemu/armbru into
> staging (2024-02-03 13:31:58 +)
>
> are available in the Git repository at:
>
> htt
On Thu, 8 Feb 2024 at 18:13, Philippe Mathieu-Daudé wrote:
>
> "qemu/units.h" is not used in the "hw/rx/rx62n.h"
> header, include it in the source where it is.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Maydell
thanks
-- PMM
On Thu, 8 Feb 2024 at 18:13, Philippe Mathieu-Daudé wrote:
>
> QEMU coding style recommend using structure typedefs:
> https://www.qemu.org/docs/master/devel/style.html#typedefs
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Thu, 8 Feb 2024 at 18:14, Philippe Mathieu-Daudé wrote:
>
> Instead of filling an array of all the possible IRQs, only call
> qdev_get_gpio_in() when an IRQ is used. Remove the array from
> RX62NState. Doing so we avoid calling qdev_get_gpio_in() on an
> unrealized device.
>
> Signed-off-by: Ph
On Thu, 8 Feb 2024 at 18:14, Philippe Mathieu-Daudé wrote:
>
> We should not wire IRQs on unrealized device.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Maydell
thanks
-- PMM
On Thu, 8 Feb 2024 at 18:14, Philippe Mathieu-Daudé wrote:
>
> We should not wire IRQs on unrealized device.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sh4/r2d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Peter Maydell
thanks
-- PMM
On Thu, 8 Feb 2024 at 18:14, Philippe Mathieu-Daudé wrote:
>
> Inline cpu_create() in order to call
> qdev_init_gpio_in_named_with_opaque()
> before the CPU is realized.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sparc64/sparc64.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion
On Thu, 8 Feb 2024 at 18:14, Philippe Mathieu-Daudé wrote:
>
> Inline cpu_create() in order to call
> qdev_init_gpio_in_named_with_opaque()
> before the CPU is realized.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sparc/leon3.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions
On Thu, 8 Feb 2024 at 18:14, Philippe Mathieu-Daudé wrote:
>
> We should not wire IRQs on unrealized device.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/sparc/sun4m.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
> in
1 - 100 of 248 matches
Mail list logo
