On 8/15/24 01:36, Pierrick Bouvier wrote:
Found on debian stable.
../contrib/plugins/execlog.c: In function ‘vcpu_tb_trans’:
../contrib/plugins/execlog.c:236:22: error: declaration of ‘n’ shadows a
previous local [-Werror=shadow=local]
236 | for (int n = 0; n < all_reg_names->len
On 2024-08-16 12:53, Stefano Stabellini wrote:
On Fri, 16 Aug 2024, Edgar E. Iglesias wrote:
On Thu, Aug 15, 2024 at 2:30 AM Stefano Stabellini
wrote:
On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> On Tue, Aug 13, 2024 at 03:52:32PM -0700, Stefano Stabellini wrote:
> > On
When riscv_load_firmware() loads an ELF, the ELF segment addresses are
used, not the passed-in firmware_load_addr. The machine models assume
the firmware entry point is what they provided for firmware_load_addr,
and use that address to generate the boot ROM, so if the ELF is linked
at any other add
Peter, thought I’d send this little snippet before getting the rest of V2 done
in case anyone hates this :). I tried to take a similar approach to kvm_type,
but I’m not sure if this will be looked upon favorably so want an early
opinion. The nice thing about kvm_type is at least it has differing
On 8/17/24 09:48, Carl Hauser wrote:
netbsd panics in the kernel trap handler; unfortunately it does not include the fsr in the
panic message, but I expect it will be the same as on Solaris.
Ok, I have reproduced this with netbsd 9.3.
I'll have a look.
r~
On 8/17/24 08:58, Carl Hauser wrote:
Yes, but ...
isn't the state of dc->fsr_qne at translation time irrelevant?
No, because patch 4 made it part of the hashed TB state.
It's checked and verified, generating a new TB if state does not match.
And changing it at
translation time (line 4593) is
Further info:
netbsd panics in the kernel trap handler; unfortunately it does
not include the fsr in the panic message, but I expect it will be
the same as on Solaris.
linux raises SIGFPE in the application that caused the exception.
Not surprising since
Yes, but ...
isn't the state of dc->fsr_qne at translation time irrelevant?
And changing it at translation time (line 4593) is dangerous
(because it pertains to runtime, not translation time); i.e. why
is 0 stored at both translation time (4593) and at runtime (459
Hi Richard,
I applied the 6 patches and then ran a divide-by-zero test on the
Solaris image. The result was a crash
(qemu) qemu:
fatal: Trap 0x08 (FPU Exception) while interrupts disabled,
Error state
pc: f0066d80 npc: f0066d84
On 8/17/24 01:42, Pierrick Bouvier wrote:
User mode uses a shared code cache while system mode uses a code cache per vcpu (thus,
translation can happen concurrently).
Not 100% accurate. The system mode code cache is global, but is partitioned so that each
partition has a different lock, so th
On 8/17/24 07:46, Carl Hauser wrote:
OK, I think the problem is the handling of dc->fsr_qne in trans_STDFQ, lines 4583 and 4593
-- the code is evaluating dc->fsr_qne at translation time and not at runtime.
That's what patch 4 does, ensure that the runtime value is available at
translation time
On 8/16/24 22:47, Alex Bennée wrote:
No, not a bug. This is a host addr, right there in the name.
Returning uint64_t would be a bug.
No it's:
* Returns: hardware (physical) target address of instruction
I was kinda assuming that was what the underlying host_addr[] fields in
DisasContextDB
OK, I think the problem is the handling of dc->fsr_qne in
trans_STDFQ, lines 4583 and 4593 -- the code is evaluating
dc->fsr_qne at translation time and not at runtime.
On 8/16/24 14:19, Carl Hauser wrote:
Hi Richard,
I applied the 6 pa
Long due upgrade, see [1]:
In GitLab Runner 13.2 a translation for step_script to
build_script was added to the custom executor. In 14.0
the build_script stage will be replaced with step_script.
We are using GitLab 17 [2]!
This removes the following warning:
WARNING: Starting with versi
> -Original Message-
> From: Brian Cain
> Sent: Friday, August 16, 2024 1:06 PM
> To: qemu-devel@nongnu.org
> Cc: bc...@quicinc.com; quic_mathb...@quicinc.com;
> sidn...@quicinc.com; quic_mlie...@quicinc.com;
> ltaylorsimp...@gmail.com
> Subject: [PATCH 3/3] target/hexagon: add enums fo
> -Original Message-
> From: Brian Cain
> Sent: Friday, August 16, 2024 1:06 PM
> To: qemu-devel@nongnu.org
> Cc: bc...@quicinc.com; quic_mathb...@quicinc.com;
> sidn...@quicinc.com; quic_mlie...@quicinc.com;
> ltaylorsimp...@gmail.com; Laurent Vivier
> Subject: [PATCH 1/3] target/hexa
> -Original Message-
> From: Brian Cain
> Sent: Friday, August 16, 2024 1:06 PM
> To: qemu-devel@nongnu.org
> Cc: bc...@quicinc.com; quic_mathb...@quicinc.com;
> sidn...@quicinc.com; quic_mlie...@quicinc.com;
> ltaylorsimp...@gmail.com
> Subject: [PATCH 2/3] target/hexagon: rename
> HEX
The value previously used for "HEX_EVENT_TRAP0" was the cause code
definition and not the event number. So in this commit, we update
the name to reflect the cause code and add a new "HEX_EVENT_TRAP0"
with the correct event number.
Signed-off-by: Brian Cain
---
target/hexagon/cpu_bits.h | 3 ++-
Change the name of these definitions to reflect that they correspond
to the event code for the exception.
Signed-off-by: Brian Cain
---
linux-user/hexagon/cpu_loop.c | 4 ++--
target/hexagon/cpu.h | 2 +-
target/hexagon/cpu_bits.h | 14 +++---
target/hexagon/gen_tcg.h
Signed-off-by: Brian Cain
---
target/hexagon/cpu_bits.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/target/hexagon/cpu_bits.h b/target/hexagon/cpu_bits.h
index eec456d8f9..2454ef72bf 100644
--- a/target/hexagon/cpu_bits.h
+++ b/target/hexagon/cpu_bi
I don't have strong opinion in the end, I'm just looking for building
contrib plugins like the rest of the codebase, to reduce maintenance burden.
Initially, when this idea was implemented, it was suggested by Alex to
remove the Makefile [1].
Now it seems to be suggested to keep it as an exampl
On 8/16/2024 11:59 AM, Peter Xu wrote:
On Fri, Aug 16, 2024 at 04:36:58PM +0100, Daniel P. Berrangé wrote:
On Fri, Aug 16, 2024 at 11:23:01AM -0400, Peter Xu wrote:
On Fri, Aug 16, 2024 at 11:13:36AM -0400, Steven Sistare wrote:
On 8/15/2024 4:28 PM, Peter Xu wrote:
On Sat, Jul 20, 2024 at 04
The interrupt level should be 0 or 1. The existing code was using the
interrupt flags to determine the level. In the only machine currently
supported (xlnx-versal-virt), the GICv3 was masking off all bits except
bit 0 when applying it, resulting in the IRQ never being delivered.
Signed-off-by: Dou
There was no case for handling received CAN FD frames with a DLC of 0-8.
This was already handled properly with TX. Add similar code for RX.
Signed-off-by: Doug Brown
---
hw/net/can/xlnx-versal-canfd.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/hw/net/can/x
This series fixes several problems I ran into while trying to simulate
the AMD/Xilinx Versal CANFD controller in the xlnx-versal-virt machine
using Xilinx's v6.6_LTS_2024.1 kernel. With all of these patches
applied, everything works correctly alongside actual CAN devices.
- IRQs were accidentally
When checking the QEMU_CAN_FRMF_TYPE_FD flag, we need to ignore other
potentially set flags. Before this change, received CAN FD frames from
SocketCAN weren't being recognized as CAN FD.
Signed-off-by: Doug Brown
---
hw/net/can/xlnx-versal-canfd.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
Previously the emulated CAN ID register was being set to the exact same
value stored in qemu_can_frame.can_id. This doesn't work correctly
because the Xilinx IP core uses a different bit arrangement than
qemu_can_frame for all of its ID registers. Correct this problem for
both RX and TX, including
The endianness of the CAN data was backwards in each group of 4 bytes.
For example, the following data:
00 11 22 33 44 55 66 77
was showing up like this:
33 22 11 00 77 66 55 44
Fix both the TX and RX code to put the data in the correct order.
Signed-off-by: Doug Brown
---
hw/net/can/xlnx-ve
Signed-off-by: Elisha Hollander
---
accel/tcg/cpu-exec.c | 4 +---
accel/tcg/icount-common.c | 4 ++--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 8163295f34..4c2baf8ed4 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu
On 8/16/2024 1:57 PM, Fabiano Rosas wrote:
Steve Sistare writes:
Remember the RAMBlock host address as host_old during migration, for use
by CPR. The iommufd interface to update the virtual address of DMA
mappings requires it.
Signed-off-by: Steve Sistare
---
hw/core/machine.c | 6 +
Steve Sistare writes:
> Remember the RAMBlock host address as host_old during migration, for use
> by CPR. The iommufd interface to update the virtual address of DMA
> mappings requires it.
>
> Signed-off-by: Steve Sistare
> ---
> hw/core/machine.c | 6 ++
> include/exec/ramblock.h |
On 8/16/24 00:45, Philippe Mathieu-Daudé wrote:
On 16/8/24 09:22, Thomas Huth wrote:
From: Pierrick Bouvier
Found on debian stable.
../target/s390x/tcg/translate.c: In function ‘get_mem_index’:
../target/s390x/tcg/translate.c:398:1: error: control reaches end of non-void
function [-Werror=re
On 8/16/24 03:59, Philippe Mathieu-Daudé wrote:
On 15/8/24 00:41, Pierrick Bouvier wrote:
Found on debian stable.
../target/i386/kvm/kvm.c: In function ‘kvm_handle_rdmsr’:
../target/i386/kvm/kvm.c:5345:1: error: control reaches end of non-void
function [-Werror=return-type]
5345 | }
Yichen Wang writes:
> From: Bryan Zhang
>
> Adds support for 'qatzip' as an option for the multifd compression
> method parameter, and implements using QAT for 'qatzip' compression and
> decompression.
>
> Signed-off-by: Bryan Zhang
> Signed-off-by: Hao Xiang
> Signed-off-by: Yichen Wang
> Ac
On 16/8/24 19:18, Philippe Mathieu-Daudé wrote:
On 16/8/24 18:40, Thomas Huth wrote:
On 16/08/2024 18.34, Philippe Mathieu-Daudé wrote:
On 16/8/24 17:37, Thomas Huth wrote:
The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
likely due to some changes in the MSYS2 environmen
Yichen Wang writes:
> From: Bryan Zhang
>
> Adds support for migration parameters to control QATzip compression
> level and to enable/disable software fallback when QAT hardware is
> unavailable. This is a preparatory commit for a subsequent commit that
> will actually use QATzip compression.
>
Yichen Wang writes:
> From: Bryan Zhang
>
> Add a 'qatzip' feature, which is automatically disabled, and which
> depends on the QATzip library if enabled.
>
> Signed-off-by: Bryan Zhang
> Signed-off-by: Hao Xiang
> Signed-off-by: Yichen Wang
Reviewed-by: Fabiano Rosas
On 16/8/24 18:40, Thomas Huth wrote:
On 16/08/2024 18.34, Philippe Mathieu-Daudé wrote:
On 16/8/24 17:37, Thomas Huth wrote:
The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
likely due to some changes in the MSYS2 environment. So far nobody has
neither a clue what's going
Yichen Wang writes:
> From: Yuan Liu
>
> add Intel QATzip compression method introduction
>
> Signed-off-by: Yuan Liu
> Reviewed-by: Nanhai Zou
> Reviewed-by: Peter Xu
> Reviewed-by: Yichen Wang
> ---
> docs/devel/migration/features.rst | 1 +
> docs/devel/migration/qatzip-compr
From: Mark Corbin
Introduced RISC-V specific ELF definitions and hardware capability
detection.
Additionally, a function to retrieve hardware capabilities
('get_elf_hwcap') is implemented, which returns the common bits set in
each CPU's ISA strings.
Signed-off-by: Mark Corbin
Signed-off-by: Aje
From: Mark Corbin
Added definitions for RISC-V VM parameters, including maximum and
default sizes for text, data, and stack, as well as address space
limits.
Implemented helper functions for retrieving and setting specific
values in the CPU state, such as stack pointer and return values.
Signed-
From: Mark Corbin
Added functions for cloning CPU registers and resetting the CPU state
for RISC-V architecture.
Signed-off-by: Mark Corbin
Signed-off-by: Ajeet Singh
Reviewed-by: Richard Henderson
---
bsd-user/riscv/target_arch_cpu.h | 14 ++
1 file changed, 14 insertions(+)
di
From: Mark Corbin
Added definitions for RISC-V signal handling, including structures
and constants for managing signal frames and context
Signed-off-by: Mark Corbin
Signed-off-by: Ajeet Singh
Co-authored-by: Warner Losh
Reviewed-by: Richard Henderson
---
bsd-user/riscv/target_arch_signal.h
From: Mark Corbin
Implemented functions for setting up and initializing threads in the
RISC-V architecture.
The 'target_thread_set_upcall' function sets up the stack pointer,
program counter, and function argument for new threads.
The 'target_thread_init' function initializes thread registers bas
From: Mark Corbin
Added implementations for 'set_mcontext' and 'get_ucontext_sigreturn'
functions for RISC-V architecture,
Both functions ensure that the CPU state and user context are properly
managed.
Signed-off-by: Mark Corbin
Signed-off-by: Warner Losh
Signed-off-by: Ajeet Singh
Co-author
From: Mark Corbin
Included the prototype for the 'target_cpu_set_tls' function in the
'target_arch.h' header file. This function is responsible for setting
the Thread Local Storage (TLS) register for RISC-V architecture.
Signed-off-by: Mark Corbin
Signed-off-by: Ajeet Singh
Reviewed-by: Richar
From: Mark Corbin
Implemented the `setup_sigtramp` function for setting up the signal
trampoline code in the RISC-V architecture.
Signed-off-by: Mark Corbin
Signed-off-by: Ajeet Singh
Reviewed-by: Richard Henderson
---
bsd-user/riscv/target_arch_sigtramp.h | 46 +++
1
From: Mark Corbin
Introduced definitions for the RISC-V system call interface, including
the 'target_pt_regs' structure that outlines the register storage
layout during a system call.
Added constants for hardware machine identifiers.
Signed-off-by: Mark Corbin
Signed-off-by: Ajeet Singh
Co-aut
From: Mark Corbin
Added functions for setting up the RISC-V signal trampoline and signal
frame:
'set_sigtramp_args()': Configures the RISC-V CPU state with arguments
for the signal handler. It sets up the registers with the signal
number,pointers to the signal info and user context, the signal h
From: Mark Corbin
Added definitions for RISC-V register structures, including
general-purpose registers and floating-point registers, in
'target_arch_reg.h'. Implemented the 'target_copy_regs' function to
copy register values from the CPU state to the target register
structure, ensuring proper en
From: Mark Corbin
Added the 'do_freebsd_arch_sysarch' function to emulate the 'sysarch'
system call for the RISC-V architecture.
Currently, this function returns '-TARGET_EOPNOTSUPP' to indicate that
the operation is not supported.
Signed-off-by: Mark Corbin
Signed-off-by: Ajeet Singh
Reviewed
From: Warner Losh
Added configuration for RISC-V 64-bit target to the build system.
Signed-off-by: Warner Losh
Signed-off-by: Ajeet Singh
Reviewed-by: Richard Henderson
---
configs/targets/riscv64-bsd-user.mak | 4
1 file changed, 4 insertions(+)
create mode 100644 configs/targets/risc
From: Mark Corbin
Added the 'get_mcontext' function to extract and populate
the RISC-V machine context from the CPU state.
This function is used to gather the current state of the
general-purpose registers and store it in a 'target_mcontext_'
structure.
Signed-off-by: Mark Corbin
Signed-off-by:
From: Mark Corbin
Added the initial implementation for RISC-V CPU initialization and main
loop. This includes setting up the general-purpose registers and
program counter based on the provided target architecture definitions.
Signed-off-by: Mark Corbin
Signed-off-by: Ajeet Singh
Co-authored-by
From: Mark Corbin
Implemented the RISC-V CPU execution loop, including handling various
exceptions and system calls. The loop continuously executes CPU
instructions,processes exceptions, and handles system calls by invoking
FreeBSD syscall handlers.
Signed-off-by: Mark Corbin
Signed-off-by: Aje
From: Warner Losh
Added a generic definition for RISC-V64 target-specific details.
Implemented the 'regpairs_aligned' function,which returns 'false'
to indicate that register pairs are not aligned in the RISC-V64 ABI.
Signed-off-by: Warner Losh
Signed-off-by: Ajeet Singh
Reviewed-by: Richard H
On 8/16/2024 10:43 AM, Peter Xu wrote:
On Thu, Aug 15, 2024 at 04:54:58PM -0400, Steven Sistare wrote:
On 8/13/2024 4:43 PM, Peter Xu wrote:
On Wed, Aug 07, 2024 at 05:04:26PM -0400, Steven Sistare wrote:
On 7/19/2024 12:28 PM, Peter Xu wrote:
On Sun, Jun 30, 2024 at 12:40:29PM -0700, Steve S
Key Changes Compared to Version 1:
Patch 3: Array subscript was replaced by a register constant.
Patches 4 and 5: Merged into a single patch.
Patch 6: Comment was removed.
Patch 10: ROUND_DOWN was used to align the stack.
Array subscript was replaced by a register constant.
Patch 15: Regi
On 8/16/2024 12:17 PM, Peter Xu wrote:
On Fri, Aug 16, 2024 at 05:00:32PM +0100, Daniel P. Berrangé wrote:
On Fri, Aug 16, 2024 at 11:34:10AM -0400, Peter Xu wrote:
On Fri, Aug 16, 2024 at 04:16:50PM +0100, Daniel P. Berrangé wrote:
On Fri, Aug 16, 2024 at 11:06:10AM -0400, Peter Xu wrote:
On
On Fri, 16 Aug 2024 at 16:50, Peter Maydell wrote:
> We shouldn't need to explicitly call cpu_address_space_destroy()
> from a target-specific unrealize anyway: we can do it all
> from the base class (and I think this would fix some
> leaks in current code for targets that hot-unplug, though
> I s
On 8/16/24 1:07 PM, Andrew Jones wrote:
This reverts commit f42cdf2ea5b3a1dc369792d7acbf9cd3e5c90815.
Linux does not properly handle '#msi-cells=<0>' when searching for
MSI controllers for PCI devices which results in the devices being
unable to use MSIs. A patch for Linux has been sent[1] bu
On Fri, 16 Aug 2024, Edgar E. Iglesias wrote:
> On Thu, Aug 15, 2024 at 2:30 AM Stefano Stabellini
> wrote:
> On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> > On Tue, Aug 13, 2024 at 03:52:32PM -0700, Stefano Stabellini wrote:
> > > On Tue, 13 Aug 2024, Edgar E. Iglesias wrote:
On 16/8/24 18:27, Philippe Mathieu-Daudé wrote:
On 16/8/24 18:07, Andrew Jones wrote:
This reverts commit f42cdf2ea5b3a1dc369792d7acbf9cd3e5c90815.
Ahah sorry I'm not seeing well after a long day in front of the
monitor =)
Linux does not properly handle '#msi-cells=<0>' when searching for
MS
On 16/08/2024 18.34, Philippe Mathieu-Daudé wrote:
On 16/8/24 17:37, Thomas Huth wrote:
The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
likely due to some changes in the MSYS2 environment. So far nobody has
neither a clue what's going wrong here, nor an idea how to fix thi
On 16/8/24 17:37, Thomas Huth wrote:
The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
likely due to some changes in the MSYS2 environment. So far nobody has
neither a clue what's going wrong here, nor an idea how to fix this
(in fact most QEMU developers even don't have a Wi
On 16/08/2024 18.21, Alex Bennée wrote:
Thomas Huth writes:
The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
likely due to some changes in the MSYS2 environment. So far nobody has
neither a clue what's going wrong here, nor an idea how to fix this
(in fact most QEMU devel
On Fri, Aug 16, 2024 at 12:17:30PM -0400, Peter Xu wrote:
> On Fri, Aug 16, 2024 at 05:00:32PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Aug 16, 2024 at 11:34:10AM -0400, Peter Xu wrote:
> > > On Fri, Aug 16, 2024 at 04:16:50PM +0100, Daniel P. Berrangé wrote:
> > > > On Fri, Aug 16, 2024 at 11:
On 16/8/24 18:07, Andrew Jones wrote:
This reverts commit f42cdf2ea5b3a1dc369792d7acbf9cd3e5c90815.
Linux does not properly handle '#msi-cells=<0>' when searching for
MSI controllers for PCI devices which results in the devices being
unable to use MSIs. A patch for Linux has been sent[1] but unt
Thomas Huth writes:
> The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
> likely due to some changes in the MSYS2 environment. So far nobody has
> neither a clue what's going wrong here, nor an idea how to fix this
> (in fact most QEMU developers even don't have a Windows env
On Fri, Aug 16, 2024 at 05:00:32PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 16, 2024 at 11:34:10AM -0400, Peter Xu wrote:
> > On Fri, Aug 16, 2024 at 04:16:50PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Aug 16, 2024 at 11:06:10AM -0400, Peter Xu wrote:
> > > > On Thu, Aug 15, 2024 at 04:
When we added support for nested (stage 1 + stage 2) translation
to the SMMU in commit 58377c363291d we forgot to update the
comment that documents the valid values of the "stage" property.
Add the new "nested" value to it.
Fixes: 58377c363291d ("hw/arm/smmuv3: Support and advertise nesting")
Sign
This patchset enables support for nested (two stage) translations
in the SMMU in the virt and sbsa-ref boards.
Patch 1 is Cornelia's compat-machine machinery patch, which we
need to make this change only happen for virt-9.2 and later;
patch 2 is a trivial "missing comment update" change; patches
3
Now that our SMMU model supports enabling both stages of translation
at once, we can enable this in the sbsa-ref board. Existing guest
code that only programs stage 1 and doesn't care about stage 2 should
continue to run with the same behaviour, but guests that do want to
do nested SMMU configurat
Now that our SMMU model supports enabling both stages of translation
at once, we can enable this in the virt board. This is no change in
behaviour for guests, because if they simply ignore stage 2 and never
configure it then it has no effect. For the usual backwards
compatibility reasons we enabl
From: Cornelia Huck
Add 9.2 machine types for arm/i440fx/m68k/q35/s390x/spapr.
Signed-off-by: Cornelia Huck
Reviewed-by: Daniel P. Berrangé
Message-id: 20240816103723.2325982-1-coh...@redhat.com
Signed-off-by: Peter Maydell
---
include/hw/boards.h| 3 +++
include/hw/i386/pc.h
Linux does not properly handle '#msi-cells=<0>' when searching for
MSI controllers for PCI devices which results in the devices being
unable to use MSIs. A patch for Linux has been sent[1] but until it,
or something like it, is merged and in distro kernels we should stop
adding the property. It's h
This reverts commit f42cdf2ea5b3a1dc369792d7acbf9cd3e5c90815.
Linux does not properly handle '#msi-cells=<0>' when searching for
MSI controllers for PCI devices which results in the devices being
unable to use MSIs. A patch for Linux has been sent[1] but until it,
or something like it, is merged a
Older firmwares and OS kernels which use deprecated device tree
properties or are missing support for new properties may not be
tolerant of fully compliant device trees. When divergence to the
bindings specifications is harmless for new firmwares and OS kernels
which are compliant, then it's probab
On Fri, Aug 16, 2024 at 11:14:38AM -0400, Steven Sistare wrote:
> On 8/16/2024 4:42 AM, Daniel P. Berrangé wrote:
> > On Thu, Aug 15, 2024 at 04:28:59PM -0400, Peter Xu wrote:
> > > On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Sistare wrote:
> > > > > > The new user-visible interfaces are:
> >
On Fri, Aug 16, 2024 at 11:34:10AM -0400, Peter Xu wrote:
> On Fri, Aug 16, 2024 at 04:16:50PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Aug 16, 2024 at 11:06:10AM -0400, Peter Xu wrote:
> > > On Thu, Aug 15, 2024 at 04:55:20PM -0400, Steven Sistare wrote:
> > > > On 8/13/2024 3:46 PM, Peter Xu
On Fri, Aug 16, 2024 at 04:36:58PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 16, 2024 at 11:23:01AM -0400, Peter Xu wrote:
> > On Fri, Aug 16, 2024 at 11:13:36AM -0400, Steven Sistare wrote:
> > > On 8/15/2024 4:28 PM, Peter Xu wrote:
> > > > On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Si
On Sun, 28 Apr 2024 16:00:45 +0900
Akihiko Odaki wrote:
> Since qemu_set_vnet_hdr_len() is always called when
> qemu_using_vnet_hdr() is called, we can merge them and save some code.
>
> For consistency, express that the virtio-net header is not in use by
> returning 0 with qemu_get_vnet_hdr_len
On Fri, Aug 16, 2024 at 11:13:20AM -0400, Steven Sistare wrote:
> On 8/15/2024 4:58 PM, Peter Xu wrote:
> > On Sun, Jun 30, 2024 at 12:44:03PM -0700, Steve Sistare wrote:
> > > Define functions to put/get file descriptors to/from a QEMUFile, for qio
> > > channels that support SCM_RIGHTS. Maintain
On Fri, 16 Aug 2024 at 16:37, Alex Bennée wrote:
>
> Salil Mehta writes:
>
> > vCPU Hot-unplug will result in QOM CPU object unrealization which will do
> > away
> > with all the vCPU thread creations, allocations, registrations that happened
> > as part of the realization process. This change i
On 8/15/24 22:28, Akihiko Odaki wrote:
On 2024/08/16 14:13, Akihiko Odaki wrote:
On 2024/08/15 14:48, Pierrick Bouvier wrote:
On 8/14/24 20:04, Akihiko Odaki wrote:
SimPoint is a widely used tool to find the ideal microarchitecture
simulation points so Valgrind[2] and Pin[3] support generating
On 8/15/24 23:05, Akihiko Odaki wrote:
SimPoint is a widely used tool to find the ideal microarchitecture
simulation points so Valgrind[2] and Pin[3] support generating basic
block vectors for use with them. Let's add a corresponding plugin to
QEMU too.
Note that this plugin has a different goal
The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
likely due to some changes in the MSYS2 environment. So far nobody has
neither a clue what's going wrong here, nor an idea how to fix this
(in fact most QEMU developers even don't have a Windows environment
available for properl
Salil Mehta writes:
> vCPU Hot-unplug will result in QOM CPU object unrealization which will do away
> with all the vCPU thread creations, allocations, registrations that happened
> as part of the realization process. This change introduces the ARM CPU
> unrealize
> function taking care of exact
On Fri, Aug 16, 2024 at 11:23:01AM -0400, Peter Xu wrote:
> On Fri, Aug 16, 2024 at 11:13:36AM -0400, Steven Sistare wrote:
> > On 8/15/2024 4:28 PM, Peter Xu wrote:
> > > On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Sistare wrote:
> > > > > > The new user-visible interfaces are:
> > > > > >
On Fri, Aug 16, 2024 at 04:16:50PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 16, 2024 at 11:06:10AM -0400, Peter Xu wrote:
> > On Thu, Aug 15, 2024 at 04:55:20PM -0400, Steven Sistare wrote:
> > > On 8/13/2024 3:46 PM, Peter Xu wrote:
> > > > On Tue, Aug 06, 2024 at 04:56:18PM -0400, Steven Si
On Fri, Aug 16, 2024 at 11:13:36AM -0400, Steven Sistare wrote:
> On 8/15/2024 4:28 PM, Peter Xu wrote:
> > On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Sistare wrote:
> > > > > The new user-visible interfaces are:
> > > > > * cpr-transfer (MigMode migration parameter)
> > > > > * cpr-u
On 8/16/2024 11:16 AM, Daniel P. Berrangé wrote:
On Fri, Aug 16, 2024 at 11:06:10AM -0400, Peter Xu wrote:
On Thu, Aug 15, 2024 at 04:55:20PM -0400, Steven Sistare wrote:
On 8/13/2024 3:46 PM, Peter Xu wrote:
On Tue, Aug 06, 2024 at 04:56:18PM -0400, Steven Sistare wrote:
The flipside, howeve
On Fri, Aug 16, 2024 at 11:06:10AM -0400, Peter Xu wrote:
> On Thu, Aug 15, 2024 at 04:55:20PM -0400, Steven Sistare wrote:
> > On 8/13/2024 3:46 PM, Peter Xu wrote:
> > > On Tue, Aug 06, 2024 at 04:56:18PM -0400, Steven Sistare wrote:
> > > > > The flipside, however, is that localhost migration vi
On 8/16/2024 4:42 AM, Daniel P. Berrangé wrote:
On Thu, Aug 15, 2024 at 04:28:59PM -0400, Peter Xu wrote:
On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Sistare wrote:
The new user-visible interfaces are:
* cpr-transfer (MigMode migration parameter)
* cpr-uri (migration parameter)
I
On 8/15/2024 4:46 PM, Peter Xu wrote:
On Sun, Jun 30, 2024 at 12:44:06PM -0700, Steve Sistare wrote:
Define the cpr-uri migration parameter to specify the URI to which
CPR vmstate is saved for cpr-transfer mode.
Signed-off-by: Steve Sistare
So I left the idea in my reply to the cover letter
On 8/15/2024 4:28 PM, Peter Xu wrote:
On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Sistare wrote:
The new user-visible interfaces are:
* cpr-transfer (MigMode migration parameter)
* cpr-uri (migration parameter)
I wonder whether this parameter can be avoided already, maybe we can l
On 8/15/2024 4:58 PM, Peter Xu wrote:
On Sun, Jun 30, 2024 at 12:44:03PM -0700, Steve Sistare wrote:
Define functions to put/get file descriptors to/from a QEMUFile, for qio
channels that support SCM_RIGHTS. Maintain ordering such that
put(A), put(fd), put(B)
followed by
get(A), get(fd),
On Thu, Aug 15, 2024 at 04:55:20PM -0400, Steven Sistare wrote:
> On 8/13/2024 3:46 PM, Peter Xu wrote:
> > On Tue, Aug 06, 2024 at 04:56:18PM -0400, Steven Sistare wrote:
> > > > The flipside, however, is that localhost migration via 2 separate QEMU
> > > > processes has issues where both QEMUs wa
On 16/8/24 15:22, Peter Maydell wrote:
Currently the QemuLockCnt data structure and associated functions are
in the include/qemu/thread.h header. Move them to their own
qemu/lockcnt.h. The main reason for doing this is that it means we
can autogenerate the documentation comments into the docs/d
On 06/08/2024 19.31, Cleber Rosa wrote:
The "media=cdrom" parameter is also used on some Avocado tests as a
way to protect files from being written. The tests here bring a more
fundamental check that this behavior can be trusted.
Signed-off-by: Cleber Rosa
---
tests/avocado/cdrom.py | 41 +++
1 - 100 of 199 matches
Mail list logo
