> -----Original Message----- > From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx] > Sent: Monday, May 02, 2011 5:35 PM > To: KY Srinivasan > Cc: Greg KH; gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx > 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: > > http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=blob;f=config- > generic;h=779415bcc036b922ba92de9c4b15b9da64e9707c;hb=HEAD > > http://gitorious.org/opensuse/kernel- > source/blobs/master/config/x86_64/default 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. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
