[PATCH 00/25] Staging: hv: Cleanup vmbus driver code
kys at microsoft.com
Mon May 2 22:11:48 UTC 2011
> -----Original Message-----
> From: Christoph Hellwig [mailto:hch at infradead.org]
> Sent: Monday, May 02, 2011 5:35 PM
> To: KY Srinivasan
> Cc: Greg KH; gregkh at suse.de; linux-kernel at vger.kernel.org;
> devel at linuxdriverproject.org; virtualization at lists.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> On Mon, May 02, 2011 at 09:16:36PM +0000, KY Srinivasan wrote:
> > > That assumes libata is a module, which it is not for many popular
> > > distributions.
> > >
> > As long as you can prevent ata_piix from loading, it should be fine.
> Again, this might very well be built in, e.g. take a look at:
Good point! For what it is worth, last night I hacked up code
to present the block devices currently managed by the blkvsc
driver as scsi devices. I have still retained the blkvsc driver to
handshake with the host and sert up the channel etc. Rather than
presenting this device as an IDE device to the guest, as you had
suggested, I am adding this device as a scsi device under the HBA
implemented by the storvsc driver. I have assigned a special channel
number to distinguish these IDE disks, so that on the I/O paths we can
communicate over the appropriate channels. Given that the host is
completely oblivious to this arrangement on the guest, I suspect
we don't need to worry about future versions of Windows breaking this.
From, very minimal testing I have done, things appear to work well.
However, the motherboard emulation in Hyper-V requires the boot
device to be an IDE device and other than taking over the IDE majors, I don't
know of a way to prevent the native drivers from taking over the boot device.
On SLES, I had implemented modprobe rules to deal with the issue you had
mentioned; it is not clear what the general solution might be for this problem if any,
other than changes to the host.
More information about the devel