This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Friday, April 29, 2011 12:40 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:]
> > > Sent: Wednesday, April 27, 2011 8:19 AM
> > > To: KY Srinivasan
> > > Cc: Christoph Hellwig; Greg KH; ; linux-
> ;
> > > ;
> > > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> > >
> > > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > > On the host side, Windows emulates the standard PC hardware
> > > > to permit hosting of fully virtualized operating systems.
> > > > To enhance disk I/O performance, we support a virtual block driver.
> > > > This block driver currently handles disks that have been setup as IDE
> > > > disks for the guest - as specified in the guest configuration.
> > > >
> > > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > > under the SCSI controller for the guest are handled via this
> > > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > > the guest are handled through native SCSI upper-level drivers.
> > > > If this SCSI front-end driver is not loaded, currently, the guest
> > > > cannot see devices that have been configured as SCSI devices.
> > > > So, while the virtual block driver described earlier could potentially
> > > > handle all block devices, the implementation choices made on the host
> > > > will not permit it. Also, the only SCSI device that can be currently configured
> > > > for the guest is a disk device.
> > > >
> > > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > > driver (hv_storvsc) communicate with the host via unique channels
> > > > that are implemented as bi-directional ring buffers. Each (storage)
> > > > channel carries with it enough state to uniquely identify the device on
> > > > the host side. Microsoft has chosen to use SCSI verbs for this storage
> channel
> > > > communication.
> > >
> > > This doesn't really explain much at all. The only important piece
> > > of information I can read from this statement is that both blkvsc
> > > and storvsc only support disks, but not any other kind of device,
> > > and that chosing either one is an arbitrary seletin when setting up
> > > a VM configuration.
> > >
> > > But this still isn't an excuse to implement a block layer driver for
> > > a SCSI protocol, and it doesn't not explain in what way the two
> > > protocols actually differ. You really should implement blksvs as a SCSI
> > > LLDD, too - and from the looks of it it doesn't even have to be a
> > > separate one, but just adding the ids to storvsc would do the work.
> >
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > the scsi driver (storvsc_drv).
>
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a block driver in
the guest and talks to an appropriate device driver on the host, communicating over
the vmbus. In this respect, it is identical to block drivers we have for guests in other
virtualization platforms (Xen etc.). The only difference is that on the host side,
the only way you can assign a scsi disk to the guest is to configure this scsi disk
under the scsi controller. So, while blkvsc is a generic block driver, because of the
restrictions on the host side, it only ends up managing block devices that have IDE majors.

>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE driver. There
is nothing IDE specific about it. It is very much like other block front-end drivers
(like in Xen) that get their device information from the host and register the block
device accordingly with the guest. It just happens that in the current version of the
Windows host, only devices that are configured as IDE devices in the host end up being
managed by this driver. To make this clear, in my recent cleanup of this driver (these patches
have been applied), all IDE major information has been properly consolidated.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Friday, April 29, 2011 12:40 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:]
> > > Sent: Wednesday, April 27, 2011 8:19 AM
> > > To: KY Srinivasan
> > > Cc: Christoph Hellwig; Greg KH; ; linux-
> ;
> > > ;
> > > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> > >
> > > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > > On the host side, Windows emulates the standard PC hardware
> > > > to permit hosting of fully virtualized operating systems.
> > > > To enhance disk I/O performance, we support a virtual block driver.
> > > > This block driver currently handles disks that have been setup as IDE
> > > > disks for the guest - as specified in the guest configuration.
> > > >
> > > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > > under the SCSI controller for the guest are handled via this
> > > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > > the guest are handled through native SCSI upper-level drivers.
> > > > If this SCSI front-end driver is not loaded, currently, the guest
> > > > cannot see devices that have been configured as SCSI devices.
> > > > So, while the virtual block driver described earlier could potentially
> > > > handle all block devices, the implementation choices made on the host
> > > > will not permit it. Also, the only SCSI device that can be currently configured
> > > > for the guest is a disk device.
> > > >
> > > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > > driver (hv_storvsc) communicate with the host via unique channels
> > > > that are implemented as bi-directional ring buffers. Each (storage)
> > > > channel carries with it enough state to uniquely identify the device on
> > > > the host side. Microsoft has chosen to use SCSI verbs for this storage
> channel
> > > > communication.
> > >
> > > This doesn't really explain much at all. The only important piece
> > > of information I can read from this statement is that both blkvsc
> > > and storvsc only support disks, but not any other kind of device,
> > > and that chosing either one is an arbitrary seletin when setting up
> > > a VM configuration.
> > >
> > > But this still isn't an excuse to implement a block layer driver for
> > > a SCSI protocol, and it doesn't not explain in what way the two
> > > protocols actually differ. You really should implement blksvs as a SCSI
> > > LLDD, too - and from the looks of it it doesn't even have to be a
> > > separate one, but just adding the ids to storvsc would do the work.
> >
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > the scsi driver (storvsc_drv).
>
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a block driver in
the guest and talks to an appropriate device driver on the host, communicating over
the vmbus. In this respect, it is identical to block drivers we have for guests in other
virtualization platforms (Xen etc.). The only difference is that on the host side,
the only way you can assign a scsi disk to the guest is to configure this scsi disk
under the scsi controller. So, while blkvsc is a generic block driver, because of the
restrictions on the host side, it only ends up managing block devices that have IDE majors.

