Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1369984 > unrolled thread

[PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management.

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management.  "K. Y. Srinivasan" <kys@microsoft.com> - 2016-04-02 18:40 +0200
    [PATCH 1/6] Drivers: hv: kvp: fix IP Failover "K. Y. Srinivasan" <kys@microsoft.com> - 2016-04-02 18:40 +0200
      [PATCH 5/6] hv: Reverse order of resources in hyperv_mmio "K. Y. Srinivasan" <kys@microsoft.com> - 2016-04-02 18:40 +0200
      [PATCH 6/6] hv: Track allocations of children of hv_vmbus in private resource tree "K. Y. Srinivasan" <kys@microsoft.com> - 2016-04-02 18:40 +0200
      [PATCH 3/6] hv: Lock access to hyperv_mmio resource tree "K. Y. Srinivasan" <kys@microsoft.com> - 2016-04-02 18:40 +0200
    Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management. Greg KH <gregkh@linuxfoundation.org> - 2016-04-03 00:30 +0200
      RE: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management. KY Srinivasan <kys@microsoft.com> - 2016-04-03 01:50 +0200
        Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management. Greg KH <gregkh@linuxfoundation.org> - 2016-04-03 03:50 +0200
          RE: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management. KY Srinivasan <kys@microsoft.com> - 2016-04-03 07:20 +0200
            RE: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management. KY Srinivasan <kys@microsoft.com> - 2016-04-04 16:40 +0200
    Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management. Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-04-04 13:10 +0200

#1369984 — [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio management.

Cleanup and mmio management. Also included is a patch
to fix an issue in KVP.

Jake Oshins (5):
  hv: Make a function to free mmio regions through vmbus
  hv: Lock access to hyperv_mmio resource tree
  hv: Use new vmbus_mmio_free() from client drivers.
  hv: Reverse order of resources in hyperv_mmio
  hv: Track allocations of children of hv_vmbus in private resource
    tree

Vitaly Kuznetsov (1):
  Drivers: hv: kvp: fix IP Failover

 drivers/hv/hv_kvp.c             |   31 +++++++++++++++++++++
 drivers/hv/hyperv_vmbus.h       |    5 +++
 drivers/hv/vmbus_drv.c          |   56 ++++++++++++++++++++++++++++++++++-----
 drivers/pci/host/pci-hyperv.c   |   14 +++++-----
 drivers/video/fbdev/hyperv_fb.c |    4 +-
 include/linux/hyperv.h          |    2 +-
 6 files changed, 95 insertions(+), 17 deletions(-)

-- 
1.7.4.1

[toc] | [next] | [standalone]

#1369987 — [PATCH 1/6] Drivers: hv: kvp: fix IP Failover

From: Vitaly Kuznetsov <vkuznets@redhat.com>

Hyper-V VMs can be replicated to another hosts and there is a feature to
set different IP for replicas, it is called 'Failover TCP/IP'. When
such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
as we finish negotiation procedure. The problem is that it can happen (and
it actually happens) before userspace daemon connects and we reply with
HV_E_FAIL to the message. As there are no repetitions we fail to set the
requested IP.

Solve the issue by postponing our reply to the negotiation message till
userspace daemon is connected. We can't wait too long as there is a
host-side timeout (cca. 75 seconds) and if we fail to reply in this time
frame the whole KVP service will become inactive. The solution is not
ideal - if it takes userspace daemon more than 60 seconds to connect
IP Failover will still fail but I don't see a solution with our current
separation between kernel and userspace parts.

Other two modules (VSS and FCOPY) don't require such delay, leave them
untouched.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/hv_kvp.c       |   31 +++++++++++++++++++++++++++++++
 drivers/hv/hyperv_vmbus.h |    5 +++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 9b9b370..cb1a916 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -78,9 +78,11 @@ static void kvp_send_key(struct work_struct *dummy);
 
 static void kvp_respond_to_host(struct hv_kvp_msg *msg, int error);
 static void kvp_timeout_func(struct work_struct *dummy);
+static void kvp_host_handshake_func(struct work_struct *dummy);
 static void kvp_register(int);
 
 static DECLARE_DELAYED_WORK(kvp_timeout_work, kvp_timeout_func);
+static DECLARE_DELAYED_WORK(kvp_host_handshake_work, kvp_host_handshake_func);
 static DECLARE_WORK(kvp_sendkey_work, kvp_send_key);
 
 static const char kvp_devname[] = "vmbus/hv_kvp";
@@ -130,6 +132,11 @@ static void kvp_timeout_func(struct work_struct *dummy)
 	hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
 }
 
