Patch to auto-load MSFT PV NIC driver

Patch to auto-load MSFT PV NIC driver

[Ky Srinivasan]

[-- Attachment #1: Type: text/plain, Size: 74 bytes --]

I am attaching a patch to auto-load hv_netvsc.

Regards,

K. Y




[-- Attachment #2: hv_netvsc_autoload.patch --]
[-- Type: text/plain, Size: 1905 bytes --]

From: K. Y. Srinivasan <ksrinivasan@novell.com>
Subject: Auto-load the hyperV PV net driver. 
References: None
Patch-mainline:

Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>

Index: linux/drivers/staging/hv/netvsc_drv.c
===================================================================
--- linux.orig/drivers/staging/hv/netvsc_drv.c	2010-05-07 15:29:32.000000000 -0600
+++ linux/drivers/staging/hv/netvsc_drv.c	2010-05-07 15:30:00.000000000 -0600
@@ -29,6 +29,8 @@
 #include <linux/etherdevice.h>
 #include <linux/skbuff.h>
 #include <linux/in.h>
+#include <linux/dmi.h>
+#include <linux/pci.h>
 #include <net/arp.h>
 #include <net/route.h>
 #include <net/sock.h>
@@ -592,6 +594,20 @@ static int netvsc_drv_init(int (*drv_ini
 	return ret;
 }
 
+static const struct dmi_system_id __initconst
+hv_netvsc_dmi_table[] __maybe_unused  = {
+	{
+		.ident = "Hyper-V",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
+			DMI_MATCH(DMI_BOARD_NAME, "Virtual Machine"),
+		},
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(dmi, hv_netvsc_dmi_table);
+
 static int __init netvsc_init(void)
 {
 	int ret;
@@ -599,6 +615,9 @@ static int __init netvsc_init(void)
 	DPRINT_ENTER(NETVSC_DRV);
 	DPRINT_INFO(NETVSC_DRV, "Netvsc initializing....");
 
+	if (!dmi_check_system(hv_netvsc_dmi_table))
+		return -ENODEV;
+
 	ret = netvsc_drv_init(NetVscInitialize);
 
 	DPRINT_EXIT(NETVSC_DRV);
@@ -613,6 +632,13 @@ static void __exit netvsc_exit(void)
 	DPRINT_EXIT(NETVSC_DRV);
 }
 
+static const struct pci_device_id __initconst
+hv_netvsc_pci_table[] __maybe_unused = {
+	{ PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
+	{ 0 }
+};
+MODULE_DEVICE_TABLE(pci, hv_netvsc_pci_table);
+
 module_param(netvsc_ringbuffer_size, int, S_IRUGO);
 
 module_init(netvsc_init);

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel

RE: Patch to auto-load MSFT PV NIC driver

[Hank Janssen]

>From: Ky Srinivasan [ksrinivasan@novell.com]  -  Friday, May 07, 2010 4:52 PM
>
> I am attaching a patch to auto-load hv_netvsc.

I am not sure if this is the right approach. hv_netvsc takes a dependency on hv_vmbus.
hv_vmbus does have the same DMI detection logic in it. But unless hv_vmbus has loaded
up competely, hv_netvsc will fail on loadup. And I do not think we can guarantee that
hv_vmbus has loaded yet.

It would be better to have netvsc check to make sure hv_vmbus is loaded.

Thanks,

Hank.

Re: Patch to auto-load MSFT PV NIC driver

[Greg KH]

On Sat, May 08, 2010 at 01:52:01PM +0000, Hank Janssen wrote:
> 
> 
> >From: Ky Srinivasan [ksrinivasan@novell.com]  -  Friday, May 07, 2010 4:52 PM
> >
> > I am attaching a patch to auto-load hv_netvsc.
> 
> I am not sure if this is the right approach. hv_netvsc takes a dependency on hv_vmbus.
> hv_vmbus does have the same DMI detection logic in it. But unless hv_vmbus has loaded
> up competely, hv_netvsc will fail on loadup. And I do not think we can guarantee that
> hv_vmbus has loaded yet.

Yes you can, the dependancies in the module will take care of it.  Try
it, if you try to load the hv_netvsc module before hv_vmbus, modprobe
will load hv_vmbus first.

> It would be better to have netvsc check to make sure hv_vmbus is loaded.

How would you do that?  The symbol resolution will not allow hv_netvsc
to be loaded without hv_vmbus being around.

Now I do think that just adding the same pci/dmi ids to all of the
modules is a bit odd, and that something else needs to be done here, but
at the moment, I can't think of anything better.

thanks,

greg k-h

Re: Patch to auto-load MSFT PV NIC driver

[Jeremy Fitzhardinge]

On 05/08/2010 07:27 AM, Greg KH wrote:
> How would you do that?  The symbol resolution will not allow hv_netvsc
> to be loaded without hv_vmbus being around.
>
> Now I do think that just adding the same pci/dmi ids to all of the
> modules is a bit odd, and that something else needs to be done here, but
> at the moment, I can't think of anything better.
>   

Could you make hv_vmbus a real bus implementation, which knows how to
enumerate and probe devices hanging off it?

    J

Re: Patch to auto-load MSFT PV NIC driver

[Greg KH]

On Sat, May 08, 2010 at 04:02:17PM -0700, Jeremy Fitzhardinge wrote:
> On 05/08/2010 07:27 AM, Greg KH wrote:
> > How would you do that?  The symbol resolution will not allow hv_netvsc
> > to be loaded without hv_vmbus being around.
> >
> > Now I do think that just adding the same pci/dmi ids to all of the
> > modules is a bit odd, and that something else needs to be done here, but
> > at the moment, I can't think of anything better.
> >   
> 
> Could you make hv_vmbus a real bus implementation, which knows how to
> enumerate and probe devices hanging off it?

Yes, that's the correct solution here.  I originally thought this
couldn't be done, but in looking at the code some more, I think it can
happen for the network driver, and perhaps some others (but not the
block, as both devices work off of the same interface to the hypervisor,
so which one do we load?)

I'll look into that later if I get the chance.

thanks,

greg k-h

RE: Patch to auto-load MSFT PV NIC driver

[Hank Janssen]

>Sent: Saturday, May 08, 2010 7:27 AM -  Hank Janssen
>>On Sat, May 08, 2010 at 01:52:01PM +0000, Hank Janssen wrote:>
>>
>> I am not sure if this is the right approach. hv_netvsc takes a dependency on hv_vmbus.
>> hv_vmbus does have the same DMI detection logic in it. But unless hv_vmbus has loaded
>> up competely, hv_netvsc will fail on loadup. And I do not think we can guarantee that
>> hv_vmbus has loaded yet.
>
>Yes you can, the dependancies in the module will take care of it.  Try
>it, if you try to load the hv_netvsc module before hv_vmbus, modprobe
>will load hv_vmbus first.

In my testing I have seen issues with timing.   It takes a little while for VMBus to start
getting the initialization taken care of with Hyper-V. And I have seen netvsc error with
unresolved symbols because vmbus had not completed the initialization yet.

Thanks,

Hank.

Re: Patch to auto-load MSFT PV NIC driver

[Greg KH]

On Mon, May 10, 2010 at 05:05:02PM +0000, Hank Janssen wrote:
> 
> >Sent: Saturday, May 08, 2010 7:27 AM -  Hank Janssen
> >>On Sat, May 08, 2010 at 01:52:01PM +0000, Hank Janssen wrote:>
> >>
> >> I am not sure if this is the right approach. hv_netvsc takes a dependency on hv_vmbus.
> >> hv_vmbus does have the same DMI detection logic in it. But unless hv_vmbus has loaded
> >> up competely, hv_netvsc will fail on loadup. And I do not think we can guarantee that
> >> hv_vmbus has loaded yet.
> >
> >Yes you can, the dependancies in the module will take care of it.  Try
> >it, if you try to load the hv_netvsc module before hv_vmbus, modprobe
> >will load hv_vmbus first.
> 
> In my testing I have seen issues with timing.   It takes a little while for VMBus to start
> getting the initialization taken care of with Hyper-V. And I have seen netvsc error with
> unresolved symbols because vmbus had not completed the initialization yet.

Odd, that shouldn't happen, unless you are loading modules in parallel.

If we switch to a proper discovery type bus, this should not be an
issue.

thanks,

greg k-h

Re: Patch to auto-load MSFT PV NIC driver

[Ky Srinivasan]

>>> On 5/10/2010 at  1:21 PM, in message <20100510172125.GA1482@kroah.com>, Greg KH
<greg@kroah.com> wrote: 
> On Mon, May 10, 2010 at 05:05:02PM +0000, Hank Janssen wrote:
>> 
>> >Sent: Saturday, May 08, 2010 7:27 AM -  Hank Janssen
>> >>On Sat, May 08, 2010 at 01:52:01PM +0000, Hank Janssen wrote:>
>> >>
>> >> I am not sure if this is the right approach. hv_netvsc takes a dependency 
> on hv_vmbus.
>> >> hv_vmbus does have the same DMI detection logic in it. But unless hv_vmbus 
> has loaded
>> >> up competely, hv_netvsc will fail on loadup. And I do not think we can 
> guarantee that
>> >> hv_vmbus has loaded yet.
>> >
>> >Yes you can, the dependancies in the module will take care of it.  Try
>> >it, if you try to load the hv_netvsc module before hv_vmbus, modprobe
>> >will load hv_vmbus first.
>> 
>> In my testing I have seen issues with timing.   It takes a little while for 
> VMBus to start
>> getting the initialization taken care of with Hyper-V. And I have seen netvsc 
> error with
>> unresolved symbols because vmbus had not completed the initialization yet.
> 
> Odd, that shouldn't happen, unless you are loading modules in parallel.
This is indeed strange. Given the module dependency, modprobe is supposed to load all the dependencies first before loading the dependent module. I am wondering if there is some other race in the modules that may be causing this problem.

K. Y
> 
> If we switch to a proper discovery type bus, this should not be an
> issue.
> 
> thanks,
> 
> greg k-h