Peter Xu writes:
> On Thu, Feb 06, 2025 at 02:32:12PM -0300, Fabiano Rosas wrote:
>> > In any case we'd still need some kind of a compatibility behavior for
>> > the TLS bit stream emitted by older QEMU versions (which is always
>> > improperly terminated).
>> >
>>
>> There is no compat issue. F
On 07.02.25 14:41, Stefan Hajnoczi wrote:
On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek wrote:
On 28.01.25 17:16, Stefan Hajnoczi wrote:
Dear QEMU and KVM communities,
QEMU will apply for the Google Summer of Code internship
program again this year. Regular contributors can submit project
idea
On Fri, Feb 7, 2025 at 8:48 AM Hanna Czenczek wrote:
>
> On 07.02.25 14:41, Stefan Hajnoczi wrote:
> > On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek wrote:
> >> On 28.01.25 17:16, Stefan Hajnoczi wrote:
> >>> Dear QEMU and KVM communities,
> >>> QEMU will apply for the Google Summer of Code inter
On Fri, 7 Feb 2025 at 11:53, Michael Tokarev wrote:
>
> 07.02.2025 13:27, Paolo Bonzini wrote:
> > From: Peter Maydell
> >
> > In commit 8adcff4ae7 ("fpu: handle raising Invalid for infzero in
> > pick_nan_muladd") we changed the handling of 0 * Inf + QNaN to always
> > raise the Invalid exceptio
On Thu, Feb 06, 2025 at 10:10:54AM -0500, Stefan Hajnoczi wrote:
> I have added your project idea to the wiki. Please make further
> changes directly on the wiki.
>
> https://wiki.qemu.org/Google_Summer_of_Code_2025#Adding_Kani_proofs_for_Virtqueues_in_Rust-vmm
>
> Thanks,
> Stefan
>
Thanks,
M
On Thu, Feb 06, 2025 at 10:02:43AM -0500, Stefan Hajnoczi wrote:
> On Thu, Feb 6, 2025 at 4:34 AM Matias Ezequiel Vara Larsen
> wrote:
> > === Adding Kani proofs for Virtqueues in Rust-vmm ===
> >
> > '''Summary:''' Verify conformance of the virtqueue implementation in
> > rust-vmm to the VirtIO s
On Fri, Feb 07, 2025 at 10:17:19AM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Thu, Feb 06, 2025 at 02:32:12PM -0300, Fabiano Rosas wrote:
> >> > In any case we'd still need some kind of a compatibility behavior for
> >> > the TLS bit stream emitted by older QEMU versions (which is al
On 2/7/25 14:33, Zhao Liu wrote:
+pub use bindings::QEMUTimer;
+
+use crate::{
+bindings::{
+self, qemu_clock_get_ns, timer_del, timer_init_full, timer_mod,
QEMUClockType,
+QEMUTimerListGroup,
+},
+callbacks::FnCall,
+};
+
+impl QEMUTimer {
+pub fn new() -> Self {
On Fri, Feb 07, 2025 at 11:27:57AM -0300, Fabiano Rosas wrote:
> Add a read flag that can inform a channel that it's ok to receive an
> EOF at any moment. Channels that have some form of strict EOF
> tracking, such as TLS session termination, may choose to ignore EOF
> errors with the use of this f
The SMC91C111 includes an MMU Command register which permits
the guest to remove entries from the RX FIFO. The datasheet
does not specify what happens if the guest tries to do this
when the FIFO is already empty; there are no status registers
containing error bits which might be applicable.
Curren
From: Ilya Leoshkevich
Allow debugging individual processes in multi-process applications by
starting them with export QEMU_GDB=/tmp/qemu-%d.sock,suspend=n.
Currently one would have to attach to every process to ensure the app
makes progress.
In case suspend=n is not specified, the flow remains
Until there are timers enabled the semantics of clock_step_next() will
fail. Since d524441a36 (system/qtest: properly feedback results of
clock_[step|set]) we will signal a FAIL if time doesn't advance.
Signed-off-by: Alex Bennée
Reviewed-by: Hao Wu
---
tests/qtest/npcm7xx_timer-test.c | 1 -
1
From: Ilya Leoshkevich
Add a function for sending signals to individual threads. It does not make
sense on Windows, so do not provide an implementation, so that if someone
uses it by accident, they will get a linker error.
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
Signed-off-by:
This reverts commit bc02be4508d8753d1f6071b77d10f4661587df6f.
Now we catch attempts to clock_step to the next timer when none are
enabled we can revert the previous attempt to prevent deadlock. As
long as a new target time is given we will move time forward even if
no timers will fire. This is des
On 2/7/25 15:47, Stefan Hajnoczi wrote:
On Fri, Feb 7, 2025 at 9:39 AM Helge Deller wrote:
Hi Stefan,
On 1/28/25 17:16, Stefan Hajnoczi wrote:
How to propose your idea
--
Reply to this email with the following project idea template filled in:
Would something lik
From: Ilya Leoshkevich
Just like for QEMU_LOG_FILENAME, replace %d with PID in the GDB socket
path. This allows running multi-process applications with, e.g.,
export QEMU_GDB=/tmp/qemu-%d.sock. Currently this is not possible,
since the first process will cause the subsequent ones to fail due to
n
From: Ilya Leoshkevich
Attaching to the gdbstub of a running process requires stopping its
threads. For threads that run on a CPU, cpu_exit() is enough, but the
only way to grab attention of a thread that is stuck in a long-running
syscall is to interrupt it with a signal.
Reserve a host realtim
qtest_send_prefix never actually sent something over the chardev, all
it does is print the timestamp to the QTEST_LOG when enabled. So
rename the function, make it static, remove the unused CharDev and
simplify all the call sites by handling that directly with
qtest_send (and qtest_log_send).
Sign
Ccing qemu-trivial and Michael
On 2/7/25 12:28 PM, Rob Bradford wrote:
The mvendorid/mimpid/marchid properties have the wrong amount of
whitespace ahead of them.
Signed-off-by: Rob Bradford
---
Reviewed-by: Daniel Henrique Barboza
target/riscv/cpu.c | 6 +++---
1 file changed, 3 inse
The mvendorid/mimpid/marchid properties have the wrong amount of
whitespace ahead of them.
Signed-off-by: Rob Bradford
---
target/riscv/cpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 3d4bd157d2..cca24b9f1f 100644
---
Another month and another set of updates from across my maintainer
trees. They include:
* qtest set/step clock cleanups
It seems the earlier patch to avoid deadlock when shutting down was
overly broad. So in this series after a little clean-up to the qtest
reply code we tighten up some checks f
This replicates the changes from 92cb8f8bf6 (tests/qtest: remove
clock_steps from virtio tests) as there are no timers in the virtio
code. We still busy wait and timeout though.
Signed-off-by: Alex Bennée
---
v2
- fix trailing space
---
tests/qtest/libqos/virtio-pci-modern.c | 6 ++
tests
It is invalid to call clock_step with an implied time to step forward
as if no timers are running we won't be able to advance.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
---
v3
- used Peter's suggested wording
- used plain old if over ternary operator
---
system/qtest.c | 13 +++
On Fri, Feb 07, 2025 at 04:02:44PM +0530, Prasad Pandit wrote:
> Hi,
>
> On Fri, 7 Feb 2025 at 04:46, Peter Xu wrote:
> > > +/* Migration channel types */
> > > +enum { CH_DEFAULT, CH_MULTIFD, CH_POSTCOPY };
> >
> > Maybe s/DEFAULT/MAIN/?
>
> * Okay.
>
> > > -if (migrate_multifd() && !migra
From: Philippe Mathieu-Daudé
Previous commit passed all our CI tests, this assertion being
never triggered. Remove it as dead code.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Signed-off-by: Igor Mammedov
---
CC: k...@vger.kernel.org
---
accel/kvm/kvm-all.c | 7 -
previous commits fixed 2 remaining cases where vcpu might
have had 'cpu->created == false' during 1st vcpu reset (at realize time)
that leads to call chain
tcg_cpu_reset_hold() => tlb_flush_by_mmuidx()
remove not need anymore check, with cpu->created always being true.
Signed-off-by: Igor M
Reseting vcpu before its thread is created, caused various issues in the past
for other targets. It doesn't cause issues for loongarch at the moment but
to be consistent with the rest of targets, move reset during realize time
after qemu_init_vcpu().
That basically prevents reset being run when wh
From: Philippe Mathieu-Daudé
Let vCPUs wait for themselves being ready first, then other ones.
This allows the first thread to starts without the global vcpu
queue (thus &first_cpu) being populated.
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Igor Mammedov
---
accel/tcg/tcg-accel-ops
Changelog:
* drop wire/unwire hooks patches
* drop unrealize related patches
* include fixed up patches from
[PATCH 0/6] tcg: fix qemu crash when add assert_cpu_is_self() is enabled
and cleanups related to cpu->created check
https://patchew.org/QEMU/20250129134436.12407
that will enable assert_cpu_is_self when QEMU is configured with
--enable-debug
without need for manual patching DEBUG_TLB_GATE define.
Need to manually path DEBUG_TLB_GATE define to enable assert,
let regression caused by [1] creep in unnoticed.
1) 30933c4fb4f3d ("tcg/cputlb: remove other-cpu
target_reset_cpu() static inlines have no user,
remove them.
Signed-off-by: Igor Mammedov
---
CC: Warner Losh
CC: Kyle Evans
---
bsd-user/aarch64/target_arch_cpu.h | 5 -
bsd-user/arm/target_arch_cpu.h | 4
bsd-user/i386/target_arch_cpu.h| 5 -
bsd-user/riscv/target_arch_c
From: Philippe Mathieu-Daudé
Previous commits made sure vCPUs are realized before accelerators
(such KVM) use them. Ensure that by asserting the vCPU is created,
no need to return.
For more context, see commit 56adee407fc ("kvm: dirty-ring: Fix race
with vcpu creation").
Signed-off-by: Philippe
cpu_list_add() was doing 2 distinct things:
- assign some index to vCPU
- add unrealized (thus in inconsistent state) vCPU to &cpus_queue
Code using CPU_FOREACH() macro would iterate over possibly
unrealized vCPUs, often dealt with special casing.
Instead of working around of vCPU existence in cp
1)
This reverts commit 30933c4fb4f3df95ae44c4c3c86a5df049852c01.
("tcg/cputlb: remove other-cpu capability from TLB flushing")
The commit caused a regression which went unnoticed due to
affected being disabled by default (DEBUG_TLB_GATE 0)
Previous patch switched to using tcg_debug_assert() so t
Reseting vcpu before its thread is created, caused various issues in the past
for other targets. It doesn't cause issues for m68k at the moment but
to be consistent with the rest of targets, move reset during realize time
after qemu_init_vcpu().
That basically prevents reset being run when when vC
From: Ilya Leoshkevich
Add a small test to prevent regressions.
Make sure that host_interrupt_signal is not visible to the guest.
Reviewed-by: Alex Bennée
Signed-off-by: Ilya Leoshkevich
Message-Id: <20250117001542.8290-9-...@linux.ibm.com>
Signed-off-by: Alex Bennée
---
tests/tcg/multiarch/
Don't both creating a GString to temporarily hold our qtest command.
Instead do a simpler g_strndup and use autofree to clean up
afterwards.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
---
system/qtest.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff
From: Ilya Leoshkevich
In case an emulated process execve()s another emulated process, bind()
will fail, because the socket already exists. So try deleting it. Use
the existing unix_listen() function which does this. Link qemu-user
with qemu-sockets.c and add the monitor_get_fd() stub.
Note that
From: Ilya Leoshkevich
gdbstub needs target_to_host_signal(), so move its declaration to a
public header.
Reviewed-by: Richard Henderson
Reviewed-by: Warner Losh
Signed-off-by: Ilya Leoshkevich
Message-Id: <20250117001542.8290-4-...@linux.ibm.com>
Signed-off-by: Alex Bennée
---
bsd-user/sig
On Fri, Feb 07, 2025, David Woodhouse wrote:
> From: David Woodhouse
>
> At the time kvm_xen_init() is called, hyperv_enabled() doesn't yet work, so
> the correct MSR index to use for the hypercall page isn't known.
>
> Rather than setting it to the default and then shifting it later for the
> H
From: Fabiano Rosas
Choose a few tests per group and move them from the full set to the
smoke set.
Signed-off-by: Fabiano Rosas
Reviewed-by: Peter Xu
Message-Id: <20250130184012.5711-3-faro...@suse.de>
Signed-off-by: Alex Bennée
---
tests/qtest/migration-test.c | 1 -
tests/qte
From: Ilya Leoshkevich
Reviewed-by: Alex Bennée
Signed-off-by: Ilya Leoshkevich
Message-Id: <20250117001542.8290-8-...@linux.ibm.com>
Signed-off-by: Alex Bennée
---
docs/user/main.rst | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/docs/user/main.rst b/do
This allows people to run the test locally:
make docker-test-rust@fedora-rust-nightly
Signed-off-by: Alex Bennée
---
v2
- update MAINTAINERS
---
MAINTAINERS | 1 +
tests/docker/Makefile.include | 3 +++
tests/docker/test-rust| 21 +
3 files c
From: Fabiano Rosas
Add a new command line option to allow selecting between running the
full set of tests or a smaller set of tests. The default will be to
run the small set (i.e. no comand line option provided) so we can
reduce the amount of tests run by default. Only hosts which support
KVM fo
Thomas Huth writes:
> This test just needs the adaption for the asset handling, then
> we can move it to the functional framework.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Alex Bennée
Tested-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
On Thu, 6 Feb 2025 at 15:41, Peter Maydell wrote:
>
> On Tue, 20 Aug 2024 at 12:30, Florian Lugou
> wrote:
> >
> > > > $ aarch64-none-elf-gcc -ffreestanding -nostdlib -T
> > > > qemu/tests/tcg/aarch64/system/kernel.ld -o test test.S
> > > >
> > > > $ qemu-system-aarch64 \
> > > > -machi
On Tue, Feb 04, 2025 at 03:33:10PM +1000, Gavin Shan wrote:
> > diff --git a/include/hw/loader.h b/include/hw/loader.h
> > index 7f6d06b956..0cd9905f97 100644
> > --- a/include/hw/loader.h
> > +++ b/include/hw/loader.h
> > @@ -353,6 +353,21 @@ void *rom_ptr_for_as(AddressSpace *as, hwaddr addr,
>
On Tue, Feb 04, 2025 at 03:02:41PM +1000, Gavin Shan wrote:
> > +reg.id = AARCH64_CORE_REG(regs.pc);
> > +reg.addr = (uintptr_t) &env->pc;
> > +ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®);
> > +if (ret) {
> > +return ret;
> > +}
> > +
> > +return 0;
> > +}
> > +
>
On Tue, Feb 04, 2025 at 03:30:00PM +1000, Gavin Shan wrote:
> > +hwaddr ram_base;
> > +size_t ram_size;
> > };
>
> s/size_t/hwaddr. To be consistent with RmeRamRegion, we may reuse
> it like below.
>
> struct RmeGuest {
> :
> GSlist *populate_ram_regions;
> RmeRamRegion init
On Tue, Feb 04, 2025 at 05:27:17PM +1000, Gavin Shan wrote:
> On 11/26/24 5:56 AM, Jean-Philippe Brucker wrote:
> > All Realm IPA states are by default RIPAS_EMPTY, and accessing them in
> > that state causes injection of synchronous exception. Either the loader
> > or the guest needs to set IPA st
On 07/02/2025 16.30, Alex Bennée wrote:
This replicates the changes from 92cb8f8bf6 (tests/qtest: remove
clock_steps from virtio tests) as there are no timers in the virtio
code. We still busy wait and timeout though.
Signed-off-by: Alex Bennée
---
v2
- fix trailing space
---
tests/qtest/
On Fri, Feb 7, 2025 at 10:34 AM Helge Deller wrote:
>
> On 2/7/25 15:47, Stefan Hajnoczi wrote:
> > On Fri, Feb 7, 2025 at 9:39 AM Helge Deller wrote:
> >>
> >> Hi Stefan,
> >>
> >> On 1/28/25 17:16, Stefan Hajnoczi wrote:
> >>> How to propose your idea
> >>> --
> >>>
On 07/02/2025 16.31, Alex Bennée wrote:
qtest_send_prefix never actually sent something over the chardev, all
it does is print the timestamp to the QTEST_LOG when enabled. So
rename the function, make it static, remove the unused CharDev and
simplify all the call sites by handling that directly w
On Tue, 28 Jan 2025 15:21:43 +0100
Philippe Mathieu-Daudé wrote:
> Hi,
>
> The goal of this series is to expose vCPUs in a stable state
> to the accelerators, in particular the QDev 'REALIZED' step.
I'll take some of your patches (with Richard's feedback fixed),
and respin series focusing mostl
On Thu, 6 Feb 2025 at 14:23, Eric Auger wrote:
>
> Currently the iommu may be reset before the devices
> it protects. For example this happens with virtio-scsi-pci.
> when system_reset is issued from qmp monitor, spurious
> "virtio: zero sized buffers are not allowed" warnings can
> be observed.
>
On Fri, 7 Feb 2025 at 11:10, Michael S. Tsirkin wrote:
>
> On Thu, Feb 06, 2025 at 03:21:51PM +0100, Eric Auger wrote:
> > This is a follow-up of Peter's attempt to fix the fact that
> > vIOMMUs are likely to be reset before the device they protect:
> >
> > [PATCH 0/4] intel_iommu: Reset vIOMMU af
On 2/7/25 5:37 PM, Peter Maydell wrote:
> On Thu, 6 Feb 2025 at 14:23, Eric Auger wrote:
>> Currently the iommu may be reset before the devices
>> it protects. For example this happens with virtio-scsi-pci.
>> when system_reset is issued from qmp monitor, spurious
>> "virtio: zero sized buffer
Hi Peter, Michael,
On 2/7/25 5:40 PM, Peter Maydell wrote:
> On Fri, 7 Feb 2025 at 11:10, Michael S. Tsirkin wrote:
>> On Thu, Feb 06, 2025 at 03:21:51PM +0100, Eric Auger wrote:
>>> This is a follow-up of Peter's attempt to fix the fact that
>>> vIOMMUs are likely to be reset before the device
On Thu, Feb 06, 2025 at 03:21:51PM +0100, Eric Auger wrote:
> This is a follow-up of Peter's attempt to fix the fact that
> vIOMMUs are likely to be reset before the device they protect:
>
> [PATCH 0/4] intel_iommu: Reset vIOMMU after all the rest of devices
> https://lore.kernel.org/all/202401170
On Fri, 7 Feb 2025 at 16:50, Eric Auger wrote:
>
>
>
>
> On 2/7/25 5:37 PM, Peter Maydell wrote:
> > On Thu, 6 Feb 2025 at 14:23, Eric Auger wrote:
> >> Currently the iommu may be reset before the devices
> >> it protects. For example this happens with virtio-scsi-pci.
> >> when system_reset is i
On Fri, 7 Feb 2025 at 16:54, Peter Xu wrote:
>
> On Thu, Feb 06, 2025 at 03:21:51PM +0100, Eric Auger wrote:
> > This is a follow-up of Peter's attempt to fix the fact that
> > vIOMMUs are likely to be reset before the device they protect:
> >
> > [PATCH 0/4] intel_iommu: Reset vIOMMU after all th
201 - 261 of 261 matches
Mail list logo