+static void kvp_host_handshake_func(struct work_struct *dummy)
+{
+	hv_poll_channel(kvp_transaction.recv_channel, hv_kvp_onchannelcallback);
+}
+
 static int kvp_handle_handshake(struct hv_kvp_msg *msg)
 {
 	switch (msg->kvp_hdr.operation) {
@@ -154,6 +161,12 @@ static int kvp_handle_handshake(struct hv_kvp_msg *msg)
 	pr_debug("KVP: userspace daemon ver. %d registered\n",
 		 KVP_OP_REGISTER);
 	kvp_register(dm_reg_value);
+
+	/*
+	 * If we're still negotiating with the host cancel the timeout
+	 * work to not poll the channel twice.
+	 */
+	cancel_delayed_work_sync(&kvp_host_handshake_work);
 	hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
 
 	return 0;
@@ -594,7 +607,22 @@ void hv_kvp_onchannelcallback(void *context)
 	struct icmsg_negotiate *negop = NULL;
 	int util_fw_version;
 	int kvp_srv_version;
+	static enum {NEGO_NOT_STARTED,
+		     NEGO_IN_PROGRESS,
+		     NEGO_FINISHED} host_negotiatied = NEGO_NOT_STARTED;
 
+	if (host_negotiatied == NEGO_NOT_STARTED &&
+	    kvp_transaction.state < HVUTIL_READY) {
+		/*
+		 * If userspace daemon is not connected and host is asking
+		 * us to negotiate we need to delay to not lose messages.
+		 * This is important for Failover IP setting.
+		 */
+		host_negotiatied = NEGO_IN_PROGRESS;
+		schedule_delayed_work(&kvp_host_handshake_work,
+				      HV_UTIL_NEGO_TIMEOUT * HZ);
+		return;
+	}
 	if (kvp_transaction.state > HVUTIL_READY)
 		return;
 
@@ -672,6 +700,8 @@ void hv_kvp_onchannelcallback(void *context)
 		vmbus_sendpacket(channel, recv_buffer,
 				       recvlen, requestid,
 				       VM_PKT_DATA_INBAND, 0);
+
+		host_negotiatied = NEGO_FINISHED;
 	}
 
 }
