-----Original Message-----
From: Christoph Hellwig [mailto:hch@infradead.org]
Sent: Sunday, May 01, 2011 4:53 PM
To: KY Srinivasan
Cc: Greg KH; gregkh@suse.de; linux-kernel@vger.kernel.org;
devel@linuxdriverproject.org; virtualization@lists.osdl.org
Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

On Sun, May 01, 2011 at 06:08:37PM +0000, KY Srinivasan wrote:

quoted

Could you elaborate on the problems/issues when the block driver registers for

the

quoted

IDE majors. On the Qemu side, we have a mechanism to disable the emulation

when

quoted

PV drivers load. I don't think there is an equivalent mechanism on the Windows

side.

quoted

So, as far as I know, registering for the IDE majors is the only way to also

prevent native

quoted

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