>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE driver. There
is nothing IDE specific about it. It is very much like other block front-end drivers
(like in Xen) that get their device information from the host and register the block
device accordingly with the guest. It just happens that in the current version of the
Windows host, only devices that are configured as IDE devices in the host end up being
managed by this driver. To make this clear, in my recent cleanup of this driver (these patches
have been applied), all IDE major information has been properly consolidated.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
This is a resend of the patches yet to be applied.
This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:


1) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

2) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

3) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

4) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

5) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Friday, April 29, 2011 12:40 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:]
> > > Sent: Wednesday, April 27, 2011 8:19 AM
> > > To: KY Srinivasan
> > > Cc: Christoph Hellwig; Greg KH; ; linux-
> ;
> > > ;
> > > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> > >
> > > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > > On the host side, Windows emulates the standard PC hardware
> > > > to permit hosting of fully virtualized operating systems.
> > > > To enhance disk I/O performance, we support a virtual block driver.
> > > > This block driver currently handles disks that have been setup as IDE
> > > > disks for the guest - as specified in the guest configuration.
> > > >
> > > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > > under the SCSI controller for the guest are handled via this
> > > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > > the guest are handled through native SCSI upper-level drivers.
> > > > If this SCSI front-end driver is not loaded, currently, the guest
> > > > cannot see devices that have been configured as SCSI devices.
> > > > So, while the virtual block driver described earlier could potentially
> > > > handle all block devices, the implementation choices made on the host
> > > > will not permit it. Also, the only SCSI device that can be currently configured
> > > > for the guest is a disk device.
> > > >
> > > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > > driver (hv_storvsc) communicate with the host via unique channels
> > > > that are implemented as bi-directional ring buffers. Each (storage)
> > > > channel carries with it enough state to uniquely identify the device on
> > > > the host side. Microsoft has chosen to use SCSI verbs for this storage
> channel
> > > > communication.
> > >
> > > This doesn't really explain much at all. The only important piece
> > > of information I can read from this statement is that both blkvsc
> > > and storvsc only support disks, but not any other kind of device,
> > > and that chosing either one is an arbitrary seletin when setting up
> > > a VM configuration.
> > >
> > > But this still isn't an excuse to implement a block layer driver for
> > > a SCSI protocol, and it doesn't not explain in what way the two
> > > protocols actually differ. You really should implement blksvs as a SCSI
> > > LLDD, too - and from the looks of it it doesn't even have to be a
> > > separate one, but just adding the ids to storvsc would do the work.
> >
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > the scsi driver (storvsc_drv).
>
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a block driver in
the guest and talks to an appropriate device driver on the host, communicating over
the vmbus. In this respect, it is identical to block drivers we have for guests in other
virtualization platforms (Xen etc.). The only difference is that on the host side,
the only way you can assign a scsi disk to the guest is to configure this scsi disk
under the scsi controller. So, while blkvsc is a generic block driver, because of the
restrictions on the host side, it only ends up managing block devices that have IDE majors.

>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE driver. There
is nothing IDE specific about it. It is very much like other block front-end drivers
(like in Xen) that get their device information from the host and register the block
device accordingly with the guest. It just happens that in the current version of the
Windows host, only devices that are configured as IDE devices in the host end up being
managed by this driver. To make this clear, in my recent cleanup of this driver (these patches
have been applied), all IDE major information has been properly consolidated.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
This is a resend of the patches yet to be applied.
This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:


1) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

2) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

3) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

4) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

5) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> the devices enumerated will not include block devices configured under the IDE
> controller. So, it is not clear to me how I can do what you are proposing given the
> restrictions imposed by the host.

Just because a device is not reported by REPORT_LUNS doesn't mean you
can't talk to it using a SCSI LLDD. We have SCSI transports with all
kinds of strange ways to discover devices. Using scsi_add_device you
can add LUNs found by your own discovery methods, and use all the
existing scsi command handling.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Friday, April 29, 2011 12:40 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:]
> > > Sent: Wednesday, April 27, 2011 8:19 AM
> > > To: KY Srinivasan
> > > Cc: Christoph Hellwig; Greg KH; ; linux-
> ;
> > > ;
> > > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> > >
> > > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > > On the host side, Windows emulates the standard PC hardware
> > > > to permit hosting of fully virtualized operating systems.
> > > > To enhance disk I/O performance, we support a virtual block driver.
> > > > This block driver currently handles disks that have been setup as IDE
> > > > disks for the guest - as specified in the guest configuration.
> > > >
> > > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > > under the SCSI controller for the guest are handled via this
> > > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > > the guest are handled through native SCSI upper-level drivers.
> > > > If this SCSI front-end driver is not loaded, currently, the guest
> > > > cannot see devices that have been configured as SCSI devices.
> > > > So, while the virtual block driver described earlier could potentially
> > > > handle all block devices, the implementation choices made on the host
> > > > will not permit it. Also, the only SCSI device that can be currently configured
> > > > for the guest is a disk device.
> > > >
> > > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > > driver (hv_storvsc) communicate with the host via unique channels
> > > > that are implemented as bi-directional ring buffers. Each (storage)
> > > > channel carries with it enough state to uniquely identify the device on
> > > > the host side. Microsoft has chosen to use SCSI verbs for this storage
> channel
> > > > communication.
> > >
> > > This doesn't really explain much at all. The only important piece
> > > of information I can read from this statement is that both blkvsc
> > > and storvsc only support disks, but not any other kind of device,
> > > and that chosing either one is an arbitrary seletin when setting up
> > > a VM configuration.
> > >
> > > But this still isn't an excuse to implement a block layer driver for
> > > a SCSI protocol, and it doesn't not explain in what way the two
> > > protocols actually differ. You really should implement blksvs as a SCSI
> > > LLDD, too - and from the looks of it it doesn't even have to be a
> > > separate one, but just adding the ids to storvsc would do the work.
> >
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > the scsi driver (storvsc_drv).
>
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a block driver in
the guest and talks to an appropriate device driver on the host, communicating over
the vmbus. In this respect, it is identical to block drivers we have for guests in other
virtualization platforms (Xen etc.). The only difference is that on the host side,
the only way you can assign a scsi disk to the guest is to configure this scsi disk
under the scsi controller. So, while blkvsc is a generic block driver, because of the
restrictions on the host side, it only ends up managing block devices that have IDE majors.

