On Tue, Dec 17, 2024 at 12:15:36AM +0100, Maciej S. Szmigiero wrote:
> On 16.12.2024 17:29, Peter Xu wrote:
> > On Thu, Dec 12, 2024 at 11:53:24PM +0100, Maciej S. Szmigiero wrote:
> > > On 12.12.2024 17:38, Peter Xu wrote:
> > > > On Wed, Dec 11, 2024 at 12:05:23AM +0100, Maciej S. Szmigiero wrote
On 16.12.2024 17:33, Peter Xu wrote:
On Thu, Dec 12, 2024 at 11:53:42PM +0100, Maciej S. Szmigiero wrote:
migrate_set_error() wouldn't be called until qemu_loadvm_state() exits
into process_incoming_migration_co().
Also this does not account other qemu_loadvm_state() callers like
qmp_xen_load_d
On 16.12.2024 17:29, Peter Xu wrote:
On Thu, Dec 12, 2024 at 11:53:24PM +0100, Maciej S. Szmigiero wrote:
On 12.12.2024 17:38, Peter Xu wrote:
On Wed, Dec 11, 2024 at 12:05:23AM +0100, Maciej S. Szmigiero wrote:
Maybe move it over to migration_object_init()? Then we keep
qemu_loadvm_state_set
On Thu, Dec 12, 2024 at 11:53:42PM +0100, Maciej S. Szmigiero wrote:
> migrate_set_error() wouldn't be called until qemu_loadvm_state() exits
> into process_incoming_migration_co().
>
> Also this does not account other qemu_loadvm_state() callers like
> qmp_xen_load_devices_state() or load_snapsho
On Thu, Dec 12, 2024 at 11:53:24PM +0100, Maciej S. Szmigiero wrote:
> On 12.12.2024 17:38, Peter Xu wrote:
> > On Wed, Dec 11, 2024 at 12:05:23AM +0100, Maciej S. Szmigiero wrote:
> > > > Maybe move it over to migration_object_init()? Then we keep
> > > > qemu_loadvm_state_setup() only invoke the
On 12.12.2024 17:55, Peter Xu wrote:
On Wed, Dec 11, 2024 at 12:05:03AM +0100, Maciej S. Szmigiero wrote:
On 4.12.2024 23:43, Peter Xu wrote:
On Thu, Nov 28, 2024 at 01:11:53PM +0100, Maciej S. Szmigiero wrote:
+static int qemu_loadvm_load_thread(void *thread_opaque)
+{
+ struct LoadThreadD
On 12.12.2024 17:38, Peter Xu wrote:
On Wed, Dec 11, 2024 at 12:05:23AM +0100, Maciej S. Szmigiero wrote:
Maybe move it over to migration_object_init()? Then we keep
qemu_loadvm_state_setup() only invoke the load_setup()s.
AFAIK migration_object_init() is called unconditionally
at QEMU startu
On Wed, Dec 11, 2024 at 12:05:03AM +0100, Maciej S. Szmigiero wrote:
> On 4.12.2024 23:43, Peter Xu wrote:
> > On Thu, Nov 28, 2024 at 01:11:53PM +0100, Maciej S. Szmigiero wrote:
> > > > > +static int qemu_loadvm_load_thread(void *thread_opaque)
> > > > > +{
> > > > > + struct LoadThreadData *d
On Wed, Dec 11, 2024 at 12:05:23AM +0100, Maciej S. Szmigiero wrote:
> > Maybe move it over to migration_object_init()? Then we keep
> > qemu_loadvm_state_setup() only invoke the load_setup()s.
>
> AFAIK migration_object_init() is called unconditionally
> at QEMU startup even if there won't me an
On 4.12.2024 23:43, Peter Xu wrote:
On Thu, Nov 28, 2024 at 01:11:53PM +0100, Maciej S. Szmigiero wrote:
+static int qemu_loadvm_load_thread(void *thread_opaque)
+{
+ struct LoadThreadData *data = thread_opaque;
+ int ret;
+
+ ret = data->function(&load_threads_abort, data->opaque);
+
On 5.12.2024 17:15, Peter Xu wrote:
On Wed, Dec 04, 2024 at 05:48:52PM -0500, Peter Xu wrote:
@@ -71,6 +72,10 @@
const unsigned int postcopy_ram_discard_version;
+static ThreadPool *load_threads;
+static int load_threads_ret;
+static bool load_threads_abort;
One thing I forgot to mention in
On 4.12.2024 23:48, Peter Xu wrote:
On Wed, Nov 27, 2024 at 09:16:49PM +0100, Maciej S. Szmigiero wrote:
On 27.11.2024 10:13, Cédric Le Goater wrote:
On 11/17/24 20:20, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads duri
On Wed, Dec 04, 2024 at 05:48:52PM -0500, Peter Xu wrote:
> > > > @@ -71,6 +72,10 @@
> > > > const unsigned int postcopy_ram_discard_version;
> > > > +static ThreadPool *load_threads;
> > > > +static int load_threads_ret;
> > > > +static bool load_threads_abort;
One thing I forgot to mention in
On Wed, Nov 27, 2024 at 09:16:49PM +0100, Maciej S. Szmigiero wrote:
> On 27.11.2024 10:13, Cédric Le Goater wrote:
> > On 11/17/24 20:20, Maciej S. Szmigiero wrote:
> > > From: "Maciej S. Szmigiero"
> > >
> > > Some drivers might want to make use of auxiliary helper threads during VM
> > > state
On Thu, Nov 28, 2024 at 01:11:53PM +0100, Maciej S. Szmigiero wrote:
> > > +static int qemu_loadvm_load_thread(void *thread_opaque)
> > > +{
> > > + struct LoadThreadData *data = thread_opaque;
> > > + int ret;
> > > +
> > > + ret = data->function(&load_threads_abort, data->opaque);
> > >
On 28.11.2024 11:26, Avihai Horon wrote:
On 17/11/2024 21:20, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads during VM
state loading, for example to make sure tha
On 17/11/2024 21:20, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads during VM
state loading, for example to make sure that their blocking (sync) I/O
operations do
On 27.11.2024 10:13, Cédric Le Goater wrote:
On 11/17/24 20:20, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads during VM
state loading, for example to make sure that their blocking (sync) I/O
operations don't block the res
On 11/17/24 20:20, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads during VM
state loading, for example to make sure that their blocking (sync) I/O
operations don't block the rest of the migration process.
Add a migration c
"Maciej S. Szmigiero" writes:
> From: "Maciej S. Szmigiero"
>
> Some drivers might want to make use of auxiliary helper threads during VM
> state loading, for example to make sure that their blocking (sync) I/O
> operations don't block the rest of the migration process.
>
> Add a migration core
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads during VM
state loading, for example to make sure that their blocking (sync) I/O
operations don't block the rest of the migration process.
Add a migration core managed thread pool to facilitate this use c
21 matches
Mail list logo
