On Thu, Feb 08, 2024 at 09:02:28AM +0300, Michael Tokarev wrote:
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1286
> Signed-off-by: Michael Tokarev
> ---
> qemu-options.hx | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Daniel P. Berrangé
With regards,
Daniel
--
|: https:
On Wed, Feb 7, 2024 at 4:47 PM Stefano Garzarella wrote:
>
> On Wed, Feb 07, 2024 at 11:17:34AM +0800, Jason Wang wrote:
> >On Tue, Feb 6, 2024 at 4:31 PM Stefano Garzarella
> >wrote:
> >>
> >> On Tue, Feb 06, 2024 at 10:47:40AM +0800, Jason Wang wrote:
> >> >On Mon, Feb 5, 2024 at 6:51 PM Stefa
Eric Blake writes:
> On Sat, Feb 03, 2024 at 09:02:26AM +0100, Markus Armbruster wrote:
>> qemu_socket() and make_udp_socket() return a file descriptor on
>> success, -1 on failure. The check misinterprets 0 as failure. Fix
>> that.
>>
>> Signed-off-by: Markus Armbruster
>> ---
>> tests/unit
Eric Blake writes:
> On Sat, Feb 03, 2024 at 09:02:25AM +0100, Markus Armbruster wrote:
>> The __linux__ version of qemu_chr_open_pp_fd() tries to claim the
>> parport device with a PPCLAIM ioctl(). On success, it stores the file
>> descriptor in the chardev object, and returns success. On fail
Daniel P. Berrangé writes:
> On Mon, Feb 05, 2024 at 08:47:03AM +0100, Markus Armbruster wrote:
>> Add missing return member documentation of guest-get-disks,
>> guest-get-devices, guest-get-diskstats, and guest-get-cpustats.
>>
>> The NVMe SMART information returned by guest-getdisks remains
>>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1286
Signed-off-by: Michael Tokarev
---
qemu-options.hx | 2 ++
1 file changed, 2 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
index 5adbed1101..05f70231c9 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3100,6 +3100,
On Wed, Feb 07, 2024 at 02:33:47PM +0100, Cédric Le Goater wrote:
> In case of error, close_return_path_on_source() can perform a shutdown
> to exit the return-path thread. However, in migrate_fd_cleanup(),
> 'to_dst_file' is closed before calling close_return_path_on_source()
> and the shutdown f
On Wed, Feb 07, 2024 at 02:33:46PM +0100, Cédric Le Goater wrote:
> close_return_path_on_source() retrieves the migration error from the
> the QEMUFile '->to_dst_file' to know if a shutdown is required. This
> shutdown is required to exit the return-path thread. However, in
> migrate_fd_cleanup(),
On Wed, Feb 07, 2024 at 02:33:45PM +0100, Cédric Le Goater wrote:
> This will help detect issues regarding I/O channels usage.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Peter Xu
--
Peter Xu
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_GLOBAL(log_global_start, Forward)
06.02.2024 18:31, Stefan Hajnoczi :
Requests that complete in an IOThread use irqfd to notify the guest
while requests that complete in the main loop thread use the traditional
qdev irq code path. The reason for this conditional is that the irq code
path requires the BQL:
if (s->ioeventfd_sta
07.02.2024 22:01, Manos Pitsidianakis:
Hello Michael,
Such changes are long overdue. However given the complexity of
commands and arguments, maybe it'd be a good idea to write a code
generator for the command line interface, This way you could also
generate --help outputs, manpages, shell comple
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,7 +3498,7 @@ void col
On Wed, Feb 07, 2024 at 02:33:34PM +0100, Cédric Le Goater wrote:
> diff --git a/migration/ram.c b/migration/ram.c
> index
> d5b7cd5ac2f31aabf4a248b966153401c48912cf..136c237f4079f68d4e578cf1c72eec2efc815bc8
> 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2931,7 +2931,7 @@ void qem
From: Peter Xu
Commit a1af605bd5 ("migration/multifd: fix hangup with TLS-Multifd due to
blocking handshake") introduced a thread for TLS channels, which will
resolve the issue on blocking the main thread. However in the same commit
p->c is slightly abused just to be able to pass over the pointe
From: Peter Xu
Based-on: <20240208030528.368214-1-pet...@redhat.com>
The patchset is based on the latest migration pull request. This is a
small cleanup patchset to firstly cleanup tls iochannel deref on error
paths, then further remove one unused var on yank if the cleanup applies.
These are
From: Peter Xu
With a clear definition of p->c protocol, where we only set it up if the
channel is fully established (TLS or non-TLS), registered_yank boolean will
have equal meaning of "p->c != NULL".
Drop registered_yank by checking p->c instead.
Reviewed-by: Fabiano Rosas
Signed-off-by: Pet
On Wed, Feb 07, 2024 at 10:31:51AM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Tue, Feb 06, 2024 at 06:51:12PM -0300, Fabiano Rosas wrote:
> >> Based-on: 20240202102857.110210-1-pet...@redhat.com
> >> [PATCH v2 00/23] migration/multifd: Refactor ->send_prepare() and cleanups
> >> http
From: Peter Xu
Using int is an overkill when there're only two options. Change it to a
boolean.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-18-pet...@redhat.com
Signed-off-by: Peter Xu
---
migration/multifd.c | 15 ---
1 file changed, 8 insert
From: Peter Xu
As reported correctly by Fabiano [1] (while per Fabiano, it sourced back to
Elena's initial report in Oct 2023), MultiFDSendParams.packet_num is buggy
to be assigned and stored. Consider two consequent operations of: (1)
queue a job into multifd send thread X, then (2) queue anoth
From: Peter Xu
This array is redundant when p->pages exists. Now we extended the life of
p->pages to the whole period where pending_job is set, it should be safe to
always use p->pages->offset[] rather than p->normal[]. Drop the array.
Alongside, the normal_num is also redundant, which is the
From: Peter Xu
The sender thread will yield the p->mutex before IO starts, trying to not
block the requester thread. This may be unnecessary lock optimizations,
because the requester can already read pending_job safely even without the
lock, because the requester is currently the only one who ca
From: Peter Xu
The current multifd_queue_page() is not easy to read and follow. It is not
good with a few reasons:
- No helper at all to show what exactly does a condition mean; in short,
readability is low.
- Rely on pages->ramblock being cleared to detect an empty queue. It's
slight
From: Peter Xu
When reviewing my attempt to refactor send_prepare(), Fabiano suggested we
try out with dropping the mutex in multifd code [1].
I thought about that before but I never tried to change the code. Now
maybe it's time to give it a stab. This only optimizes the sender side.
The tric
From: Peter Xu
Multifd provide a threaded model for processing jobs. On sender side,
there can be two kinds of job: (1) a list of pages to send, or (2) a sync
request.
The sync request is a very special kind of job. It never contains a page
array, but only a multifd packet telling the dest sid
From: Fabiano Rosas
We currently only need p->running to avoid calling qemu_thread_join()
on a non existent thread if the thread has never been created.
However, there are at least two bugs in this logic:
1) On the sending side, p->running is set too early and
qemu_thread_create() can be skippe
From: Peter Xu
Multifd send side has two fields to indicate error quits:
- MultiFDSendParams.quit
- &multifd_send_state->exiting
Merge them into the global one. The replacement is done by changing all
p->quit checks into the global var check. The global check doesn't need
any lock.
A few
From: Peter Xu
Introduce a helper multifd_send_prepare_header() to setup the header packet
for multifd sender.
It's fine to setup the IOV[0] _before_ send_prepare() because the packet
buffer is already ready, even if the content is to be filled in.
With this helper, we can already slightly clea
From: Peter Xu
Now multifd's logic is designed to have no spurious wakeup. I still
remember a talk to Juan and he seems to agree we should drop it now, and if
my memory was right it was there because multifd used to hit that when
still debugging.
Let's drop it and see what can explode; as long
From: Peter Xu
Shrink the function by moving relevant works into helpers: move the thread
join()s into multifd_send_terminate_threads(), then create two more helpers
to cover channel/state cleanups.
Add a TODO entry for the thread terminate process because p->running is
still buggy. We need to
From: Fabiano Rosas
We're currently leaking the resources of the TLS thread by not joining
it and also overwriting the p->thread pointer altogether.
Fixes: a1af605bd5 ("migration/multifd: fix hangup with TLS-Multifd due to
blocking handshake")
Cc: qemu-stable
Reviewed-by: Peter Xu
Signed-off-
From: Peter Xu
The new build-previous-qemu job relies on QEMU release tag being present,
while that may not be always true for personal git repositories since by
default tag is not pushed. The job can fail on those CI kicks, as reported
by Peter Maydell.
Fix it by fetching the tags remotely fro
From: Peter Xu
Move them into fill/unfill of packets. With that, we can further cleanup
the send/recv thread procedure, and remove one more temp var.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-12-pet...@redhat.com
Signed-off-by: Peter Xu
---
migration/mu
From: Fabiano Rosas
During multifd channel creation (multifd_send_new_channel_async) when
TLS is enabled, the multifd_channel_connect function is called twice,
once to create the TLS handshake thread and another time after the
asynchrounous TLS handshake has finished.
This creates a slightly con
From: Avihai Horon
The commit in the fixes line mistakenly modified the channels and
transport compatibility check logic so it now checks multi-channel
support only for socket transport type.
Thus, running multifd migration using a transport other than socket that
is incompatible with multi-chan
From: Peter Xu
Use similar logic to cleanup the recv side.
Note that multifd_recv_terminate_threads() may need some similar rework
like the sender side, but let's leave that for later.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-21-pet...@redhat.com
Signed-
From: Peter Xu
This field, no matter whether on src or dest, is only used for debugging
purpose.
They can even be removed already, unless it still more or less provide some
accounting on "how many packets are sent/recved for this thread". The
other more important one is called packet_num, which
From: Peter Xu
Using int is an overkill when there're only two options. Change it to a
boolean.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-17-pet...@redhat.com
Signed-off-by: Peter Xu
---
migration/multifd.h | 2 +-
migration/multifd.c | 9 +
mig
From: Fabiano Rosas
Hide the error handling inside multifd_send_setup to make it cleaner
for the next patch to move the function around.
Reviewed-by: Peter Xu
Signed-off-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240206215118.6171-4-faro...@suse.de
Signed-off-by: Peter Xu
---
migrat
From: Peter Xu
Just like the previous patch, move the accounting for total_normal_pages on
both src/dst sides into the packet fill/unfill procedures.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-11-pet...@redhat.com
Signed-off-by: Peter Xu
---
migration/mul
From: Peter Xu
It turns out that we may not be able to enable this test even for the
upcoming v9.0. Document what we're still missing.
Reviewed-by: "Daniel P. Berrangé"
Link: https://lore.kernel.org/r/20240207005403.242235-4-pet...@redhat.com
Signed-off-by: Peter Xu
---
.gitlab-ci.d/buildtes
From: Fabiano Rosas
It is possible that one of the multifd channels fails to be created at
multifd_new_send_channel_async() while the rest of the channel
creation tasks are still in flight.
This could lead to multifd_save_cleanup() executing the
qemu_thread_join() loop too early and not waiting
From: Fabiano Rosas
We currently have an unfavorable situation around multifd channels
creation and the migration thread execution.
We create the multifd channels with qio_channel_socket_connect_async
-> qio_task_run_in_thread, but only connect them at the
multifd_new_send_channel_async callback
From: Peter Xu
Split multifd_send_terminate_threads() into two functions:
- multifd_send_set_error(): used when an error happened on the sender
side, set error and quit state only
- multifd_send_terminate_threads(): used only by the main thread to kick
all multifd send threads out o
From: Peter Xu
Most of the multifd code uses send/recv to represent the two sides, but
some rare cases use save/load.
Since send/recv is the majority, replacing the save/load use cases to use
send/recv globally. Now we reach a consensus on the naming.
Reviewed-by: Fabiano Rosas
Link: https://
From: Peter Xu
We've already done that with multifd_flush_after_each_section, for multifd
in general. Drop the stale "TODO-like" comment.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-2-pet...@redhat.com
Signed-off-by: Peter Xu
---
migration/multifd.c | 11
From: Peter Xu
Recently we introduced cross-binary migration test. It's always wanted
that migration-test uses stable guest ABI for both QEMU binaries in this
case, so that both QEMU binaries will be compatible on the migration
stream with the cmdline specified.
Switch to a static gic version "
From: Peter Xu
When a multifd sender thread hit errors, it always needs to kick the main
thread by kicking all the semaphores that it can be waiting upon.
Provide a helper for it and deduplicate the code.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-3-pet...
From: Peter Xu
This patch redefines the interfacing of ->send_prepare(). It further
simplifies multifd_send_thread() especially on zero copy.
Now with the new interface, we require the hook to do all the work for
preparing the IOVs to send. After it's completed, the IOVs should be ready
to be
From: Peter Xu
Now with a split SYNC handler, we always have pages->num set for
pending_job==true. Assert it instead.
Reviewed-by: Fabiano Rosas
Link: https://lore.kernel.org/r/20240202102857.110210-9-pet...@redhat.com
Signed-off-by: Peter Xu
---
migration/multifd.c | 13 +++--
1 fil
From: Peter Xu
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:
https://gitlab.com/peterx/qemu.git tags/migration
From: Peter Xu
Now we reset MultiFDPages_t object in the multifd sender thread in the
middle of the sending job. That's not necessary, because the "*pages"
struct will not be reused anyway until pending_job is cleared.
Move that to the end after the job is completed, provide a helper to reset
a
From: William Roche
A memory page poisoned from the hypervisor level is no longer readable.
The migration of a VM will crash Qemu when it tries to read the
memory address space and stumbles on the poisoned page with a similar
stack trace:
Program terminated with signal SIGBUS, Bus error.
#0 _mm
On Tue, Feb 06, 2024 at 06:51:12PM -0300, Fabiano Rosas wrote:
> Based-on: 20240202102857.110210-1-pet...@redhat.com
> [PATCH v2 00/23] migration/multifd: Refactor ->send_prepare() and cleanups
> https://lore.kernel.org/r/20240202102857.110210-1-pet...@redhat.com
>
> Hi,
>
> For v3 I fixed the re
On Wed, Feb 07, 2024 at 03:44:18PM -0800, Hao Xiang wrote:
> On Wed, Feb 7, 2024 at 12:41 AM Jiri Denemark wrote:
> >
> > On Wed, Feb 07, 2024 at 12:37:15 +0800, Peter Xu wrote:
> > > On Wed, Feb 07, 2024 at 12:13:10PM +0800, Peter Xu wrote:
> > > > On Tue, Feb 06, 2024 at 11:19:04PM +, Hao Xi
On Wed, Feb 07, 2024 at 08:54:00AM +0800, pet...@redhat.com wrote:
> From: Peter Xu
>
> v2:
> - Fix a typo in patch 2 on QEMU_PREV_VERSION
> - Added R-bs for Dan
>
> Hi,
>
> This small patchset updates the recent cross-binary test for migration on
> a few things.
>
> Patch 1 modifies the aarch
On Wed, Feb 07, 2024 at 04:47:27PM -0800, Hao Xiang wrote:
> Sure I will drop "throughput" to avoid confusion. In my testing, 1
> multifd channel already makes the main thread spin at 100%. So the
> total-time is the same across 1/2/4 multifd channels as long as zero
> page is run on the main migra
On Wed, Feb 7, 2024 at 12:38 AM Liu, Yuan1 wrote:
>
> Thank you very much for your reminder and the rapid updates to the
> multifd function. I will incorporate your suggestions into the next
> version (IAA Accelerated Live Migration solution).
>
> Regarding the QAT and DSA optimization, my colleag
On Tue, Feb 6, 2024 at 7:45 PM Peter Xu wrote:
>
> On Tue, Feb 06, 2024 at 11:19:03PM +, Hao Xiang wrote:
> > diff --git a/qapi/migration.json b/qapi/migration.json
> > index 819708321d..ff033a0344 100644
> > --- a/qapi/migration.json
> > +++ b/qapi/migration.json
> > @@ -874,6 +874,11 @@
> >
On Tue, Feb 6, 2024 at 7:39 PM Peter Xu wrote:
>
> On Tue, Feb 06, 2024 at 11:19:02PM +, Hao Xiang wrote:
> > This patchset is based on Juan Quintela's old series here
> > https://lore.kernel.org/all/20220802063907.18882-1-quint...@redhat.com/
> >
> > In the multifd live migration model, there
On Wed, Feb 7, 2024 at 12:41 AM Jiri Denemark wrote:
>
> On Wed, Feb 07, 2024 at 12:37:15 +0800, Peter Xu wrote:
> > On Wed, Feb 07, 2024 at 12:13:10PM +0800, Peter Xu wrote:
> > > On Tue, Feb 06, 2024 at 11:19:04PM +, Hao Xiang wrote:
> > > > This change extends the MigrationStatus interface
Am 06.02.2024 um 16:31 hat Stefan Hajnoczi geschrieben:
> 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:
>
Hi Inès,
(this is now commit 52671f69f7).
On 9/1/24 17:06, Inès Varhol wrote:
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Signed-off-by: Arnaud Minier
Signed-off-by: Inès Varhol
---
hw/arm/Kconfig | 1 +
hw/arm/stm
From: Stefan Hajnoczi
Hanna Czenczek noted that the array index in
virtio_blk_dma_restart_cb() is not bounds-checked:
g_autofree VirtIOBlockReq **vq_rq = g_new0(VirtIOBlockReq *, num_queues);
...
while (rq) {
VirtIOBlockReq *next = rq->next;
uint16_t idx = virtio_get_queue_ind
From: Hanna Czenczek
Since AioContext locks have been removed, a BlockBackend's AioContext
may really change at any time (only exception is that it is often
confined to a drained section, as noted in this patch). Therefore,
blk_get_aio_context() cannot rely on its root node's context always
matc
usb-storage is for the most part just a wrapper around an internally
created scsi-disk device. It uses DEFINE_BLOCK_PROPERTIES() to offer all
of the usual block device properties to the user, but then only forwards
a few select properties to the internal device while the rest is
silently ignored.
From: Daniel P. Berrangé
If something goes wrong causing the iotests not to cleanup their
temporary directory, it is useful if the dir had an identifying
name to show what is to blame.
Signed-off-by: Daniel P. Berrangé
Message-ID: <20240205155158.1843304-1-berra...@redhat.com>
Revieved-by: Mich
From: Stefan Hajnoczi
Hanna Czenczek noticed that the safety of
`vq_aio_context[vq->value] = ctx;` with user-defined vq->value inputs is
not obvious.
The code is structured in validate() + apply() steps so input validation
is there, but it happens way earlier and there is nothing that
guarantee
From: Stefan Hajnoczi
QEMU's coding style generally forbids C99 mixed declarations.
Signed-off-by: Stefan Hajnoczi
Message-ID: <20240206140410.65650-1-stefa...@redhat.com>
Reviewed-by: Hanna Czenczek
Reviewed-by: Kevin Wolf
Acked-by: Michael S. Tsirkin
Signed-off-by: Kevin Wolf
---
hw/bloc
From: Stefan Hajnoczi
The aio_co_reschedule_self() API is designed to avoid the race
condition between scheduling the coroutine in another AioContext and
yielding.
The QMP dispatch code uses the open-coded version that appears
susceptible to the race condition at first glance:
aio_co_schedule
From: Stefan Hajnoczi
The VirtIOBlock::rq field has had the type void * since its introduction
in commit 869a5c6df19a ("Stop VM on error in virtio-blk. (Gleb
Natapov)").
Perhaps this was done to avoid the forward declaration of
VirtIOBlockReq.
Hanna Czenczek pointed out the missing type. Speci
blkio_alloc_mem_region() requires that the requested buffer size is a
multiple of the memory-alignment property. If it isn't, the allocation
fails with a return value of -EINVAL.
Fix the call in blkio_resize_bounce_pool() to make sure the requested
size is properly aligned.
I observed this proble
From: Hanna Czenczek
scsi_device_for_each_req_async() currently does not provide any way to
be awaited. One of its callers is scsi_device_purge_requests(), which
therefore currently does not guarantee that all requests are fully
settled when it returns.
We want all requests to be settled, becau
From: Stefan Hajnoczi
Requests that complete in an IOThread use irqfd to notify the guest
while requests that complete in the main loop thread use the traditional
qdev irq code path. The reason for this conditional is that the irq code
path requires the BQL:
if (s->ioeventfd_started && !s->ioe
From: Hanna Czenczek
Commit d3f6f294aeadd5f88caf0155e4360808c95b3146 ("virtio-blk: always set
ioeventfd during startup") has made virtio_blk_start_ioeventfd() always
kick the virtqueue (set the ioeventfd), regardless of whether the BB is
drained. That is no longer necessary, because attaching th
From: Stefan Hajnoczi
It is not possible to instantiate a virtio-blk device with 0 virtqueues.
The following check is located in ->realize():
if (!conf->num_queues) {
error_setg(errp, "num-queues property must be larger than 0");
return;
}
Later on we access s->vq_aio_context[0]
From: Hanna Czenczek
During drain, we do not care about virtqueue notifications, which is why
we remove the handlers on it. When removing those handlers, whether vq
notifications are enabled or not depends on whether we were in polling
mode or not; if not, they are enabled (by default); if so, t
From: Daniel P. Berrangé
Creating an instance of the 'TestEnv' class will create a temporary
directory. This dir is only deleted, however, in the __exit__ handler
invoked by a context manager.
In dry-run mode, we don't use the TestEnv via a context manager, so
were leaking the temporary director
From: Hanna Czenczek
As of commit 38738f7dbbda90fbc161757b7f4be35b52205552 ("virtio-scsi:
don't waste CPU polling the event virtqueue"), we only attach an io_read
notifier for the virtio-scsi event virtqueue instead, and no polling
notifiers. During operation, the event virtqueue is typically
no
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:
https://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to fe
07.02.2024 20:20, Tianlan Zhou :
In `qemu_console_resize()`, the old surface of the console is keeped if the new
console size is the same as the old one. If the old surface is a placeholder,
and the new size of console is the same as the placeholder surface (640*480),
the surface won't be replace
[[ I dont know if it's too late ]]
On Mon, Jan 29, 2024 at 9:48 AM Philippe Mathieu-Daudé
wrote:
> Mechanical patch produced running the command documented
> in scripts/coccinelle/cpu_env.cocci_template header.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> bsd-user/signal.c | 3 +--
> li
Am 22.01.2024 um 18:26 hat Stefan Hajnoczi geschrieben:
> Requests that complete in an IOThread use irqfd to notify the guest
> while requests that complete in the main loop thread use the traditional
> qdev irq code path. The reason for this conditional is that the irq code
> path requires the BQL
Am 02.02.2024 um 16:31 hat Hanna Czenczek geschrieben:
> Hanna Czenczek (3):
> virtio-scsi: Attach event vq notifier with no_poll
> virtio: Re-enable notifications after drain
> virtio-blk: Use ioeventfd_attach in start_ioeventfd
>
> include/block/aio.h | 7 ++-
> hw/block/virtio-blk
Hi Jamin,
On 7/2/24 20:52, Jamin Lin via 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 initi
On 7/2/24 14:33, Cédric Le Goater wrote:
This will help detect issues regarding I/O channels usage.
English isn't my native language but I'd expect "detecting" here.
Signed-off-by: Cédric Le Goater
---
migration/qemu-file.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Revie
On 7/2/24 14:33, Cédric Le Goater wrote:
vfio_set_migration_error() sets the 'return' error on the migration
stream if a migration is in progress. To improve error reporting, add
a new Error* argument to also set the Error object on the migration
stream.
Signed-off-by: Cédric Le Goater
---
hw
On 7/2/24 14:33, Cédric Le Goater wrote:
Use vmstate_save_state_with_err() to improve error reporting in the
callers.
Signed-off-by: Cédric Le Goater
---
include/hw/vfio/vfio-common.h | 2 +-
hw/vfio/migration.c | 18 --
hw/vfio/pci.c | 5 +++--
On 7/2/24 14:33, Cédric Le Goater wrote:
Add an Error** argument to vfio_migration_set_state() and adjust
callers, including vfio_save_setup(). The error will be propagated up
to qemu_savevm_state_setup() where the save_setup() handler is
executed.
Signed-off-by: Cédric Le Goater
---
hw/vfio/
On 7/2/24 14:33, Cédric Le Goater wrote:
This improves error reporting in the log_global_stop() VFIO handler.
Signed-off-by: Cédric Le Goater
---
hw/vfio/common.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On 7/2/24 14:33, Cédric Le Goater wrote:
This allows to update the Error argument of the VFIO log_global_start()
handler. Errors detected when device level logging is started will be
propagated up to qemu_savevm_state_setup() when the ram save_setup()
handler is executed.
The vfio_set_migration_
On 7/2/24 14:33, Cédric Le Goater wrote:
We will use the Error object to improve error reporting in the
.log_global*() handlers of VFIO.
Signed-off-by: Cédric Le Goater
---
include/hw/vfio/vfio-container-base.h | 4 ++--
hw/vfio/common.c | 4 ++--
hw/vfio/container-base
On 7/2/24 14:33, Cédric Le Goater wrote:
The .save_setup() handler has now an Error** argument that we can use
to propagate errors reported by the .log_global_start() handler. Do
that for the RAM. qemu_savevm_state_setup() will store the error under
the migration stream for later detection in the
On 7/2/24 14:33, Cédric Le Goater wrote:
This will be useful to report errors at a higher level, mostly in VFIO
today.
Signed-off-by: Cédric Le Goater
---
include/migration/register.h | 2 +-
hw/vfio/migration.c | 2 +-
migration/ram.c | 2 +-
migration/savevm.c
On 7/2/24 14:33, Cédric Le Goater wrote:
The purpose is to record a potential error in the migration stream if
qemu_savevm_state_setup() fails. Most of the current .save_setup()
handlers can be modified to use the Error argument instead of managing
their own and calling locally error_report(). Th
Hi Richard,
On 2/6/24 11:52 PM, Richard Henderson wrote:
Changes for v3:
- As if /sys/devices/system/cpu/cpu/mte_tcf_preferred is "sync".
- Fix do_st_zpa as well as do_ld_zpa. Oops.
Because of the above, I dropped Gustavo's t-b.
r~
Richard Henderson (6):
linux-user/aarch64: Choose
On 7/2/24 17:38, Alex Bennée wrote:
From: Ilya Leoshkevich
The upcoming syscall catchpoint support needs to send SIGTRAP stop
packets to GDB. Being able to compile this support only once for all
targets is a good thing, and it requires hiding TARGET_SIGTRAP behind
a function call.
Signed-off-b
On 2/6/24 11:52 PM, Richard Henderson wrote:
The API does not generate an error for setting ASYNC | SYNC; that merely
constrains the selection vs the per-cpu default. For qemu linux-user,
choose SYNC as the default.
Cc: qemu-sta...@nongnu.org
Reported-by: Gustavo Romero
Signed-off-by: Richar
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, then, CPUs(cortex-a35)
execute u-boot,
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 models
in sync with the datasheet, let's introduce a new U
1 - 100 of 266 matches
Mail list logo
