[PATCH]: Staging: hv: Allocate the vmbus irq dynamically

[Greg KH]

On Mon, Feb 21, 2011 at 03:51:56PM +0100, Thomas Gleixner wrote:
> On Mon, 21 Feb 2011, KY Srinivasan wrote:
> > > > > There are various ways to solve that proper.
> > > > >
> > > > >  - You can provide the interrupt number from ACPI/PCI or whatever your HV
> > > > >    provides as enumeration.
> > > > >
> > > > >  - Use a fixed vector like XEN does for the event channel
> > > > >
> > > > >  - Use dynamic allocation in the IOAPIC space like the kernel does for
> > > > >    MSI(-X)
> > > > >
> > > > > Thanks,
> > > > >
> > > > > 	tglx
> > > >
> > > > I am not claiming that what I have done here is the best possible solution.
> > > > However, I will submit to you that it is better than what we had here
> > > > prior to this patch.  I will address this and a  whole lot of other issues
> > > > in future patches.
> > > 
> > > No, it's _NOT_ better in any way. You trade breaking your PV thing
> > > against breaking random other drivers. Care to explain why you think
> > > that's better ?
> > 
> > The root device for the VM is bound to the PV driver on some distributions.
> > So, if we cannot load the PV drivers, we do not have a system that boots.
> > In general, the system performance without these PV drivers is so poor that
> > for all practical purposes, having the PV drivers is almost a requirement
> > for having a useable system. While the platform supports configuration of the VM with
> > some emulated devices, it is not a recommended configuration (because of
> > performance reasons) for Linux virtual machines on the Hyper-V platform.
> 
> It does not matter whether it's recommended or not. If it results in a
> non usable emulated device it's broken. Just imagine you grab the
> serial interrupt, which results in not having a debug console. Not at
> all acceptable.
>  
> > I have spent significantly more time debating this patch than
> > developing this patch that I still think improves the current
> > driver. I will leave it to Greg and other powers that be to decide
> > if this patch will be accepted. Let me know what your verdict is.
> 
> As I said, any other clean solution (and I pointed out 3) over this
> hack.

Yeah, that sounds like the best solution, let's not cause accidental
breakage of systems that were working already.

KY, care to fix this up properly now?  There's no rush to take your
previous patch, as that is working ok for now, right?

thanks,

greg k-h