On Mon, 26 Aug 2024 08:31, Junjie Mao wrote:
+unsafe impl GlobalAlloc for QemuAllocator {
+unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
+if layout.align() == 0 {
+g_malloc0(layout.size().try_into().unwrap()).cast::()
+} else {
+g_aligned_alloc0(
On Mon, 26 Aug 2024 08:03, Junjie Mao wrote:
Hi Manos,
On 8/23/2024 4:11 PM, Manos Pitsidianakis wrote:
Add rust/qemu-api, which exposes rust-bindgen generated FFI bindings and
provides some declaration macros for symbols visible to the rest of
QEMU.
Co-authored-by: Junjie Mao
Co-authored-by
On 23/8/24 19:39, Fabiano Rosas wrote:
Prior to moving the ram code into multifd-nocomp.c, change the code to
register the nocomp ops dynamically so we don't need to have the ops
structure defined in multifd.c.
While here, move the ops struct initialization to the end of the file
to make the nex
On 23/8/24 19:39, Fabiano Rosas wrote:
While we cannot yet disentangle the multifd packet from page data, we
can make the code a bit cleaner by setting the page-related fields in
a separate function.
Signed-off-by: Fabiano Rosas
---
migration/multifd.c| 99 +---
On Tue, Aug 20, 2024 at 6:36 PM Philippe Mathieu-Daudé
wrote:
>
> On 20/8/24 11:51, CLEMENT MATHIEU--DRIF wrote:
> > Signed-off-by: Clément Mathieu--Drif
> > ---
> > MAINTAINERS | 1 +
> > 1 file changed, 1 insertion(+)
>
> Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Jason Wang
Thanks
>
Hi Gustavo,
On 25/8/24 16:52, Gustavo Romero wrote:
Extend MTE gdbstub tests to also run in system mode (share tests between
user mode and system mode). The tests will only run if a version of GDB
that supports MTE on baremetal is available in the test environment and
if available compiler suppo
Hello Junjie,
On Mon, 26 Aug 2024 08:15, Junjie Mao wrote:
On 8/23/2024 4:11 PM, Manos Pitsidianakis wrote:
This commit adds a helper crate library, qemu-api-macros for derive (and
other procedural) macros to be used along qemu-api.
It needs to be a separate library because in Rust, procedura
On 8/23/2024 4:11 PM, Manos Pitsidianakis wrote:
Add rust/qemu-api, which exposes rust-bindgen generated FFI bindings and
provides some declaration macros for symbols visible to the rest of
QEMU.
Co-authored-by: Junjie Mao
Co-authored-by: Paolo Bonzini
Signed-off-by: Junjie Mao
Signed-off-by:
On 8/23/2024 4:11 PM, Manos Pitsidianakis wrote:
This commit adds a helper crate library, qemu-api-macros for derive (and
other procedural) macros to be used along qemu-api.
It needs to be a separate library because in Rust, procedural macros, or
macros that can generate arbitrary code, need to
Hi Manos,
On 8/23/2024 4:11 PM, Manos Pitsidianakis wrote:
Add rust/qemu-api, which exposes rust-bindgen generated FFI bindings and
provides some declaration macros for symbols visible to the rest of
QEMU.
Co-authored-by: Junjie Mao
Co-authored-by: Paolo Bonzini
Signed-off-by: Junjie Mao
Sig
> -Original Message-
> From: Sunil V L
> Sent: Friday, August 23, 2024 9:20 PM
> To: JeeHeng Sia
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; qemu-ri...@nongnu.org;
> m...@redhat.com; imamm...@redhat.com;
> anisi...@redhat.com; peter.mayd...@linaro.org; shannon.zha...@gmail.com;
> -Original Message-
> From: Sunil V L
> Sent: Friday, August 23, 2024 9:15 PM
> To: JeeHeng Sia
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; qemu-ri...@nongnu.org;
> m...@redhat.com; imamm...@redhat.com;
> anisi...@redhat.com; peter.mayd...@linaro.org; shannon.zha...@gmail.com;
Em Sun, 25 Aug 2024 12:34:14 +0100
Peter Maydell escreveu:
> On Sun, 25 Aug 2024 at 04:46, Mauro Carvalho Chehab
> wrote:
> >
> > Accurately injecting an ARM Processor error ACPI/APEI GHES
> > error record requires the value of the ARM Multiprocessor
> > Affinity Register (mpidr).
> >
> > While
According to RISC-V Debug specification, the optional textra32 and textra64
trigger CSRs can be used to configure additional matching conditions for the
triggers.
This series support to write MHVALUE and MHSELECT fields into textra32 and
textra64 trigger CSRs. Besides, the additional matching cond
This commit allows program to write textra trigger CSR for type 2, 3, 6
triggers. In this preliminary patch, the textra.MHVALUE and the
textra.MHSELECT fields are allowed to be configured. Other fields, such
as textra.SBYTEMASK, textra.SVALUE, and textra.SSELECT, are hardwired to
zero for now.
For
According to RISC-V Debug specification, the optional textra32 and
textra64 trigger CSRs can be used to configure additional matching
conditions for the triggers. For example, if the textra.MHSELECT field
is set to 4 (mcontext), this trigger will only match or fire if the low
bits of mcontext/hcont
I'd like to *PING* this patch once again. Please review this patch. If
there is anything missing or ambiguous in the patch, please let me know.
Thanks,
Zero Tang
On Sun, Aug 18, 2024 at 1:30 AM Zero Tang wrote:
> Hello,
>
> I'd like to ping this patch in that the QEMU-PCILeech plugin is now mer
On Wed, Aug 21, 2024 at 5:51 PM Andrew Jones wrote:
>
> Just as the hart bit setting of the AIA should be calculated as
> ceil(log2(max_hart_id + 1)) the group bit setting should be
> calculated as ceil(log2(max_group_id + 1)). The hart bits are
> implemented by passing max_hart_id to find_last_bi
On Fri, Aug 23, 2024 at 9:33 PM Sia Jee Heng
wrote:
>
> Signed-off-by: Sia Jee Heng
Acked-by: Alistair Francis
Alistair
> ---
> tests/qtest/bios-tables-test-allowed-diff.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
> b/tests/qtest/bi
On Tue, Aug 20, 2024 at 2:00 PM Alvin Che-Chia Chang(張哲嘉)
wrote:
>
> Hi Alistair,
>
> > -Original Message-
> > From: Alvin Che-Chia Chang(張哲嘉)
> > Sent: Sunday, July 21, 2024 3:24 PM
> > To: qemu-ri...@nongnu.org; qemu-devel@nongnu.org
> > Cc: alistair.fran...@wdc.com; bin.m...@windriver.
On Fri, Aug 23, 2024 at 10:32 AM Alistair Francis wrote:
>
> The OpenTitan Ibex CPU now supports the the Zba, Zbb, Zbc
> and Zbs bit-manipulation sub-extensions ratified in
> v.1.0.0 of the RISC-V Bit- Manipulation ISA Extension, so let's enable
> them in QEMU as well.
>
> 1: https://github.com/lo
On Fri, Aug 23, 2024 at 4:39 PM Vladimir Isaev
wrote:
>
> za64rs requires priv 1.12 when enabled by priv 1.11.
>
> This fixes annoying warning:
> warning: disabling za64rs extension for hart 0x because privilege
> spec version does not match
>
> on priv 1.11 CPUs.
>
> Fixes: 68c9e54beae8
On Sun, Aug 25, 2024 at 3:34 AM Daniel Henrique Barboza
wrote:
>
> Gitlab issue [1] reports a misleading error when trying to run a 'rv64'
> cpu with 'zfinx' and without 'f':
>
> $ ./build/qemu-system-riscv64 -nographic -M virt -cpu rv64,zfinx=true,f=false
> qemu-system-riscv64: Zfinx cannot be su
On Fri, Aug 23, 2024 at 4:39 PM Vladimir Isaev
wrote:
>
> za64rs requires priv 1.12 when enabled by priv 1.11.
>
> This fixes annoying warning:
> warning: disabling za64rs extension for hart 0x because privilege
> spec version does not match
>
> on priv 1.11 CPUs.
>
> Fixes: 68c9e54beae8
On Sun, Aug 25, 2024 at 3:34 AM Daniel Henrique Barboza
wrote:
>
> Gitlab issue [1] reports a misleading error when trying to run a 'rv64'
> cpu with 'zfinx' and without 'f':
>
> $ ./build/qemu-system-riscv64 -nographic -M virt -cpu rv64,zfinx=true,f=false
> qemu-system-riscv64: Zfinx cannot be su
On Fri, Aug 23, 2024 at 2:22 AM Peter Maydell wrote:
>
> The TYPE_XLNX_VERSAL_EFUSE_CTRL device creates a register block with
> register_init_block32() in its instance_init method; we must
> therefore destroy it in our instance_finalize method to avoid a leak
> in the QOM introspection "init-inspe
On Fri, Aug 23, 2024 at 2:22 AM Peter Maydell wrote:
>
> The TYPE_XLNX_VERSAL_TRNG device creates a register block with
> register_init_block32() in its instance_init method; we must
> therefore destroy it in our instance_finalize method to avoid a leak
> in the QOM introspection "init-inspect-fin
On Fri, Aug 23, 2024 at 2:23 AM Peter Maydell wrote:
>
> The TYPE_XLNX_ZYNQMP_EFUSE device creates a register block with
> register_init_block32() in its instance_init method; we must
> therefore destroy it in our instance_finalize method to avoid a leak
> in the QOM introspection "init-inspect-fi
On Fri, Aug 23, 2024 at 2:22 AM Peter Maydell wrote:
>
> The TYPE_XLNX_BBRAM device creates a register block with
> register_init_block32() in its instance_init method; we must
> therefore destroy it in our instance_finalize method to avoid a leak
> in the QOM introspection "init-inspect-finalize"
Thank you for your contribution.
Reviewed-by: Jeuk Kim
On 8/22/2024 5:08 PM, Yoochan Jeong wrote:
Previously, it was only able to test virtual UFS devices if they properly
read and write storage data. In this patch, three test functions are added
to test if virtual UFS devices properly read a
On Fri, Aug 23, 2024 at 2:22 AM Peter Maydell wrote:
>
> The TYPE_XLNX_VERSAL_TRNG device creates s->prng with g_rand_new()
> in its init method, but it frees it in its unrealize method. This
> results in a leak in the QOM introspection "initialize-inspect-finalize"
> lifecycle:
>
> Direct leak of
On Fri, Aug 23, 2024 at 2:22 AM Peter Maydell wrote:
>
> Since the TYPE_XNLX_VERSAL_CFU_FDRO device creates a FIFO in its
> instance_init method, we must destroy the FIFO in instance_finalize
> to avoid a memory leak for the QOM introspection
> "instantiate-examine-finalize" cycle:
>
> Direct leak
On 8/24/24 05:01, Deepak Gupta wrote:
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 12484ca7d2..9f08a67a9e 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1761,6 +1761,8 @@ void riscv_cpu_do_interrupt(CPUState *cs)
cs->watchp
Hi Peter and Pavel,
On 8/25/2024 10:30 AM, Peter Maydell wrote:
> We're currently still in codefreeze for the upcoming 9.1 release,
> so I would recommend sending a v2 with the extra patches. Nothing
> except critical bugfixes is going to be applied upstream for
> the next week or two.
Thanks, t
On Sat, 24 Aug 2024 at 02:55, Doug Brown wrote:
> Now, all of these patches are reviewed but there are a few other issues
> we talked about here (dlc2len/len2dlc and issues with the flags), and I
> also found a FIFO issue. Would it make the most sense for me to submit a
> V2 of this series with a
Hello,
> Is this a type of migration that you have attempted before and it used
> to work? Or is this the first time you're using the mirror job for live
> migration?
We have been using live migration for a quite some time (about 5 years) and
this issue has been present for many years.
It is no
Hello Doug
On Saturday 24 of August 2024 03:54:00 Doug Brown wrote:
> Thank you for reviewing all of my patches, Francisco.
>
> Now, all of these patches are reviewed but there are a few other issues
> we talked about here (dlc2len/len2dlc and issues with the flags), and I
> also found a FIFO issu
Extend MTE gdbstub tests to also run in system mode (share tests between
user mode and system mode). The tests will only run if a version of GDB
that supports MTE on baremetal is available in the test environment and
if available compiler supports the 'memtag' flag
(-march=armv8.5-a+memtag).
For t
Use cpu_mmu_index() to determine the specific translation regime (MMU
index) before probing addresses using allocation_tag_mem_probe().
Currently, the MMU index is hardcoded to 0 and only works for user mode.
By obtaining the specific MMU index according to the translation regime,
future use of th
This commit adds support for passing arguments to the GDB test scripts
so it's possible to parse the args in an "argparse way" in the test
scripts launched by the runner. The arguments should be preceded by --
when passed to the runner. For example, passing "--help" arg to the
GDB_TEST_SCRIPT:
run
This patchset makes handle_q_memtag, handle_q_isaddresstagged, and
handle_Q_memtag stubs build for system mode, allowing all GDB
'memory-tag' subcommands to work with QEMU gdbstub on aarch64 system
mode.
It also extends the MTE gdbstub tests to run in system mode, sharing the
tests between QEMU us
This commit makes handle_q_memtag, handle_q_isaddresstagged, and
handle_Q_memtag stubs build for system mode, allowing all GDB
'memory-tag' subcommands to work with QEMU gdbstub on aarch64 system
mode.
Signed-off-by: Gustavo Romero
Reviewed-by: Richard Henderson
---
target/arm/gdbstub64.c | 4 +
On Sun, 25 Aug 2024 at 12:35, Jason A. Donenfeld wrote:
>
> On Fri, Aug 23, 2024 at 07:28:43AM +0100, Stafford Horne wrote:
> > Also, I will wait to see if Jason has anything to say.
>
> So long as this doesn't change the assignment of the serial ports to
> device nodes in Linux, I don't think thi
On 8/23/24 16:42, Philippe Mathieu-Daudé wrote:
static void sbsa_fdt_add_gic_node(SBSAMachineState *sms)
{
- char *nodename;
+ const char *intc_nodename = "/intc";
+ const char *its_nodename = "/intc/its";
Should we use static qualifiers?'
No. The real object is the string liter
On Fri, Aug 23, 2024 at 07:28:43AM +0100, Stafford Horne wrote:
> Also, I will wait to see if Jason has anything to say.
So long as this doesn't change the assignment of the serial ports to
device nodes in Linux, I don't think this should interfere with much.
You might want to try it, though.
Jas
On Sun, 25 Aug 2024 at 04:46, Mauro Carvalho Chehab
wrote:
>
> Accurately injecting an ARM Processor error ACPI/APEI GHES
> error record requires the value of the ARM Multiprocessor
> Affinity Register (mpidr).
>
> While ARM implements it, this is currently not visible.
>
> Add a field at CPU stor
When using the mailbox command get scan media results, the scan media
restart physical address field in the ouput palyload is not 64-byte
aligned.
This patch removed the error source of the restart physical address.
The Scan Media Restart Physical Address is the location from which the
host s
47 matches
Mail list logo