>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE driver. There
is nothing IDE specific about it. It is very much like other block front-end drivers
(like in Xen) that get their device information from the host and register the block
device accordingly with the guest. It just happens that in the current version of the
Windows host, only devices that are configured as IDE devices in the host end up being
managed by this driver. To make this clear, in my recent cleanup of this driver (these patches
have been applied), all IDE major information has been properly consolidated.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
This is a resend of the patches yet to be applied.
This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:


1) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

2) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

3) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

4) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

5) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> the devices enumerated will not include block devices configured under the IDE
> controller. So, it is not clear to me how I can do what you are proposing given the
> restrictions imposed by the host.

Just because a device is not reported by REPORT_LUNS doesn't mean you
can't talk to it using a SCSI LLDD. We have SCSI transports with all
kinds of strange ways to discover devices. Using scsi_add_device you
can add LUNs found by your own discovery methods, and use all the
existing scsi command handling.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.
>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

The blkvsc driver isn't an IDE driver, although it currently claims
the old IDE drivers major numbers, which is a no-no and can't work
in most usual setups. I'm pretty sure I already complained about
this in a previous review round.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Friday, April 29, 2011 12:40 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:]
> > > Sent: Wednesday, April 27, 2011 8:19 AM
> > > To: KY Srinivasan
> > > Cc: Christoph Hellwig; Greg KH; ; linux-
> ;
> > > ;
> > > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> > >
> > > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > > On the host side, Windows emulates the standard PC hardware
> > > > to permit hosting of fully virtualized operating systems.
> > > > To enhance disk I/O performance, we support a virtual block driver.
> > > > This block driver currently handles disks that have been setup as IDE
> > > > disks for the guest - as specified in the guest configuration.
> > > >
> > > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > > under the SCSI controller for the guest are handled via this
> > > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > > the guest are handled through native SCSI upper-level drivers.
> > > > If this SCSI front-end driver is not loaded, currently, the guest
> > > > cannot see devices that have been configured as SCSI devices.
> > > > So, while the virtual block driver described earlier could potentially
> > > > handle all block devices, the implementation choices made on the host
> > > > will not permit it. Also, the only SCSI device that can be currently configured
> > > > for the guest is a disk device.
> > > >
> > > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > > driver (hv_storvsc) communicate with the host via unique channels
> > > > that are implemented as bi-directional ring buffers. Each (storage)
> > > > channel carries with it enough state to uniquely identify the device on
> > > > the host side. Microsoft has chosen to use SCSI verbs for this storage
> channel
> > > > communication.
> > >
> > > This doesn't really explain much at all. The only important piece
> > > of information I can read from this statement is that both blkvsc
> > > and storvsc only support disks, but not any other kind of device,
> > > and that chosing either one is an arbitrary seletin when setting up
> > > a VM configuration.
> > >
> > > But this still isn't an excuse to implement a block layer driver for
> > > a SCSI protocol, and it doesn't not explain in what way the two
> > > protocols actually differ. You really should implement blksvs as a SCSI
> > > LLDD, too - and from the looks of it it doesn't even have to be a
> > > separate one, but just adding the ids to storvsc would do the work.
> >
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > the scsi driver (storvsc_drv).
>
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a block driver in
the guest and talks to an appropriate device driver on the host, communicating over
the vmbus. In this respect, it is identical to block drivers we have for guests in other
virtualization platforms (Xen etc.). The only difference is that on the host side,
the only way you can assign a scsi disk to the guest is to configure this scsi disk
under the scsi controller. So, while blkvsc is a generic block driver, because of the
restrictions on the host side, it only ends up managing block devices that have IDE majors.

>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE driver. There
is nothing IDE specific about it. It is very much like other block front-end drivers
(like in Xen) that get their device information from the host and register the block
device accordingly with the guest. It just happens that in the current version of the
Windows host, only devices that are configured as IDE devices in the host end up being
managed by this driver. To make this clear, in my recent cleanup of this driver (these patches
have been applied), all IDE major information has been properly consolidated.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
This is a resend of the patches yet to be applied.
This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:


1) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

2) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

3) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

4) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

5) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> the devices enumerated will not include block devices configured under the IDE
> controller. So, it is not clear to me how I can do what you are proposing given the
> restrictions imposed by the host.

Just because a device is not reported by REPORT_LUNS doesn't mean you
can't talk to it using a SCSI LLDD. We have SCSI transports with all
kinds of strange ways to discover devices. Using scsi_add_device you
can add LUNs found by your own discovery methods, and use all the
existing scsi command handling.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.
>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

