* [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap @ 2015-02-10 5:48 linhaifeng 2015-02-10 5:48 ` [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table linhaifeng 2015-02-10 8:46 ` [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap Michael S. Tsirkin 0 siblings, 2 replies; 13+ messages in thread From: linhaifeng @ 2015-02-10 5:48 UTC (permalink / raw) To: qemu-devel; +Cc: arei.gonglei, Linhaifeng, mst From: Linhaifeng <haifeng.lin@huawei.com> Slave should reply to master and set u64 to 0 if mmap all regions success otherwise set u64 to 1. Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> --- docs/specs/vhost-user.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt index 650bb18..c96bf6b 100644 --- a/docs/specs/vhost-user.txt +++ b/docs/specs/vhost-user.txt @@ -171,6 +171,7 @@ Message types Id: 5 Equivalent ioctl: VHOST_SET_MEM_TABLE Master payload: memory regions description + Slave payload: u64 (0:success >0:failed) Sets the memory map regions on the slave so it can translate the vring addresses. In the ancillary data there is an array of file descriptors -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table 2015-02-10 5:48 [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap linhaifeng @ 2015-02-10 5:48 ` linhaifeng 2015-02-10 6:35 ` Gonglei 2015-02-10 8:46 ` [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap Michael S. Tsirkin 1 sibling, 1 reply; 13+ messages in thread From: linhaifeng @ 2015-02-10 5:48 UTC (permalink / raw) To: qemu-devel; +Cc: arei.gonglei, Linhaifeng, mst From: Linhaifeng <haifeng.lin@huawei.com> If u64 is not 0 we should return -1 to tell qemu not going on. Remove some unnecessary '\n' in error_report. Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> --- hw/virtio/vhost-user.c | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index aefe0bb..d69bb33 100644 --- a/hw/virtio/vhost-user.c +++ b/hw/virtio/vhost-user.c @@ -128,7 +128,7 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg) r = qemu_chr_fe_read_all(chr, p, size); if (r != size) { - error_report("Failed to read msg header. Read %d instead of %d.\n", r, + error_report("Failed to read msg header. Read %d instead of %d.", r, size); goto fail; } @@ -136,7 +136,7 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg) /* validate received flags */ if (msg->flags != (VHOST_USER_REPLY_MASK | VHOST_USER_VERSION)) { error_report("Failed to read msg header." - " Flags 0x%x instead of 0x%x.\n", msg->flags, + " Flags 0x%x instead of 0x%x.", msg->flags, VHOST_USER_REPLY_MASK | VHOST_USER_VERSION); goto fail; } @@ -144,7 +144,7 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg) /* validate message size is sane */ if (msg->size > VHOST_USER_PAYLOAD_SIZE) { error_report("Failed to read msg header." - " Size %d exceeds the maximum %zu.\n", msg->size, + " Size %d exceeds the maximum %zu.", msg->size, VHOST_USER_PAYLOAD_SIZE); goto fail; } @@ -155,7 +155,7 @@ static int vhost_user_read(struct vhost_dev *dev, VhostUserMsg *msg) r = qemu_chr_fe_read_all(chr, p, size); if (r != size) { error_report("Failed to read msg payload." - " Read %d instead of %d.\n", r, msg->size); + " Read %d instead of %d.", r, msg->size); goto fail; } } @@ -236,14 +236,14 @@ static int vhost_user_call(struct vhost_dev *dev, unsigned long int request, if (!fd_num) { error_report("Failed initializing vhost-user memory map\n" - "consider using -object memory-backend-file share=on\n"); + "consider using -object memory-backend-file share=on"); return -1; } msg.size = sizeof(m.memory.nregions); msg.size += sizeof(m.memory.padding); msg.size += fd_num * sizeof(VhostUserMemoryRegion); - + need_reply = 1; break; case VHOST_SET_LOG_FD: @@ -280,7 +280,7 @@ static int vhost_user_call(struct vhost_dev *dev, unsigned long int request, } break; default: - error_report("vhost-user trying to send unhandled ioctl\n"); + error_report("vhost-user trying to send unhandled ioctl"); return -1; break; } @@ -296,27 +296,38 @@ static int vhost_user_call(struct vhost_dev *dev, unsigned long int request, if (msg_request != msg.request) { error_report("Received unexpected msg type." - " Expected %d received %d\n", msg_request, msg.request); + " Expected %d received %d", msg_request, msg.request); return -1; } switch (msg_request) { case VHOST_USER_GET_FEATURES: if (msg.size != sizeof(m.u64)) { - error_report("Received bad msg size.\n"); + error_report("Received bad msg size."); return -1; } *((__u64 *) arg) = msg.u64; break; case VHOST_USER_GET_VRING_BASE: if (msg.size != sizeof(m.state)) { - error_report("Received bad msg size.\n"); + error_report("Received bad msg size."); return -1; } memcpy(arg, &msg.state, sizeof(struct vhost_vring_state)); break; + case VHOST_SET_MEM_TABLE: + if (msg.size != sizeof(m.u64)) { + error_report("Received bad msg size."); + return -1; + } else { + if (m.u64) { + error_report("Failed to set memory table."); + return -1; + } + } + break; default: - error_report("Received unexpected msg type.\n"); + error_report("Received unexpected msg type."); return -1; break; } -- 1.7.12.4 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table 2015-02-10 5:48 ` [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table linhaifeng @ 2015-02-10 6:35 ` Gonglei 2015-02-10 6:54 ` Linhaifeng 0 siblings, 1 reply; 13+ messages in thread From: Gonglei @ 2015-02-10 6:35 UTC (permalink / raw) To: linhaifeng, qemu-devel; +Cc: mst On 2015/2/10 13:48, linhaifeng wrote: > From: Linhaifeng <haifeng.lin@huawei.com> > > If u64 is not 0 we should return -1 to tell qemu not going on. > > Remove some unnecessary '\n' in error_report. Hi, haifeng: You'd better split a single patch to do this work, and using '--cover' argument for patch series when git format-patch . :) Regards, -Gonglei > > Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> > --- > hw/virtio/vhost-user.c | 33 ++++++++++++++++++++++----------- > 1 file changed, 22 insertions(+), 11 deletions(-) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table 2015-02-10 6:35 ` Gonglei @ 2015-02-10 6:54 ` Linhaifeng 0 siblings, 0 replies; 13+ messages in thread From: Linhaifeng @ 2015-02-10 6:54 UTC (permalink / raw) To: Gonglei, qemu-devel; +Cc: mst On 2015/2/10 14:35, Gonglei wrote: > On 2015/2/10 13:48, linhaifeng wrote: >> From: Linhaifeng <haifeng.lin@huawei.com> >> >> If u64 is not 0 we should return -1 to tell qemu not going on. >> >> Remove some unnecessary '\n' in error_report. > Hi, haifeng: > > You'd better split a single patch to do this work, > and using '--cover' argument for patch series when git format-patch . :) > good idea! > Regards, > -Gonglei >> >> Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> >> --- >> hw/virtio/vhost-user.c | 33 ++++++++++++++++++++++----------- >> 1 file changed, 22 insertions(+), 11 deletions(-) > > > > . > -- Regards, Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 5:48 [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap linhaifeng 2015-02-10 5:48 ` [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table linhaifeng @ 2015-02-10 8:46 ` Michael S. Tsirkin 2015-02-10 10:27 ` Linhaifeng 1 sibling, 1 reply; 13+ messages in thread From: Michael S. Tsirkin @ 2015-02-10 8:46 UTC (permalink / raw) To: linhaifeng; +Cc: arei.gonglei, qemu-devel On Tue, Feb 10, 2015 at 01:48:12PM +0800, linhaifeng wrote: > From: Linhaifeng <haifeng.lin@huawei.com> > > Slave should reply to master and set u64 to 0 if > mmap all regions success otherwise set u64 to 1. > > Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> How does this work with existig slaves though? > --- > docs/specs/vhost-user.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt > index 650bb18..c96bf6b 100644 > --- a/docs/specs/vhost-user.txt > +++ b/docs/specs/vhost-user.txt > @@ -171,6 +171,7 @@ Message types > Id: 5 > Equivalent ioctl: VHOST_SET_MEM_TABLE > Master payload: memory regions description > + Slave payload: u64 (0:success >0:failed) > > Sets the memory map regions on the slave so it can translate the vring > addresses. In the ancillary data there is an array of file descriptors > -- > 1.7.12.4 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 8:46 ` [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap Michael S. Tsirkin @ 2015-02-10 10:27 ` Linhaifeng 2015-02-10 10:41 ` Michael S. Tsirkin 0 siblings, 1 reply; 13+ messages in thread From: Linhaifeng @ 2015-02-10 10:27 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: arei.gonglei, qemu-devel On 2015/2/10 16:46, Michael S. Tsirkin wrote: > On Tue, Feb 10, 2015 at 01:48:12PM +0800, linhaifeng wrote: >> From: Linhaifeng <haifeng.lin@huawei.com> >> >> Slave should reply to master and set u64 to 0 if >> mmap all regions success otherwise set u64 to 1. >> >> Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> > > How does this work with existig slaves though? > Slaves should work like this: int set_mem_table(...) { .... for (idx = 0, i = 0; idx < memory.nregions; idx++) { .... mem = mmap(..); if (MAP_FAILED == mem) { msg->msg.u64 = 1; msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); return 1; } } .... msg->msg.u64 = 0; msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); return 1; } If slaves not reply QEMU will always wait. >> --- >> docs/specs/vhost-user.txt | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt >> index 650bb18..c96bf6b 100644 >> --- a/docs/specs/vhost-user.txt >> +++ b/docs/specs/vhost-user.txt >> @@ -171,6 +171,7 @@ Message types >> Id: 5 >> Equivalent ioctl: VHOST_SET_MEM_TABLE >> Master payload: memory regions description >> + Slave payload: u64 (0:success >0:failed) >> >> Sets the memory map regions on the slave so it can translate the vring >> addresses. In the ancillary data there is an array of file descriptors >> -- >> 1.7.12.4 >> > > -- Regards, Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 10:27 ` Linhaifeng @ 2015-02-10 10:41 ` Michael S. Tsirkin 2015-02-10 11:59 ` Linhaifeng 0 siblings, 1 reply; 13+ messages in thread From: Michael S. Tsirkin @ 2015-02-10 10:41 UTC (permalink / raw) To: Linhaifeng; +Cc: arei.gonglei, qemu-devel On Tue, Feb 10, 2015 at 06:27:04PM +0800, Linhaifeng wrote: > > > On 2015/2/10 16:46, Michael S. Tsirkin wrote: > > On Tue, Feb 10, 2015 at 01:48:12PM +0800, linhaifeng wrote: > >> From: Linhaifeng <haifeng.lin@huawei.com> > >> > >> Slave should reply to master and set u64 to 0 if > >> mmap all regions success otherwise set u64 to 1. > >> > >> Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> > > > > How does this work with existig slaves though? > > > > Slaves should work like this: > > int set_mem_table(...) > { > .... > for (idx = 0, i = 0; idx < memory.nregions; idx++) { > .... > mem = mmap(..); > if (MAP_FAILED == mem) { > msg->msg.u64 = 1; > msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); > return 1; > } > } > > .... > > msg->msg.u64 = 0; > msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); > return 1; > } > > If slaves not reply QEMU will always wait. Are you sure existing slaves reply? > >> --- > >> docs/specs/vhost-user.txt | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt > >> index 650bb18..c96bf6b 100644 > >> --- a/docs/specs/vhost-user.txt > >> +++ b/docs/specs/vhost-user.txt > >> @@ -171,6 +171,7 @@ Message types > >> Id: 5 > >> Equivalent ioctl: VHOST_SET_MEM_TABLE > >> Master payload: memory regions description > >> + Slave payload: u64 (0:success >0:failed) > >> > >> Sets the memory map regions on the slave so it can translate the vring > >> addresses. In the ancillary data there is an array of file descriptors > >> -- > >> 1.7.12.4 > >> > > > > > > -- > Regards, > Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 10:41 ` Michael S. Tsirkin @ 2015-02-10 11:59 ` Linhaifeng 2015-02-10 12:04 ` Michael S. Tsirkin 0 siblings, 1 reply; 13+ messages in thread From: Linhaifeng @ 2015-02-10 11:59 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: arei.gonglei, qemu-devel On 2015/2/10 18:41, Michael S. Tsirkin wrote: > On Tue, Feb 10, 2015 at 06:27:04PM +0800, Linhaifeng wrote: >> >> >> On 2015/2/10 16:46, Michael S. Tsirkin wrote: >>> On Tue, Feb 10, 2015 at 01:48:12PM +0800, linhaifeng wrote: >>>> From: Linhaifeng <haifeng.lin@huawei.com> >>>> >>>> Slave should reply to master and set u64 to 0 if >>>> mmap all regions success otherwise set u64 to 1. >>>> >>>> Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> >>> >>> How does this work with existig slaves though? >>> >> >> Slaves should work like this: >> >> int set_mem_table(...) >> { >> .... >> for (idx = 0, i = 0; idx < memory.nregions; idx++) { >> .... >> mem = mmap(..); >> if (MAP_FAILED == mem) { >> msg->msg.u64 = 1; >> msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); >> return 1; >> } >> } >> >> .... >> >> msg->msg.u64 = 0; >> msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); >> return 1; >> } >> >> If slaves not reply QEMU will always wait. > > Are you sure existing slaves reply? No.May be the existing slaves need add reply in their codes. > >>>> --- >>>> docs/specs/vhost-user.txt | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt >>>> index 650bb18..c96bf6b 100644 >>>> --- a/docs/specs/vhost-user.txt >>>> +++ b/docs/specs/vhost-user.txt >>>> @@ -171,6 +171,7 @@ Message types >>>> Id: 5 >>>> Equivalent ioctl: VHOST_SET_MEM_TABLE >>>> Master payload: memory regions description >>>> + Slave payload: u64 (0:success >0:failed) >>>> >>>> Sets the memory map regions on the slave so it can translate the vring >>>> addresses. In the ancillary data there is an array of file descriptors >>>> -- >>>> 1.7.12.4 >>>> >>> >>> >> >> -- >> Regards, >> Haifeng > > . > -- Regards, Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 11:59 ` Linhaifeng @ 2015-02-10 12:04 ` Michael S. Tsirkin 2015-02-11 1:38 ` Linhaifeng ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Michael S. Tsirkin @ 2015-02-10 12:04 UTC (permalink / raw) To: Linhaifeng; +Cc: arei.gonglei, qemu-devel On Tue, Feb 10, 2015 at 07:59:16PM +0800, Linhaifeng wrote: > > > On 2015/2/10 18:41, Michael S. Tsirkin wrote: > > On Tue, Feb 10, 2015 at 06:27:04PM +0800, Linhaifeng wrote: > >> > >> > >> On 2015/2/10 16:46, Michael S. Tsirkin wrote: > >>> On Tue, Feb 10, 2015 at 01:48:12PM +0800, linhaifeng wrote: > >>>> From: Linhaifeng <haifeng.lin@huawei.com> > >>>> > >>>> Slave should reply to master and set u64 to 0 if > >>>> mmap all regions success otherwise set u64 to 1. > >>>> > >>>> Signed-off-by: Linhaifeng <haifeng.lin@huawei.com> > >>> > >>> How does this work with existig slaves though? > >>> > >> > >> Slaves should work like this: > >> > >> int set_mem_table(...) > >> { > >> .... > >> for (idx = 0, i = 0; idx < memory.nregions; idx++) { > >> .... > >> mem = mmap(..); > >> if (MAP_FAILED == mem) { > >> msg->msg.u64 = 1; > >> msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); > >> return 1; > >> } > >> } > >> > >> .... > >> > >> msg->msg.u64 = 0; > >> msg->msg.size = MEMB_SIZE(VhostUserMsg, u64); > >> return 1; > >> } > >> > >> If slaves not reply QEMU will always wait. > > > > Are you sure existing slaves reply? > > No.May be the existing slaves need add reply in their codes. So that's not good. We need a way to negotiate the capability, we can't just deadlock with legacy slaves. > > > >>>> --- > >>>> docs/specs/vhost-user.txt | 1 + > >>>> 1 file changed, 1 insertion(+) > >>>> > >>>> diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt > >>>> index 650bb18..c96bf6b 100644 > >>>> --- a/docs/specs/vhost-user.txt > >>>> +++ b/docs/specs/vhost-user.txt > >>>> @@ -171,6 +171,7 @@ Message types > >>>> Id: 5 > >>>> Equivalent ioctl: VHOST_SET_MEM_TABLE > >>>> Master payload: memory regions description > >>>> + Slave payload: u64 (0:success >0:failed) > >>>> > >>>> Sets the memory map regions on the slave so it can translate the vring > >>>> addresses. In the ancillary data there is an array of file descriptors > >>>> -- > >>>> 1.7.12.4 > >>>> > >>> > >>> > >> > >> -- > >> Regards, > >> Haifeng > > > > . > > > > -- > Regards, > Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 12:04 ` Michael S. Tsirkin @ 2015-02-11 1:38 ` Linhaifeng 2015-02-12 16:38 ` Michael S. Tsirkin 2015-02-11 6:30 ` Linhaifeng 2015-02-12 3:25 ` Linhaifeng 2 siblings, 1 reply; 13+ messages in thread From: Linhaifeng @ 2015-02-11 1:38 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: arei.gonglei, qemu-devel On 2015/2/10 20:04, Michael S. Tsirkin wrote: > So that's not good. We need a way to negotiate the capability, > we can't just deadlock with legacy slaves. Should we wait many seconds if slave not reply we just return error? -- Regards, Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-11 1:38 ` Linhaifeng @ 2015-02-12 16:38 ` Michael S. Tsirkin 0 siblings, 0 replies; 13+ messages in thread From: Michael S. Tsirkin @ 2015-02-12 16:38 UTC (permalink / raw) To: Linhaifeng; +Cc: arei.gonglei, qemu-devel On Wed, Feb 11, 2015 at 09:38:34AM +0800, Linhaifeng wrote: > > > On 2015/2/10 20:04, Michael S. Tsirkin wrote: > > So that's not good. We need a way to negotiate the capability, > > we can't just deadlock with legacy slaves. > > Should we wait many seconds if slave not reply we just return error? I would prefer something more robust. Isn't there a version field we can use? > -- > Regards, > Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 12:04 ` Michael S. Tsirkin 2015-02-11 1:38 ` Linhaifeng @ 2015-02-11 6:30 ` Linhaifeng 2015-02-12 3:25 ` Linhaifeng 2 siblings, 0 replies; 13+ messages in thread From: Linhaifeng @ 2015-02-11 6:30 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: arei.gonglei, qemu-devel On 2015/2/10 20:04, Michael S. Tsirkin wrote: > So that's not good. We need a way to negotiate the capability, > we can't just deadlock with legacy slaves. Or add a new message to query slaves' version if slaves not reply we don't wait otherwise if the version as same as QEMU we wait the reply. Mostly the same as iotcl may be all messages need reply. -- Regards, Haifeng ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap 2015-02-10 12:04 ` Michael S. Tsirkin 2015-02-11 1:38 ` Linhaifeng 2015-02-11 6:30 ` Linhaifeng @ 2015-02-12 3:25 ` Linhaifeng 2 siblings, 0 replies; 13+ messages in thread From: Linhaifeng @ 2015-02-12 3:25 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: arei.gonglei, qemu-devel >> >> No.May be the existing slaves need add reply in their codes. > > So that's not good. We need a way to negotiate the capability, > we can't just deadlock with legacy slaves. > Hi,Michael Do you have any suggestions? ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-02-12 16:38 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-10 5:48 [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap linhaifeng 2015-02-10 5:48 ` [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table linhaifeng 2015-02-10 6:35 ` Gonglei 2015-02-10 6:54 ` Linhaifeng 2015-02-10 8:46 ` [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap Michael S. Tsirkin 2015-02-10 10:27 ` Linhaifeng 2015-02-10 10:41 ` Michael S. Tsirkin 2015-02-10 11:59 ` Linhaifeng 2015-02-10 12:04 ` Michael S. Tsirkin 2015-02-11 1:38 ` Linhaifeng 2015-02-12 16:38 ` Michael S. Tsirkin 2015-02-11 6:30 ` Linhaifeng 2015-02-12 3:25 ` Linhaifeng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.