@@ -708,6 +738,7 @@ hv_kvp_init(struct hv_util_service *srv)
 void hv_kvp_deinit(void)
 {
 	kvp_transaction.state = HVUTIL_DEVICE_DYING;
+	cancel_delayed_work_sync(&kvp_host_handshake_work);
 	cancel_delayed_work_sync(&kvp_timeout_work);
 	cancel_work_sync(&kvp_sendkey_work);
 	hvutil_transport_destroy(hvt);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 12321b9..8b07f9c 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -36,6 +36,11 @@
 #define HV_UTIL_TIMEOUT 30
 
 /*
+ * Timeout for guest-host handshake for services.
+ */
+#define HV_UTIL_NEGO_TIMEOUT 60
+
+/*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
  * is set by CPUID(HVCPUID_VERSION_FEATURES).
  */
-- 
1.7.4.1

[toc] | [prev] | [next] | [standalone]

#1369988 — [PATCH 5/6] hv: Reverse order of resources in hyperv_mmio

From: Jake Oshins <jakeo@microsoft.com>

A patch later in this series allocates child nodes
in this resource tree.  For that to work, this tree
needs to be sorted in ascending order.

Signed-off-by: Jake Oshins <jakeo@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/vmbus_drv.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 60553c1..1ce47d0 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1049,7 +1049,6 @@ static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
 	new_res->end = end;
 
 	/*
-	 * Stick ranges from higher in address space at the front of the list.
 	 * If two ranges are adjacent, merge them.
 	 */
 	do {
@@ -1070,7 +1069,7 @@ static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
 			break;
 		}
 
-		if ((*old_res)->end < new_res->start) {
+		if ((*old_res)->start > new_res->end) {
 			new_res->sibling = *old_res;
 			if (prev_res)
 				(*prev_res)->sibling = new_res;
-- 
1.7.4.1

[toc] | [prev] | [next] | [standalone]

#1369990 — [PATCH 6/6] hv: Track allocations of children of hv_vmbus in private resource tree

From: Jake Oshins <jakeo@microsoft.com>

This patch changes vmbus_allocate_mmio() and vmbus_free_mmio() so
that when child paravirtual devices allocate memory-mapped I/O
space, they allocate it privately from a resource tree pointed
at by hyperv_mmio and also by the public resource tree
iomem_resource.  This allows the region to be marked as "busy"
in the private tree, but a "bridge window" in the public tree,
guaranteeing that no two bridge windows will overlap each other
but while also allowing the PCI device children of the bridge
windows to overlap that window.

One might conclude that this belongs in the pnp layer, rather
than in this driver.  Rafael Wysocki, the maintainter of the
pnp layer, has previously asked that we not modify the pnp layer
as it is considered deprecated.  This patch is thus essentially
a workaround.

Signed-off-by: Jake Oshins <jakeo@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/vmbus_drv.c |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 1ce47d0..dfc6149 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1128,7 +1128,7 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
 			resource_size_t size, resource_size_t align,
 			bool fb_overlap_ok)
 {
-	struct resource *iter;
+	struct resource *iter, *shadow;
 	resource_size_t range_min, range_max, start, local_min, local_max;
 	const char *dev_n = dev_name(&device_obj->device);
 	u32 fb_end = screen_info.lfb_base + (screen_info.lfb_size << 1);
@@ -1170,12 +1170,22 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
 
 			start = (local_min + align - 1) & ~(align - 1);
 			for (; start + size - 1 <= local_max; start += align) {
+				shadow = __request_region(iter, start,
+							  size,
+							  NULL,
+							  IORESOURCE_BUSY);
+				if (!shadow)
+					continue;
+
 				*new = request_mem_region_exclusive(start, size,
 								    dev_n);
 				if (*new) {
+					shadow->name = (char *)*new;
 					retval = 0;
 					goto exit;
 				}
+
+				__release_region(iter, start, size);
 			}
 		}
 	}
@@ -1196,7 +1206,17 @@ EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
  */
 void vmbus_free_mmio(resource_size_t start, resource_size_t size)
 {
+	struct resource *iter;
+
+	down(&hyperv_mmio_lock);
+	for (iter = hyperv_mmio; iter; iter = iter->sibling) {
+		if ((iter->start >= start + size) || (iter->end <= start))
+			continue;
+
+		__release_region(iter, start, size);
+	}
 	release_mem_region(start, size);
+	up(&hyperv_mmio_lock);
 
 }
 EXPORT_SYMBOL_GPL(vmbus_free_mmio);
-- 
1.7.4.1

[toc] | [prev] | [next] | [standalone]

#1369992 — [PATCH 3/6] hv: Lock access to hyperv_mmio resource tree

From: Jake Oshins <jakeo@microsoft.com>

In existing code, this tree of resources is created
in single-threaded code and never modified after it is
created, and thus needs no locking.  This patch introduces
a semaphore for tree access, as other patches in this
series introduce run-time modifications of this resource
tree which can happen on multiple threads.

Signed-off-by: Jake Oshins <jakeo@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/vmbus_drv.c |   16 ++++++++++++----
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 44e95a4..60553c1 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -102,6 +102,7 @@ static struct notifier_block hyperv_panic_block = {
 };
 
 struct resource *hyperv_mmio;
+DEFINE_SEMAPHORE(hyperv_mmio_lock);
 
 static int vmbus_exists(void)
 {
@@ -1132,7 +1133,10 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
 	resource_size_t range_min, range_max, start, local_min, local_max;
 	const char *dev_n = dev_name(&device_obj->device);
 	u32 fb_end = screen_info.lfb_base + (screen_info.lfb_size << 1);
-	int i;
+	int i, retval;
+
+	retval = -ENXIO;
+	down(&hyperv_mmio_lock);
 
 	for (iter = hyperv_mmio; iter; iter = iter->sibling) {
 		if ((iter->start >= max) || (iter->end <= min))
@@ -1169,13 +1173,17 @@ int vmbus_allocate_mmio(struct resource **new, struct hv_device *device_obj,
 			for (; start + size - 1 <= local_max; start += align) {
 				*new = request_mem_region_exclusive(start, size,
 								    dev_n);
-				if (*new)
-					return 0;
+				if (*new) {
+					retval = 0;
+					goto exit;
+				}
 			}
 		}
 	}
 
-	return -ENXIO;
+exit:
+	up(&hyperv_mmio_lock);
+	return retval;
 }
 EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
 
-- 
1.7.4.1

[toc] | [prev] | [next] | [standalone]

#1370059

On Sat, Apr 02, 2016 at 11:10:38AM -0700, K. Y. Srinivasan wrote:
> Cleanup and mmio management. Also included is a patch
> to fix an issue in KVP.

So these all are for 4.7-rc1?

[toc] | [prev] | [next] | [standalone]

#1370071

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Saturday, April 2, 2016 3:23 PM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> jasowang@redhat.com
> Subject: Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio
> management.
> 
> On Sat, Apr 02, 2016 at 11:10:38AM -0700, K. Y. Srinivasan wrote:
> > Cleanup and mmio management. Also included is a patch
> > to fix an issue in KVP.
> 
> So these all are for 4.7-rc1?

Jake's PCI driver made it into 4.6 and some of the patches in this series fix issues in the Hyper-V
PCI pass-through driver. Is it possible for this series to go into 4.6. If not, 4.7-rc1 is fine.

Regards,

K. Y

[toc] | [prev] | [next] | [standalone]

#1370084

On Sat, Apr 02, 2016 at 11:46:21PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Saturday, April 2, 2016 3:23 PM
> > To: KY Srinivasan <kys@microsoft.com>
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> > jasowang@redhat.com
> > Subject: Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio
> > management.
> > 
> > On Sat, Apr 02, 2016 at 11:10:38AM -0700, K. Y. Srinivasan wrote:
> > > Cleanup and mmio management. Also included is a patch
> > > to fix an issue in KVP.
> > 
> > So these all are for 4.7-rc1?
> 
> Jake's PCI driver made it into 4.6 and some of the patches in this series fix issues in the Hyper-V
> PCI pass-through driver. Is it possible for this series to go into 4.6. If not, 4.7-rc1 is fine.

Even patch 1?  Please be specific where you want patches to be merged
to.

greg k-h

[toc] | [prev] | [next] | [standalone]

#1370096

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Saturday, April 2, 2016 6:48 PM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: olaf@aepfle.de; jasowang@redhat.com; linux-kernel@vger.kernel.org;
> apw@canonical.com; devel@linuxdriverproject.org
> Subject: Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio
> management.
> 
> On Sat, Apr 02, 2016 at 11:46:21PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Saturday, April 2, 2016 3:23 PM
> > > To: KY Srinivasan <kys@microsoft.com>
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> > > jasowang@redhat.com
> > > Subject: Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio
> > > management.
> > >
> > > On Sat, Apr 02, 2016 at 11:10:38AM -0700, K. Y. Srinivasan wrote:
> > > > Cleanup and mmio management. Also included is a patch
> > > > to fix an issue in KVP.
> > >
> > > So these all are for 4.7-rc1?
> >
> > Jake's PCI driver made it into 4.6 and some of the patches in this series fix
> issues in the Hyper-V
> > PCI pass-through driver. Is it possible for this series to go into 4.6. If not,
> 4.7-rc1 is fine.
> 
> Even patch 1?  Please be specific where you want patches to be merged
> to.

Patch 1 can go into 4.7. If Jake's patches can go into 4.6, that would be good. Do you want me
to resend the patches that clearly indicate where the patches need to be merged.

Thank you for your patience.

K. Y 
> 
> greg k-h

[toc] | [prev] | [next] | [standalone]

#1370672

> -----Original Message-----
> From: KY Srinivasan
> Sent: Saturday, April 2, 2016 10:18 PM
> To: 'Greg KH' <gregkh@linuxfoundation.org>
> Cc: olaf@aepfle.de; jasowang@redhat.com; linux-kernel@vger.kernel.org;
> apw@canonical.com; devel@linuxdriverproject.org
> Subject: RE: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio
> management.
> 
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Saturday, April 2, 2016 6:48 PM
> > To: KY Srinivasan <kys@microsoft.com>
> > Cc: olaf@aepfle.de; jasowang@redhat.com; linux-kernel@vger.kernel.org;
> > apw@canonical.com; devel@linuxdriverproject.org
> > Subject: Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio
> > management.
> >
> > On Sat, Apr 02, 2016 at 11:46:21PM +0000, KY Srinivasan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > > Sent: Saturday, April 2, 2016 3:23 PM
> > > > To: KY Srinivasan <kys@microsoft.com>
> > > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com;
> > > > jasowang@redhat.com
> > > > Subject: Re: [PATCH 0/6] Drivers: hv: vmbus: Cleanup and mmio
> > > > management.
> > > >
> > > > On Sat, Apr 02, 2016 at 11:10:38AM -0700, K. Y. Srinivasan wrote:
> > > > > Cleanup and mmio management. Also included is a patch
> > > > > to fix an issue in KVP.
> > > >
> > > > So these all are for 4.7-rc1?
> > >
> > > Jake's PCI driver made it into 4.6 and some of the patches in this series fix
> > issues in the Hyper-V
> > > PCI pass-through driver. Is it possible for this series to go into 4.6. If not,
> > 4.7-rc1 is fine.
> >
> > Even patch 1?  Please be specific where you want patches to be merged
> > to.
> 
> Patch 1 can go into 4.7. If Jake's patches can go into 4.6, that would be good.
> Do you want me
> to resend the patches that clearly indicate where the patches need to be
> merged.

Greg,

Please drop this set. Jake has sent out a new series that we may want to pick up. I will resend
the patches I sent the on April 2, 2016 with appropriate adjustments.

Regards,

K. Y

[toc] | [prev] | [next] | [standalone]

#1370545

"K. Y. Srinivasan" <kys@microsoft.com> writes:

> Cleanup and mmio management. Also included is a patch
> to fix an issue in KVP.
>
> Jake Oshins (5):
>   hv: Make a function to free mmio regions through vmbus
>   hv: Lock access to hyperv_mmio resource tree
>   hv: Use new vmbus_mmio_free() from client drivers.
>   hv: Reverse order of resources in hyperv_mmio
>   hv: Track allocations of children of hv_vmbus in private resource
>     tree

It seems there is an updated version of the patchset from Jake:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-April/088262.html

It consists of 7 patches. It would probably make sense to take them all
I think.

>
> Vitaly Kuznetsov (1):
>   Drivers: hv: kvp: fix IP Failover
>
>  drivers/hv/hv_kvp.c             |   31 +++++++++++++++++++++
>  drivers/hv/hyperv_vmbus.h       |    5 +++
>  drivers/hv/vmbus_drv.c          |   56 ++++++++++++++++++++++++++++++++++-----
>  drivers/pci/host/pci-hyperv.c   |   14 +++++-----
>  drivers/video/fbdev/hyperv_fb.c |    4 +-
>  include/linux/hyperv.h          |    2 +-
>  6 files changed, 95 insertions(+), 17 deletions(-)

-- 
  Vitaly

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web