The blkvsc driver isn't an IDE driver, although it currently claims
the old IDE drivers major numbers, which is a no-no and can't work
in most usual setups. I'm pretty sure I already complained about
this in a previous review round.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Sunday, May 01, 2011 11:41 AM
> To: Greg KH
> Cc: KY Srinivasan; Christoph Hellwig; ; linux-
> ; ;
>
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> > Are you sure the libata core can't see this ide controller and connect
> > to it? That way you would use the scsi system if you do that and you
> > would need a much smaller ide driver, perhaps being able to merge it
> > with your scsi driver.
> >
> > We really don't want to write new IDE drivers anymore that don't use
> > libata.
>
> The blkvsc driver isn't an IDE driver, although it currently claims
> the old IDE drivers major numbers, which is a no-no and can't work
> in most usual setups.

What is the issue here? This is no different than what is done in other
Virtualization platforms. For instance, the Xen blkfront driver is no
different - if you specify the block device to be presented to the guest
as an ide device, it will register for the appropriate ide major number.

Regards,

K. Y

> I'm pretty sure I already complained about
> this in a previous review round.


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Friday, April 29, 2011 12:40 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:]
> > > Sent: Wednesday, April 27, 2011 8:19 AM
> > > To: KY Srinivasan
> > > Cc: Christoph Hellwig; Greg KH; ; linux-
> ;
> > > ;
> > > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> > >
> > > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > > On the host side, Windows emulates the standard PC hardware
> > > > to permit hosting of fully virtualized operating systems.
> > > > To enhance disk I/O performance, we support a virtual block driver.
> > > > This block driver currently handles disks that have been setup as IDE
> > > > disks for the guest - as specified in the guest configuration.
> > > >
> > > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > > under the SCSI controller for the guest are handled via this
> > > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > > the guest are handled through native SCSI upper-level drivers.
> > > > If this SCSI front-end driver is not loaded, currently, the guest
> > > > cannot see devices that have been configured as SCSI devices.
> > > > So, while the virtual block driver described earlier could potentially
> > > > handle all block devices, the implementation choices made on the host
> > > > will not permit it. Also, the only SCSI device that can be currently configured
> > > > for the guest is a disk device.
> > > >
> > > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > > driver (hv_storvsc) communicate with the host via unique channels
> > > > that are implemented as bi-directional ring buffers. Each (storage)
> > > > channel carries with it enough state to uniquely identify the device on
> > > > the host side. Microsoft has chosen to use SCSI verbs for this storage
> channel
> > > > communication.
> > >
> > > This doesn't really explain much at all. The only important piece
> > > of information I can read from this statement is that both blkvsc
> > > and storvsc only support disks, but not any other kind of device,
> > > and that chosing either one is an arbitrary seletin when setting up
> > > a VM configuration.
> > >
> > > But this still isn't an excuse to implement a block layer driver for
> > > a SCSI protocol, and it doesn't not explain in what way the two
> > > protocols actually differ. You really should implement blksvs as a SCSI
> > > LLDD, too - and from the looks of it it doesn't even have to be a
> > > separate one, but just adding the ids to storvsc would do the work.
> >
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > the scsi driver (storvsc_drv).
>
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a block driver in
the guest and talks to an appropriate device driver on the host, communicating over
the vmbus. In this respect, it is identical to block drivers we have for guests in other
virtualization platforms (Xen etc.). The only difference is that on the host side,
the only way you can assign a scsi disk to the guest is to configure this scsi disk
under the scsi controller. So, while blkvsc is a generic block driver, because of the
restrictions on the host side, it only ends up managing block devices that have IDE majors.

>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE driver. There
is nothing IDE specific about it. It is very much like other block front-end drivers
(like in Xen) that get their device information from the host and register the block
device accordingly with the guest. It just happens that in the current version of the
Windows host, only devices that are configured as IDE devices in the host end up being
managed by this driver. To make this clear, in my recent cleanup of this driver (these patches
have been applied), all IDE major information has been properly consolidated.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
This is a resend of the patches yet to be applied.
This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:


1) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

2) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

3) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

4) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

5) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> the devices enumerated will not include block devices configured under the IDE
> controller. So, it is not clear to me how I can do what you are proposing given the
> restrictions imposed by the host.

Just because a device is not reported by REPORT_LUNS doesn't mean you
can't talk to it using a SCSI LLDD. We have SCSI transports with all
kinds of strange ways to discover devices. Using scsi_add_device you
can add LUNs found by your own discovery methods, and use all the
existing scsi command handling.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.
>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

The blkvsc driver isn't an IDE driver, although it currently claims
the old IDE drivers major numbers, which is a no-no and can't work
in most usual setups. I'm pretty sure I already complained about
this in a previous review round.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Sunday, May 01, 2011 11:41 AM
> To: Greg KH
> Cc: KY Srinivasan; Christoph Hellwig; ; linux-
> ; ;
>
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> > Are you sure the libata core can't see this ide controller and connect
> > to it? That way you would use the scsi system if you do that and you
> > would need a much smaller ide driver, perhaps being able to merge it
> > with your scsi driver.
> >
> > We really don't want to write new IDE drivers anymore that don't use
> > libata.
>
> The blkvsc driver isn't an IDE driver, although it currently claims
> the old IDE drivers major numbers, which is a no-no and can't work
> in most usual setups.

What is the issue here? This is no different than what is done in other
Virtualization platforms. For instance, the Xen blkfront driver is no
different - if you specify the block device to be presented to the guest
as an ide device, it will register for the appropriate ide major number.

Regards,

K. Y

