[Openib-windows] Diskless Windows with SRP

[Robert H.B. Netzer]

Hi all.  I work for System Fabric Works, in Austin TX, and this post
is about a diskless SRP boot solution for Windows that I am working on
that uses the Windows OpenIB drivers.  I would like to solicit advice
on a problem I have on determining which Windows disk device objects
correspond to SRP targets as opposed to local disks.  If there is
interest, I will be happy to describe the entire boot solution in
detail.  Here is the short story:

I have Windows Server 2003 R2 x64 booting and running (diskless) using
a custom int13 SRP-based boot loader and a recent snapshot of the
Windows OpenIB stack which mounts the system drive via SRP, using an
Arbel HCA in Tavor mode currently.

We use Etherboot (burned into the HCA's option ROM) to load an
int13-based secondary boot loader which performs SRP target discovery
and boots the first target found that has a bootable partition.
Because this loader hooks the BIOS int13 vector, it remains available
to NTLDR for loading of the Windows boot-start drivers.  I made the
ib_bus, ib_iou, ib_srp, thca, and mt23108 drivers boot-start instead
of demand-start so they are loaded by NTLDR and started very early in
the boot process to become usable for mounting the Windows boot volume
(i.e., the filesystem containing the Windows directory etc).

There were a few misc details such as getting the HCA fully reset and
delaying the boot process long enough for SRP target discovery to
complete so that all IB devices could be enumerated, but I used filter
drivers to accomplish those tasks so I wouldn't have to make code
changes to the OpenIB drivers.

This all works nicely up to the point where Windows mounts the boot
volume, which is where my problem lies.  The kernel finds it by
looking at the boot.ini file (read by NTLDR via int13's) which
contains (among other things) an "arcname" path with the disk# and
partition# to mount like

    multi(0)disk(0)rdisk(0)partition(1)

The kernel seems to map this to a disk device by looking up this name
in the Windows object name space under \Arcname (e.g., by looking up
"\Arcname\multi(0)disk(0)rdisk(0)partition(1)") which should be a
symlink object that names a disk block device in the object name space
such as \Device\HardDisk0\Partition1 (note that this is a Windows
symlink object, not a filesystem symlink).  The kernel thus mounts the
filesystem on this partition.

My auxiliary driver needs to add this symlink.  The problem is finding
out which of the \Device\HardDisk%d devices correspond to SRP targets
as opposed to local disks.  This is important since there might be
bootable local drives which I don't want to boot from.  (Also, in my
particular application, it's OK to use any of the bootable SRP targets
discovered.)  Right now I'm simply always setting it to
\Device\Harddisk0\Partition1 since I have no local drives on my test
system, and this works but it isn't a general solution.

I assume that the Disk class driver creates these objects after the
SRP SCSI miniport initializes.  The question is: Does anyone know how
I can determine on behalf of which miniport each disk device was
created?  It's easy enough to figure out how many \Device\HardDisk%d
devices there are (via IoGetConfigurationInformation) and to get the
device object pointer each one, but at this point I'm stuck.

Any advice would be appreciated.

Rob Netzer
System Fabric Works, Inc.
rob at systemfabricworks.com