virtual StorPortInitialize failing when called for hiber or dump

When a crash or hibernate happens, my virtual storport DriverEntry is
called, but then the call to StorPortInitialize fails with 0xC0000059
which appears to be STATUS_REVISION_MISMATCH.

I’m obviously not setting something up right, but can anyone suggest
what? The obvious thing might be the Version field in the DUMP_POINTERS
but I am setting that to DUMP_MINIPORT_VERSION_1 as per the docs.

Thanks

James

dump port doesn’t understand virtual model. You should pass non-virtual flavor of HW_INITIALIZATION_DATA to StorPortInitialize.

Ah - yes good point. And James has virtualized hardware underneath his
storport device, (the xen interface) so other than the convenience of
being able to code outside the storport hardware ddi box, he has no
need I can see to use the virtual storport model.

Mark Roddy

On Mon, Jan 17, 2011 at 1:22 PM, wrote:
> dump port doesn’t understand virtual model. You should pass non-virtual flavor of HW_INITIALIZATION_DATA to StorPortInitialize.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

>

dump port doesn’t understand virtual model. You should pass
non-virtual flavor
of HW_INITIALIZATION_DATA to StorPortInitialize.

Thanks! I’ll try that ASAP.

James

>

Ah - yes good point. And James has virtualized hardware underneath his
storport device, (the xen interface) so other than the convenience of
being able to code outside the storport hardware ddi box, he has no
need I can see to use the virtual storport model.

Correct. I need to make calls into my bus driver, which include:
. Allocate/Free ‘grant references’ which is the mechanism Xen uses to
grant memory from one VM to another
. Notify Xen that there is a new item on the comms ring

All of that can be done at any IRQL (grant reference freelist is lock
free), and the disk driver has existed forever as a scsiport driver just
fine except for some hibernation issues under 2008.

I’d be pretty much able to use a hardware storport driver except for
that the Xen comms ring requires that buffers are aligned to a sector
(512 byte) boundary, requiring double buffering in some cases - Windows
mostly aligns all buffers except for the first few calls during boot,
during a chkdsk and format, and probably a few other occasions. Also I
found some strange things when developing a scsi passthrough driver (eg
for tape drives) with storport that it wouldn’t give me >64KB buffers as
I wasn’t attached to a real hardware bus.

James

Mark Roddy

On Mon, Jan 17, 2011 at 1:22 PM, wrote:
> > dump port doesn’t understand virtual model. You should pass
non-virtual
> flavor of HW_INITIALIZATION_DATA to StorPortInitialize.
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

> Ah - yes good point. And James has virtualized hardware underneath his storport device

Back when we started writing the Xen PV drivers in the company before my current one, we couldn’t figure out how to get SCSIPort to work as a child device of anything but the PCI bus - and I thought that was also the general consensus around here. I never looked into what specifically allows this, was there some trick?

Anyway, the solution was to have a somewhat strange relationship between the xen disk and bus driver… The virtual storport miniport eliminated the need for that strange relationship.

James, remember that the function prototypes are different for the virtual find adapter and the non-virtual one - so remember that in the case of dump and hiber, you need to grab your pointer to HW_INITIALIZATION_DATA from a different variable.

>

> Ah - yes good point. And James has virtualized hardware underneath
his
storport device

Back when we started writing the Xen PV drivers in the company before
my
current one, we couldn’t figure out how to get SCSIPort to work as a
child
device of anything but the PCI bus - and I thought that was also the
general
consensus around here. I never looked into what specifically allows
this, was
there some trick?

The bus driver enumerates everything as a PNPBus device. The scsiport
driver identifies itself up as a PNPBus device, and it all kind of just
works. I know I had a few false starts when writing the driver initially
but not with enumeration.

A scsiport device does have to have a memory or io mapped resource for
some reason though, which I had to fake.

I also re-export the PCI Bus’s BUS_INTERFACE_STANDARD interface to my
child devices which fixes a few problems I was seeing under 64 bit.

Anyway, the solution was to have a somewhat strange relationship
between the
xen disk and bus driver… The virtual storport miniport eliminated
the need
for that strange relationship.

James, remember that the function prototypes are different for the
virtual
find adapter and the non-virtual one - so remember that in the case of
dump
and hiber, you need to grab your pointer to HW_INITIALIZATION_DATA
from a
different variable.

Yep. Someone else pointed that out. Haven’t tested it yet but will do so
shortly. In retrospect it should have been obvious to me given the error
I was seeing :slight_smile:

Thanks

James

>that the Xen comms ring requires that buffers are aligned to a sector

(512 byte) boundary, requiring double buffering in some cases - Windows
mostly aligns all buffers except for the first few calls during boot

Very strange that Windows violates its own rules.

Have you tried to set the alignment requirement in your miniport?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>

>that the Xen comms ring requires that buffers are aligned to a sector
>(512 byte) boundary, requiring double buffering in some cases -
Windows
>mostly aligns all buffers except for the first few calls during boot

Very strange that Windows violates its own rules.

I don’t think windows makes any promises about alignment. It just
happens that any buffers allocated in the kernel larger than 4K will be
page aligned (and therefore sector aligned).

I think there might have been an ancient sector alignment requirement
under the Linux kernel which has been inherited by everything since. Or
maybe it’s just something that seemed like a good idea at the time.
Either way, I’m stuck with it for now.

Have you tried to set the alignment requirement in your miniport?

According to the docs my choices for an alignment mask are 0, 1, 3, or
7, being for 1, 2, 4, or 8 byte alignment. I’ve tried giving an
alignment mask of 511 for 512 byte alignment but windows just ignores my
request.

James

>I don’t think windows makes any promises about alignment.

Windows has a rule that the buffer pointers for noncached IO must be sector-aligned.

And you say “format” and “chkdsk” violate this.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>

>I don’t think windows makes any promises about alignment.

Windows has a rule that the buffer pointers for noncached IO must be
sector-
aligned.

And you say “format” and “chkdsk” violate this.

That is what I have observed. And when I say they violate this, I mean
that a large percentage of requests are not sector aligned. During boot
I’d estimate around 5-50 requests are seen by my driver, but obviously
that isn’t enough for any measurable performance impact.

Do you think that format and chkdsk would both read/write directly to
the disk as opposed to going via ntfs?

James

>Do you think that format and chkdsk would both read/write directly to

the disk as opposed to going via ntfs?

They are working on locked volume, so, this should be noncached IO.

Locked volume cannot have anything dirty in the cache.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com