> I'm pretty sure I already complained about
> this in a previous review round.


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Sun, May 01, 2011 at 11:39:21AM -0400, Christoph Hellwig wrote:
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> > the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> > the devices enumerated will not include block devices configured under the IDE
> > controller. So, it is not clear to me how I can do what you are proposing given the
> > restrictions imposed by the host.
>
> Just because a device is not reported by REPORT_LUNS doesn't mean you
> can't talk to it using a SCSI LLDD. We have SCSI transports with all
> kinds of strange ways to discover devices. Using scsi_add_device you
> can add LUNs found by your own discovery methods, and use all the
> existing scsi command handling.

Yeah, it seems to me that no matter how the user specifies the disk
"type" for the guest configuration, we should use the same Linux driver,
with the same naming scheme for both ways.

As Christoph points out, it's just a matter of hooking the device up to
the scsi subsystem. We do that today for ide, usb, scsi, and loads of
other types of devices all with the common goal of making it easier for
userspace to handle the devices in a standard manner.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)

This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:

1) Cleanup unnecessary state in struct hv_device and
struct hv_driver to be compliant with the Linux
Driver model.

2) Cleanup the vmbus_match() function to conform with the
Linux Driver model.

3) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

4) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

5) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

6) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

7) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Tuesday, April 26, 2011 12:57 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> Do you have a repository containing the current state of your patche
> somewhere? There's been so much cleanup that it's hard to review these
> patches against the current mainline codebase.

Christoph,

Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
You checkout Greg's tree today, you will get the most recent hv codebase. This current
patch-set is against Greg's current tree.

Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 05:04:36PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Tuesday, April 26, 2011 12:57 PM
> > To: KY Srinivasan
> > Cc: ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > Do you have a repository containing the current state of your patche
> > somewhere? There's been so much cleanup that it's hard to review these
> > patches against the current mainline codebase.
>
> Christoph,
>
> Yesterday (April 25, 2011), Greg checked in all of the outstanding hv patches. So, if
> You checkout Greg's tree today, you will get the most recent hv codebase. This current
> patch-set is against Greg's current tree.

It's also always in the linux-next tree, which is easier for most people
to work off of.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> This patch-set addresses some of the bus/driver model cleanup that
> Greg sugested over the last couple of days. In this patch-set we
> deal with the following issues:
>
> 1) Cleanup unnecessary state in struct hv_device and
> struct hv_driver to be compliant with the Linux
> Driver model.
>
> 2) Cleanup the vmbus_match() function to conform with the
> Linux Driver model.
>
> 3) Cleanup error handling in the vmbus_probe() and
> vmbus_child_device_register() functions. Fixed a
> bug in the probe failure path as part of this cleanup.
>
> 4) The Windows host cannot handle the vmbus_driver being
> unloaded and subsequently loaded. Cleanup the driver with
> this in mind.

I've stopped at this patch (well, I applied one more, but you can see
that.)

I'd like to get some confirmation that this is really what you all want
to do here before applying it. If it is, care to resend them with a bit
more information about this issue and why you all are making it?

Anyway, other than this one, the series looks good. But you should
follow-up with some driver structure changes like what Christoph said to
do. After that, do you want another round of review of the code, or do
you have more things you want to send in (like the name[64] removal?)

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Tuesday, April 26, 2011 7:29 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Tue, Apr 26, 2011 at 09:19:45AM -0700, K. Y. Srinivasan wrote:
> > This patch-set addresses some of the bus/driver model cleanup that
> > Greg sugested over the last couple of days. In this patch-set we
> > deal with the following issues:
> >
> > 1) Cleanup unnecessary state in struct hv_device and
> > struct hv_driver to be compliant with the Linux
> > Driver model.
> >
> > 2) Cleanup the vmbus_match() function to conform with the
> > Linux Driver model.
> >
> > 3) Cleanup error handling in the vmbus_probe() and
> > vmbus_child_device_register() functions. Fixed a
> > bug in the probe failure path as part of this cleanup.
> >
> > 4) The Windows host cannot handle the vmbus_driver being
> > unloaded and subsequently loaded. Cleanup the driver with
> > this in mind.
>
> I've stopped at this patch (well, I applied one more, but you can see
> that.)
>
> I'd like to get some confirmation that this is really what you all want
> to do here before applying it. If it is, care to resend them with a bit
> more information about this issue and why you all are making it?

Greg, this is restriction imposed by the Windows host: you cannot reload the
Vmbus driver without rebooting the guest. If you cannot re-load, what good is it
to be able to unload? Distros that integrate these drivers will load these drivers
automatically on boot and there is not much point in being able to unload this since
most likely the root device will be handled by these drivers. For systems that don't
integrate these drivers; I don't see much point in allowing the driver to be unloaded,
if you cannot reload the driver without rebooting the guest. If and when the Windows
host supports reloading the vmbus driver, we can very easily add this functionality.
The situation currently at best very misleading - you think you can unload the vmbus
driver, only to discover that you have to reboot the guest!

>
> Anyway, other than this one, the series looks good. But you should
> follow-up with some driver structure changes like what Christoph said to
> do.

I will send you a patch for this.

> After that, do you want another round of review of the code, or do
> you have more things you want to send in (like the name[64] removal?)

I would prefer that we go through the review process. What is the process for
this review? Is there a time window for people to respond. I am hoping I will be able
to address all the review comments well in advance of the next closing of the tree,
with the hope of taking the vmbus driver out of staging this go around (hope springs
eternal in the human breast ...)!

Regards,

