[Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[linhaifeng]

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

[Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table

[linhaifeng]

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

Re: [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table

[Gonglei]

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(-)

Re: [Qemu-devel] [PATCH v1 2/2] vhost-user: add reply for set_mem_table

[Linhaifeng]

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

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Michael S. Tsirkin]

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
> 

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Linhaifeng]

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

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Michael S. Tsirkin]

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

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Linhaifeng]

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

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Michael S. Tsirkin]

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

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Linhaifeng]

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

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Linhaifeng]

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

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Linhaifeng]

>>
>> 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?

Re: [Qemu-devel] [PATCH v1 1/2] vhost-user: support SET_MEM_TABLE waite the result of mmap

[Michael S. Tsirkin]

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