[Openib-windows] Diskless Windows with SRP
leonid at mellanox.co.il
Tue Jun 20 02:30:21 PDT 2006
Maybe, use IoGetDeviceProperty() or/and scan the Registry under
> -----Original Message-----
> From: openib-windows-bounces at openib.org
> [mailto:openib-windows-bounces at openib.org] On Behalf Of
> Robert H.B. Netzer
> Sent: Monday, June 19, 2006 9:40 PM
> To: openib-windows at openib.org
> Subject: [Openib-windows] Diskless Windows with SRP
> 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
> 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
> openib-windows mailing list
> openib-windows at openib.org
More information about the ofw