Drivers: hv: Support the newly introduced KVP messages in the driver

Support the newly defined KVP message types. It turns out that the host
pushes a set of standard key value pairs as soon as the guest opens the KVP channel.
Since we cannot handle these tuples until the user level daemon loads up, defer
reading the KVP channel until the user level daemon is launched.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

1 files changed, 7 insertions, 0 deletions

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 00d3f7c099e0..a98878c874be 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -389,10 +389,16 @@ int main(void)
                         }
                         continue;
 
+                case KVP_OP_SET:
+                case KVP_OP_GET:
+                case KVP_OP_DELETE:
                 default:
                         break;
                 }
 
+                if (hv_msg->kvp_hdr.operation != KVP_OP_ENUMERATE)
+                        goto kvp_done;
+
                 hv_msg = (struct hv_kvp_msg *)incoming_cn_msg->data;
                 key_name = (char *)hv_msg->body.kvp_enum_data.data.key;
                 key_value = (char *)hv_msg->body.kvp_enum_data.data.value;
@@ -454,6 +460,7 @@ int main(void)
                  * already in the receive buffer. Update the cn_msg header to
                  * reflect the key value that has been added to the message
                  */
+kvp_done:
 
                 incoming_cn_msg->id.idx = CN_KVP_IDX;
                 incoming_cn_msg->id.val = CN_KVP_VAL;