K. Y
>
> thanks,
>
> greg k-h

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks that have been setup as IDE
> disks for the guest - as specified in the guest configuration.
>
> On the SCSI side, we emulate a SCSI HBA. Devices configured
> under the SCSI controller for the guest are handled via this
> emulated HBA (SCSI front-end). So, SCSI disks configured for
> the guest are handled through native SCSI upper-level drivers.
> If this SCSI front-end driver is not loaded, currently, the guest
> cannot see devices that have been configured as SCSI devices.
> So, while the virtual block driver described earlier could potentially
> handle all block devices, the implementation choices made on the host
> will not permit it. Also, the only SCSI device that can be currently configured
> for the guest is a disk device.
>
> Both the block device driver (hv_blkvsc) and the SCSI front-end
> driver (hv_storvsc) communicate with the host via unique channels
> that are implemented as bi-directional ring buffers. Each (storage)
> channel carries with it enough state to uniquely identify the device on
> the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> communication.

This doesn't really explain much at all. The only important piece
of information I can read from this statement is that both blkvsc
and storvsc only support disks, but not any other kind of device,
and that chosing either one is an arbitrary seletin when setting up
a VM configuration.

But this still isn't an excuse to implement a block layer driver for
a SCSI protocol, and it doesn't not explain in what way the two
protocols actually differ. You really should implement blksvs as a SCSI
LLDD, too - and from the looks of it it doesn't even have to be a
separate one, but just adding the ids to storvsc would do the work.
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > After that, do you want another round of review of the code, or do
> > you have more things you want to send in (like the name[64] removal?)
>
> I would prefer that we go through the review process. What is the process for
> this review?

The same as always, just ask.

> Is there a time window for people to respond.

No. We don't have time limits here, this is a community, we don't have
deadlines, you know that.

> I am hoping I will be able to address all the review comments well in
> advance of the next closing of the tree, with the hope of taking the
> vmbus driver out of staging this go around (hope springs eternal in
> the human breast ...)!

Yes, it would be nice, and I understand your the corporate pressures you
are under to get this done, and I am doing my best to fit the patch
review and apply cycle into my very-very-limited-at-the-moment spare
time.

As always, if you miss this kernel release, there's always another one 3
months away, so it's no big deal in the long-run.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Wednesday, April 27, 2011 8:28 PM
> To: KY Srinivasan
> Cc: ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 01:54:02AM +0000, KY Srinivasan wrote:
> > > After that, do you want another round of review of the code, or do
> > > you have more things you want to send in (like the name[64] removal?)
> >
> > I would prefer that we go through the review process. What is the process for
> > this review?
>
> The same as always, just ask.
>
> > Is there a time window for people to respond.
>
> No. We don't have time limits here, this is a community, we don't have
> deadlines, you know that.

Perhaps I did not properly formulate my question here. The review
process itself may be open-ended, and that is fine - we will fix all legitimate
issues/concerns in our drivers whether they are in the staging area or not.
My question was specifically with regards to the review process that may gate exiting
staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
you by early next week and ask for a review. I fully intend to address whatever review
comments I may get in a very timely manner. Assuming at some point in time after I ask
for this review there are no outstanding issues, would that be sufficient to exit staging?

>
> > I am hoping I will be able to address all the review comments well in
> > advance of the next closing of the tree, with the hope of taking the
> > vmbus driver out of staging this go around (hope springs eternal in
> > the human breast ...)!
>
> Yes, it would be nice, and I understand your the corporate pressures you
> are under to get this done, and I am doing my best to fit the patch
> review and apply cycle into my very-very-limited-at-the-moment spare
> time.

Greg, I do appreciate your ongoing help here.

Regards,

K. Y

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 02:26:13PM +0000, KY Srinivasan wrote:
> Perhaps I did not properly formulate my question here. The review
> process itself may be open-ended, and that is fine - we will fix all legitimate
> issues/concerns in our drivers whether they are in the staging area or not.
> My question was specifically with regards to the review process that may gate exiting
> staging. I am hoping to re-spin the remaining patches of the last patch-set and send it to
> you by early next week and ask for a review. I fully intend to address whatever review
> comments I may get in a very timely manner. Assuming at some point in time after I ask
> for this review there are no outstanding issues, would that be sufficient to exit staging?

If it looks acceptable to me, and there are no other objections from
other developers, then yes, that would be sufficient to move it out of
staging.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Wednesday, April 27, 2011 8:19 AM
> To: KY Srinivasan
> Cc: Christoph Hellwig; Greg KH; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > On the host side, Windows emulates the standard PC hardware
> > to permit hosting of fully virtualized operating systems.
> > To enhance disk I/O performance, we support a virtual block driver.
> > This block driver currently handles disks that have been setup as IDE
> > disks for the guest - as specified in the guest configuration.
> >
> > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > under the SCSI controller for the guest are handled via this
> > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > the guest are handled through native SCSI upper-level drivers.
> > If this SCSI front-end driver is not loaded, currently, the guest
> > cannot see devices that have been configured as SCSI devices.
> > So, while the virtual block driver described earlier could potentially
> > handle all block devices, the implementation choices made on the host
> > will not permit it. Also, the only SCSI device that can be currently configured
> > for the guest is a disk device.
> >
> > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > driver (hv_storvsc) communicate with the host via unique channels
> > that are implemented as bi-directional ring buffers. Each (storage)
> > channel carries with it enough state to uniquely identify the device on
> > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > communication.
>
> This doesn't really explain much at all. The only important piece
> of information I can read from this statement is that both blkvsc
> and storvsc only support disks, but not any other kind of device,
> and that chosing either one is an arbitrary seletin when setting up
> a VM configuration.
>
> But this still isn't an excuse to implement a block layer driver for
> a SCSI protocol, and it doesn't not explain in what way the two
> protocols actually differ. You really should implement blksvs as a SCSI
> LLDD, too - and from the looks of it it doesn't even have to be a
> separate one, but just adding the ids to storvsc would do the work.

