From: "manish.mishra"
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a
From: "manish.mishra"
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a
"manish.mishra" wrote:
> Hi Everyone,
>
> I was just checking if it was not missed in holidays and was received. :)
Queued.
Sorry for the delay.
"manish.mishra" wrote:
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the main channel followed by the multifid or post-copy
> preemption channel. This may not be always true, as e
On 31/01/23 8:47 pm, Peter Xu wrote:
On Tue, Jan 31, 2023 at 08:29:08PM +0530, manish.mishra wrote:
Hi Peter, Daniel,
Just a gentle reminder on this patch if it can be merged, and really
sorry i see now earlier reminders i sent were on v6[0/2] and somehow you
were not CCed on that earlier. Yo
On Tue, Jan 31, 2023 at 08:29:08PM +0530, manish.mishra wrote:
> Hi Peter, Daniel,
>
> Just a gentle reminder on this patch if it can be merged, and really
> sorry i see now earlier reminders i sent were on v6[0/2] and somehow you
> were not CCed on that earlier. You were CCed just on v6[1/2] and
K for socket channel
migration: check magic value for deciding the mapping of channels
chardev/char-socket.c | 4 +--
include/io/channel.h| 6
io/channel-buffer.c | 1 +
io/channel-command.c| 1 +
io/channel-f
multifd_load_setup to migration_ioc_process_incoming.
manish.mishra (2):
io: Add support for MSG_PEEK for socket channel
migration: check magic value for deciding the mapping of channels
chardev/char-socket.c | 4 +--
include/io/channel.h| 6
io
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connectio
migration_incoming_setup but if multifd channel is received before
default channel, multifd channels will be uninitialized. Moved
multifd_load_setup to migration_ioc_process_incoming.
manish.mishra (2):
io: Add support for MSG_PEEK for socket channel
migration: check magic value for deciding the
migration_incoming_setup but if multifd channel is received before
default channel, multifd channels will be uninitialized. Moved
multifd_load_setup to migration_ioc_process_incoming.
manish.mishra (2):
io: Add support for MSG_PEEK for socket channel
migration: check magic value for deciding the
On Tue, Dec 13, 2022 at 04:38:47PM -0500, Peter Xu wrote:
> From: "manish.mishra"
>
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the main channel followed by the multifid or pos
From: "manish.mishra"
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a
migration: check magic value for deciding the mapping of channels
chardev/char-socket.c | 4 +--
include/io/channel.h| 6
io/channel-buffer.c | 1 +
io/channel-command.c| 1 +
io/channel-file.c | 1 +
io/channel
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connectio
On 23/11/22 9:57 pm, Peter Xu wrote:
On Wed, Nov 23, 2022 at 09:28:14PM +0530, manish.mishra wrote:
On 23/11/22 9:22 pm, Peter Xu wrote:
On Wed, Nov 23, 2022 at 03:05:27PM +, manish.mishra wrote:
+int migration_channel_read_peek(QIOChannel *ioc,
+const cha
On Wed, Nov 23, 2022 at 09:28:14PM +0530, manish.mishra wrote:
>
> On 23/11/22 9:22 pm, Peter Xu wrote:
> > On Wed, Nov 23, 2022 at 03:05:27PM +, manish.mishra wrote:
> > > +int migration_channel_read_peek(QIOChannel *ioc,
> > > +const char *buf,
> > > +
On Wed, Nov 23, 2022 at 09:34:35PM +0530, manish.mishra wrote:
>
> On 23/11/22 9:28 pm, Daniel P. Berrangé wrote:
> > On Wed, Nov 23, 2022 at 03:05:27PM +, manish.mishra wrote:
> > > Current logic assumes that channel connections on the destination side are
> > > always established in the same
On 23/11/22 9:28 pm, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 03:05:27PM +, manish.mishra wrote:
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed
On 23/11/22 9:22 pm, Peter Xu wrote:
On Wed, Nov 23, 2022 at 03:05:27PM +, manish.mishra wrote:
+int migration_channel_read_peek(QIOChannel *ioc,
+const char *buf,
+const size_t buflen,
+Error *
On Wed, Nov 23, 2022 at 03:05:27PM +, manish.mishra wrote:
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the main channel followed by the multifid or post-copy
> preemption cha
On Wed, Nov 23, 2022 at 03:05:27PM +, manish.mishra wrote:
> +int migration_channel_read_peek(QIOChannel *ioc,
> +const char *buf,
> +const size_t buflen,
> +Error **errp)
> +{
> + ssize_t len = 0;
peek and added one
specific to live migration.
2. Updated to use qemu_co_sleep_ns instead of qio_channel_yield.
3. Some other minor fixes.
manish.mishra (2):
io: Add support for MSG_PEEK for socket channel
migration: check magic value for deciding the mapping of channels
chardev/char
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connectio
On Sat, Nov 19, 2022 at 09:36:15AM +, manish.mishra wrote:
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the main channel followed by the multifid or post-copy
> preemption cha
On Sat, Nov 19, 2022 at 09:36:15AM +, manish.mishra wrote:
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the main channel followed by the multifid or post-copy
> preemption cha
minor fixes.
manish.mishra (2):
io: Add support for MSG_PEEK for socket channel
migration: check magic value for deciding the mapping of channels
chardev/char-socket.c | 4 +-
include/io/channel.h| 83 +
io/channel-buffer.c
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connectio
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connectio
On 16/11/22 4:57 pm, Daniel P. Berrangé wrote:
On Wed, Nov 16, 2022 at 04:49:18PM +0530, manish.mishra wrote:
On 16/11/22 12:20 am, Daniel P. Berrangé wrote:
On Tue, Nov 15, 2022 at 06:11:30PM +, Daniel P. Berrangé wrote:
On Mon, Nov 07, 2022 at 04:51:59PM +, manish.mishra wrote:
Cu
On Wed, Nov 16, 2022 at 04:49:18PM +0530, manish.mishra wrote:
>
> On 16/11/22 12:20 am, Daniel P. Berrangé wrote:
> > On Tue, Nov 15, 2022 at 06:11:30PM +, Daniel P. Berrangé wrote:
> > > On Mon, Nov 07, 2022 at 04:51:59PM +, manish.mishra wrote:
> > > > Current logic assumes that channel
On 16/11/22 12:20 am, Daniel P. Berrangé wrote:
On Tue, Nov 15, 2022 at 06:11:30PM +, Daniel P. Berrangé wrote:
On Mon, Nov 07, 2022 at 04:51:59PM +, manish.mishra wrote:
Current logic assumes that channel connections on the destination side are
always established in the same order as
On Tue, Nov 15, 2022 at 11:29:13PM +0530, manish.mishra wrote:
> > > + while (bytes < nbytes) {
> > > + bytes = klass->io_read_peek(ioc,
> > > + buf,
> > > + nbytes,
> > > + errp);
> > IIUC
On Tue, Nov 15, 2022 at 06:11:30PM +, Daniel P. Berrangé wrote:
> On Mon, Nov 07, 2022 at 04:51:59PM +, manish.mishra wrote:
> > Current logic assumes that channel connections on the destination side are
> > always established in the same order as the source and the first one will
> > alway
On Mon, Nov 07, 2022 at 04:51:59PM +, manish.mishra wrote:
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the main channel followed by the multifid or post-copy
> preemption cha
On 15/11/22 11:06 pm, Peter Xu wrote:
Hi, Manish,
On Mon, Nov 07, 2022 at 04:51:59PM +, manish.mishra wrote:
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel foll
Hi, Manish,
On Mon, Nov 07, 2022 at 04:51:59PM +, manish.mishra wrote:
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the main channel followed by the multifid or post-copy
> p
From: "manish.mishra"
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a
From: "manish.mishra"
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a
Thanks Peter
On 14/11/22 10:21 pm, Peter Xu wrote:
Manish,
On Thu, Nov 03, 2022 at 11:47:51PM +0530, manish.mishra wrote:
Yes, but if we try to read early on main channel with tls enabled case it is an
issue. Sorry i may not have put above comment cleary. I will try to put
scenario step wise
Manish,
On Thu, Nov 03, 2022 at 11:47:51PM +0530, manish.mishra wrote:
> Yes, but if we try to read early on main channel with tls enabled case it is
> an issue. Sorry i may not have put above comment cleary. I will try to put
> scenario step wise.
> 1. main channel is created and tls handshake
On 11/11/22 4:17 am, Peter Xu wrote:
On Thu, Nov 10, 2022 at 05:59:45PM +0530, manish.mishra wrote:
Hi Everyone, Just a gentle reminder for review. :)
Hi, Manish,
I've got a slightly busy week, sorry! If Daniel and Juan won't have time
to look at it I'll have a closer look at it next Monday
On Thu, Nov 10, 2022 at 05:59:45PM +0530, manish.mishra wrote:
> Hi Everyone, Just a gentle reminder for review. :)
Hi, Manish,
I've got a slightly busy week, sorry! If Daniel and Juan won't have time
to look at it I'll have a closer look at it next Monday (holiday tomorrow).
--
Peter Xu
Hi Everyone, Just a gentle reminder for review. :)
Thanks
Manish Mishra
On 07/11/22 10:21 pm, manish.mishra wrote:
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel fol
On 07/11/22 10:21 pm, manish.mishra wrote:
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be al
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connectio
On 03/11/22 11:47 pm, manish.mishra wrote:
On 03/11/22 11:27 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 11:06:23PM +0530, manish.mishra wrote:
On 03/11/22 10:57 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 10:04:54PM +0530, manish.mishra wrote:
On 03/11/22 2:59 pm, Dani
On 03/11/22 11:47 pm, manish.mishra wrote:
On 03/11/22 11:27 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 11:06:23PM +0530, manish.mishra wrote:
On 03/11/22 10:57 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 10:04:54PM +0530, manish.mishra wrote:
On 03/11/22 2:59 pm, Dani
On 03/11/22 11:27 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 11:06:23PM +0530, manish.mishra wrote:
On 03/11/22 10:57 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 10:04:54PM +0530, manish.mishra wrote:
On 03/11/22 2:59 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 a
On Thu, Nov 03, 2022 at 11:06:23PM +0530, manish.mishra wrote:
>
> On 03/11/22 10:57 pm, Daniel P. Berrangé wrote:
> > On Thu, Nov 03, 2022 at 10:04:54PM +0530, manish.mishra wrote:
> > > On 03/11/22 2:59 pm, Daniel P. Berrangé wrote:
> > > > On Thu, Nov 03, 2022 at 02:50:25PM +0530, manish.mishra
On 03/11/22 10:57 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 10:04:54PM +0530, manish.mishra wrote:
On 03/11/22 2:59 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 02:50:25PM +0530, manish.mishra wrote:
On 01/11/22 9:15 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at
On Thu, Nov 03, 2022 at 10:04:54PM +0530, manish.mishra wrote:
>
> On 03/11/22 2:59 pm, Daniel P. Berrangé wrote:
> > On Thu, Nov 03, 2022 at 02:50:25PM +0530, manish.mishra wrote:
> > > On 01/11/22 9:15 pm, Daniel P. Berrangé wrote:
> > > > On Tue, Nov 01, 2022 at 09:10:14PM +0530, manish.mishra
On 03/11/22 2:59 pm, Daniel P. Berrangé wrote:
On Thu, Nov 03, 2022 at 02:50:25PM +0530, manish.mishra wrote:
On 01/11/22 9:15 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at 09:10:14PM +0530, manish.mishra wrote:
On 01/11/22 8:21 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at 0
On Thu, Nov 03, 2022 at 02:50:25PM +0530, manish.mishra wrote:
>
> On 01/11/22 9:15 pm, Daniel P. Berrangé wrote:
> > On Tue, Nov 01, 2022 at 09:10:14PM +0530, manish.mishra wrote:
> > > On 01/11/22 8:21 pm, Daniel P. Berrangé wrote:
> > > > On Tue, Nov 01, 2022 at 02:30:29PM +, manish.mishra
On 01/11/22 9:15 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at 09:10:14PM +0530, manish.mishra wrote:
On 01/11/22 8:21 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at 02:30:29PM +, manish.mishra wrote:
Current logic assumes that channel connections on the destination side a
On Tue, Nov 01, 2022 at 09:10:14PM +0530, manish.mishra wrote:
>
> On 01/11/22 8:21 pm, Daniel P. Berrangé wrote:
> > On Tue, Nov 01, 2022 at 02:30:29PM +, manish.mishra wrote:
> > > Current logic assumes that channel connections on the destination side are
> > > always established in the same
On 01/11/22 9:15 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at 09:10:14PM +0530, manish.mishra wrote:
On 01/11/22 8:21 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at 02:30:29PM +, manish.mishra wrote:
Current logic assumes that channel connections on the destination side a
On Tue, Nov 01, 2022 at 02:30:29PM +, manish.mishra wrote:
> Current logic assumes that channel connections on the destination side are
> always established in the same order as the source and the first one will
> always be the default channel followed by the multifid or post-copy
> preemption
On 01/11/22 8:21 pm, Daniel P. Berrangé wrote:
On Tue, Nov 01, 2022 at 02:30:29PM +, manish.mishra wrote:
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the default channel follo
Sorry for late patch on this. I mentioned i will send it last week itself, but
later reliased it was festival week in India, so was mostly holidays.
Thanks
Manish Mishra
On 01/11/22 8:00 pm, manish.mishra wrote:
Current logic assumes that channel connections on the destination side are
always
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the default channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connec
61 matches
Mail list logo
