> -----Original Message----- > From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx] > Sent: Sunday, May 01, 2011 4:53 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 Sun, May 01, 2011 at 06:08:37PM +0000, KY Srinivasan wrote: > > Could you elaborate on the problems/issues when the block driver registers for > the > > IDE majors. On the Qemu side, we have a mechanism to disable the emulation > when > > PV drivers load. I don't think there is an equivalent mechanism on the Windows > side. > > So, as far as I know, registering for the IDE majors is the only way to also > prevent native > > drivers in Linux from taking control of the emulated device. > > What qemu are you talking about for the qemu side? Upstream qemu > doesn't have any way to provide the same image as multiple devices, > nevermind dynamically unplugging bits in that case. Nor does it support > the hyperv devices. I am talking about the qemu that was (is) shipping with Xen. In Hyper-V, the block devices configured as IDE devices for the guest will be taken over by the native drivers if the PV drivers don't load first and take over the IDE majors. If you want to have the root device be managed by the PV drivers, this appears to be the only way to ensure that native IDE drivers don't take over the root device. Granted, this depends on ensuring the PV drivers load first, but I don't know if there is another way to achieve this. > > When you steal majors you rely on: > > a) loading earlier than the driver you steal them from > b) the driver not simple using other numbers > c) if it doesn't preventing it from working at all, also for > devices you don't "replace" with your PV devices. These are exactly the issues that had to be solved to have the PV drivers manage the root device. > d) that the guest actually uses the minors your claim, e.g. any > current linux distribution uses libata anyway, so you old IDE > major claim wouldn't do anything. Nor would claiming sd majors > as the low-level libata driver would still drive the hardware > even if SD doesn't bind to it. By setting up appropriate modprobe rules, this can be addressed. > > You really must never present the same device as two emulated devices > instead of doing such hacks. Agreed; I am not sure what the right solution for Hyper-V is other than (a) preventing the native IDE drivers from loading and (b) having the right modprobe rules to ensure libata would not present these same devices to the guest as scsi devices. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