On the host-side, as part of configuring a guest you can specify block devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
the devices enumerated will not include block devices configured under the IDE
controller. So, it is not clear to me how I can do what you are proposing given the
restrictions imposed by the host.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:]
> > Sent: Wednesday, April 27, 2011 8:19 AM
> > To: KY Srinivasan
> > Cc: Christoph Hellwig; Greg KH; ; linux-;
> > ;
> > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> >
> > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > On the host side, Windows emulates the standard PC hardware
> > > to permit hosting of fully virtualized operating systems.
> > > To enhance disk I/O performance, we support a virtual block driver.
> > > This block driver currently handles disks that have been setup as IDE
> > > disks for the guest - as specified in the guest configuration.
> > >
> > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > under the SCSI controller for the guest are handled via this
> > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > the guest are handled through native SCSI upper-level drivers.
> > > If this SCSI front-end driver is not loaded, currently, the guest
> > > cannot see devices that have been configured as SCSI devices.
> > > So, while the virtual block driver described earlier could potentially
> > > handle all block devices, the implementation choices made on the host
> > > will not permit it. Also, the only SCSI device that can be currently configured
> > > for the guest is a disk device.
> > >
> > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > driver (hv_storvsc) communicate with the host via unique channels
> > > that are implemented as bi-directional ring buffers. Each (storage)
> > > channel carries with it enough state to uniquely identify the device on
> > > the host side. Microsoft has chosen to use SCSI verbs for this storage channel
> > > communication.
> >
> > This doesn't really explain much at all. The only important piece
> > of information I can read from this statement is that both blkvsc
> > and storvsc only support disks, but not any other kind of device,
> > and that chosing either one is an arbitrary seletin when setting up
> > a VM configuration.
> >
> > But this still isn't an excuse to implement a block layer driver for
> > a SCSI protocol, and it doesn't not explain in what way the two
> > protocols actually differ. You really should implement blksvs as a SCSI
> > LLDD, too - and from the looks of it it doesn't even have to be a
> > separate one, but just adding the ids to storvsc would do the work.
>
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv).

Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.

We really don't want to write new IDE drivers anymore that don't use
libata.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Greg KH [mailto:]
> Sent: Friday, April 29, 2011 12:40 PM
> To: KY Srinivasan
> Cc: Christoph Hellwig; ; linux-;
> ;
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Christoph Hellwig [mailto:]
> > > Sent: Wednesday, April 27, 2011 8:19 AM
> > > To: KY Srinivasan
> > > Cc: Christoph Hellwig; Greg KH; ; linux-
> ;
> > > ;
> > > Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> > >
> > > On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote:
> > > > On the host side, Windows emulates the standard PC hardware
> > > > to permit hosting of fully virtualized operating systems.
> > > > To enhance disk I/O performance, we support a virtual block driver.
> > > > This block driver currently handles disks that have been setup as IDE
> > > > disks for the guest - as specified in the guest configuration.
> > > >
> > > > On the SCSI side, we emulate a SCSI HBA. Devices configured
> > > > under the SCSI controller for the guest are handled via this
> > > > emulated HBA (SCSI front-end). So, SCSI disks configured for
> > > > the guest are handled through native SCSI upper-level drivers.
> > > > If this SCSI front-end driver is not loaded, currently, the guest
> > > > cannot see devices that have been configured as SCSI devices.
> > > > So, while the virtual block driver described earlier could potentially
> > > > handle all block devices, the implementation choices made on the host
> > > > will not permit it. Also, the only SCSI device that can be currently configured
> > > > for the guest is a disk device.
> > > >
> > > > Both the block device driver (hv_blkvsc) and the SCSI front-end
> > > > driver (hv_storvsc) communicate with the host via unique channels
> > > > that are implemented as bi-directional ring buffers. Each (storage)
> > > > channel carries with it enough state to uniquely identify the device on
> > > > the host side. Microsoft has chosen to use SCSI verbs for this storage
> channel
> > > > communication.
> > >
> > > This doesn't really explain much at all. The only important piece
> > > of information I can read from this statement is that both blkvsc
> > > and storvsc only support disks, but not any other kind of device,
> > > and that chosing either one is an arbitrary seletin when setting up
> > > a VM configuration.
> > >
> > > But this still isn't an excuse to implement a block layer driver for
> > > a SCSI protocol, and it doesn't not explain in what way the two
> > > protocols actually differ. You really should implement blksvs as a SCSI
> > > LLDD, too - and from the looks of it it doesn't even have to be a
> > > separate one, but just adding the ids to storvsc would do the work.
> >
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-
> end which is
> > the scsi driver (storvsc_drv).
>
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.

If we don't load the blkvsc driver, the emulated IDE controller exposed to
the guest can and will be seen by the libata core. In this case though, your
disk I/O will be taking the emulated path with the usual performance hit.

When you load the blkvsc driver, the device access does not go through the emulated
IDE controller. Blkvsc is truly a generic block driver that registers as a block driver in
the guest and talks to an appropriate device driver on the host, communicating over
the vmbus. In this respect, it is identical to block drivers we have for guests in other
virtualization platforms (Xen etc.). The only difference is that on the host side,
the only way you can assign a scsi disk to the guest is to configure this scsi disk
under the scsi controller. So, while blkvsc is a generic block driver, because of the
restrictions on the host side, it only ends up managing block devices that have IDE majors.

>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

As I noted earlier, it is incorrect to view Hyper-V blkvsc driver as an IDE driver. There
is nothing IDE specific about it. It is very much like other block front-end drivers
(like in Xen) that get their device information from the host and register the block
device accordingly with the guest. It just happens that in the current version of the
Windows host, only devices that are configured as IDE devices in the host end up being
managed by this driver. To make this clear, in my recent cleanup of this driver (these patches
have been applied), all IDE major information has been properly consolidated.

Regards,

K. Y


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
This is a resend of the patches yet to be applied.
This patch-set addresses some of the bus/driver model cleanup that
Greg sugested over the last couple of days. In this patch-set we
deal with the following issues:


1) Cleanup error handling in the vmbus_probe() and
vmbus_child_device_register() functions. Fixed a
bug in the probe failure path as part of this cleanup.

2) The Windows host cannot handle the vmbus_driver being
unloaded and subsequently loaded. Cleanup the driver with
this in mind.

3) Get rid of struct hv_bus that embedded struct bus_type to
conform with the LDM.

4) Add probe/remove/shutdown functions to struct hv_driver to
conform to LDM.

5) On some older Hyper-V hosts, the Linux PCI sub-sytem is not able
to allocate irq resources to the vmbus driver. I recently learnt
that the vmbus driver is an acpi enumerated device on the Hyper-V
platform. Added code to retrieve irq information from DSDT.



Regards,

K. Y
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> On the host-side, as part of configuring a guest you can specify block devices
> as being under an IDE controller or under a
> SCSI controller. Those are the only options you have. Devices configured under
> the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> the devices enumerated will not include block devices configured under the IDE
> controller. So, it is not clear to me how I can do what you are proposing given the
> restrictions imposed by the host.

Just because a device is not reported by REPORT_LUNS doesn't mean you
can't talk to it using a SCSI LLDD. We have SCSI transports with all
kinds of strange ways to discover devices. Using scsi_add_device you
can add LUNs found by your own discovery methods, and use all the
existing scsi command handling.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> Are you sure the libata core can't see this ide controller and connect
> to it? That way you would use the scsi system if you do that and you
> would need a much smaller ide driver, perhaps being able to merge it
> with your scsi driver.
>
> We really don't want to write new IDE drivers anymore that don't use
> libata.

The blkvsc driver isn't an IDE driver, although it currently claims
the old IDE drivers major numbers, which is a no-no and can't work
in most usual setups. I'm pretty sure I already complained about
this in a previous review round.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)


> -----Original Message-----
> From: Christoph Hellwig [mailto:]
> Sent: Sunday, May 01, 2011 11:41 AM
> To: Greg KH
> Cc: KY Srinivasan; Christoph Hellwig; ; linux-
> ; ;
>
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
>
> On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
> > Are you sure the libata core can't see this ide controller and connect
> > to it? That way you would use the scsi system if you do that and you
> > would need a much smaller ide driver, perhaps being able to merge it
> > with your scsi driver.
> >
> > We really don't want to write new IDE drivers anymore that don't use
> > libata.
>
> The blkvsc driver isn't an IDE driver, although it currently claims
> the old IDE drivers major numbers, which is a no-no and can't work
> in most usual setups.

What is the issue here? This is no different than what is done in other
Virtualization platforms. For instance, the Xen blkfront driver is no
different - if you specify the block device to be presented to the guest
as an ide device, it will register for the appropriate ide major number.

Regards,

K. Y

> I'm pretty sure I already complained about
> this in a previous review round.


_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Sun, May 01, 2011 at 11:39:21AM -0400, Christoph Hellwig wrote:
> On Fri, Apr 29, 2011 at 04:32:35PM +0000, KY Srinivasan wrote:
> > On the host-side, as part of configuring a guest you can specify block devices
> > as being under an IDE controller or under a
> > SCSI controller. Those are the only options you have. Devices configured under
> > the IDE controller cannot be seen in the guest under the emulated SCSI front-end which is
> > the scsi driver (storvsc_drv). So, when you do a bus scan in the emulated scsi front-end,
> > the devices enumerated will not include block devices configured under the IDE
> > controller. So, it is not clear to me how I can do what you are proposing given the
> > restrictions imposed by the host.
>
> Just because a device is not reported by REPORT_LUNS doesn't mean you
> can't talk to it using a SCSI LLDD. We have SCSI transports with all
> kinds of strange ways to discover devices. Using scsi_add_device you
> can add LUNs found by your own discovery methods, and use all the
> existing scsi command handling.

Yeah, it seems to me that no matter how the user specifies the disk
"type" for the guest configuration, we should use the same Linux driver,
with the same naming scheme for both ways.

As Christoph points out, it's just a matter of hooking the device up to
the scsi subsystem. We do that today for ide, usb, scsi, and loads of
other types of devices all with the common goal of making it easier for
userspace to handle the devices in a standard manner.

thanks,

greg k-h
_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)
On Sun, May 01, 2011 at 03:46:23PM +0000, KY Srinivasan wrote:
> What is the issue here? This is no different than what is done in other
> Virtualization platforms. For instance, the Xen blkfront driver is no
> different - if you specify the block device to be presented to the guest
> as an ide device, it will register for the appropriate ide major number.

No, it won't - at least not in mainline just because it's so buggy.
If distros keep that crap around I can only recommed you to not use
them.

_______________________________________________
devel mailing list

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
)