MSI resource descriptors too long?

NTDEV
1

I’m looking at the CM_PARTIAL_RESORUCE_DESCRIPTOR definition in wdm.h in
the vista beta 2 WDK. IT contains this for message-signaled interrupts:

struct {
union {
struct {
USHORT DataPayload;
USHORT MessageCount;
ULONG Vector;
ULONG_PTR MessageTargetAddress;
} Raw;

struct {
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
} Translated;
};
} MessageInterrupt;

One of the reasons large memory BARs are being supported as they are
instaed of increasing the size of the Length field is backwards
compatiblity (or so I’m told). A resource can only have the equivalent
of 3 ULONGs in it. Maybe I’m counting wrong but on a 64-bit system the
Raw struct in that union has the equivalent of 4 ULONGs in it (ULONG_PTR
is 8 bytes, not 4 on a 64-bit system). So how does this work with
backward compatiblity? All drivers built using a previous DDK that have
more than one resource will have some serious problems, won’t they? Or
is backward compatibility no longer considered an issue?

Beverly

2

Brown, Beverly wrote:

I’m looking at the CM_PARTIAL_RESORUCE_DESCRIPTOR definition in wdm.h
in the vista beta 2 WDK. IT contains this for message-signaled interrupts:

struct {
union {
struct {
USHORT DataPayload;
USHORT MessageCount;
ULONG Vector;
ULONG_PTR MessageTargetAddress;
} Raw;

struct {
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
} Translated;
};
} MessageInterrupt;

One of the reasons large memory BARs are being supported as they are
instaed of increasing the size of the Length field is backwards
compatiblity (or so I’m told). A resource can only have the equivalent
of 3 ULONGs in it. Maybe I’m counting wrong but on a 64-bit system the
Raw struct in that union has the equivalent of 4 ULONGs in it
(ULONG_PTR is 8 bytes, not 4 on a 64-bit system). So how does this
work with backward compatiblity? All drivers built using a previous
DDK that have more than one resource will have some serious problems,
won’t they? Or is backward compatibility no longer considered an issue?

No, it’s just 4 dwords. The two USHORTs combine to one dword, Vector is
the second, and MessageTargetAddress is the 3rd and 4th.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Yes, I know that it’s 4 dwords. That’s the problem. It needs to be 3
dwords to match all the other descriptor types.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 01, 2006 3:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MSI resource descriptors too long?

Brown, Beverly wrote:

I’m looking at the CM_PARTIAL_RESORUCE_DESCRIPTOR definition in wdm.h
in the vista beta 2 WDK. IT contains this for message-signaled
interrupts:

struct {
union {
struct {
USHORT DataPayload;
USHORT MessageCount;
ULONG Vector;
ULONG_PTR MessageTargetAddress;
} Raw;

struct {
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
} Translated;
};
} MessageInterrupt;

One of the reasons large memory BARs are being supported as they are
instaed of increasing the size of the Length field is backwards
compatiblity (or so I’m told). A resource can only have the equivalent

of 3 ULONGs in it. Maybe I’m counting wrong but on a 64-bit system the

Raw struct in that union has the equivalent of 4 ULONGs in it
(ULONG_PTR is 8 bytes, not 4 on a 64-bit system). So how does this
work with backward compatiblity? All drivers built using a previous
DDK that have more than one resource will have some serious problems,
won’t they? Or is backward compatibility no longer considered an
issue?

No, it’s just 4 dwords. The two USHORTs combine to one dword, Vector is
the second, and MessageTargetAddress is the 3rd and 4th.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

It’s 3 dwords on x86 and that is the important backwards compat issue
here. The size of the union grew to 4 dwords when 64 bit windows was
introduced on server 2003 when KAFFINITY grew as well in the Interrupt
part of the union

struct {
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
} Interrupt;

The MessageInterrupt part of the union did not grow the overall size of
the union from the first release of 64 bit windows.

d

– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, June 01, 2006 1:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MSI resource descriptors too long?

Yes, I know that it’s 4 dwords. That’s the problem. It needs to be 3
dwords to match all the other descriptor types.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 01, 2006 3:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MSI resource descriptors too long?

Brown, Beverly wrote:

I’m looking at the CM_PARTIAL_RESORUCE_DESCRIPTOR definition in wdm.h
in the vista beta 2 WDK. IT contains this for message-signaled
interrupts:

struct {
union {
struct {
USHORT DataPayload;
USHORT MessageCount;
ULONG Vector;
ULONG_PTR MessageTargetAddress;
} Raw;

struct {
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
} Translated;
};
} MessageInterrupt;

One of the reasons large memory BARs are being supported as they are
instaed of increasing the size of the Length field is backwards
compatiblity (or so I’m told). A resource can only have the equivalent

of 3 ULONGs in it. Maybe I’m counting wrong but on a 64-bit system the

Raw struct in that union has the equivalent of 4 ULONGs in it
(ULONG_PTR is 8 bytes, not 4 on a 64-bit system). So how does this
work with backward compatiblity? All drivers built using a previous
DDK that have more than one resource will have some serious problems,
won’t they? Or is backward compatibility no longer considered an
issue?

No, it’s just 4 dwords. The two USHORTs combine to one dword, Vector is
the second, and MessageTargetAddress is the 3rd and 4th.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

OK. Thanks. I didn’t realize that KAFFINITY grew on 64-bit systems.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, June 02, 2006 12:57 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MSI resource descriptors too long?

It’s 3 dwords on x86 and that is the important backwards compat issue
here. The size of the union grew to 4 dwords when 64 bit windows was
introduced on server 2003 when KAFFINITY grew as well in the Interrupt
part of the union

struct {
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
} Interrupt;

The MessageInterrupt part of the union did not grow the overall size of
the union from the first release of 64 bit windows.

d

– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, June 01, 2006 1:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MSI resource descriptors too long?

Yes, I know that it’s 4 dwords. That’s the problem. It needs to be 3
dwords to match all the other descriptor types.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 01, 2006 3:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MSI resource descriptors too long?

Brown, Beverly wrote:

I’m looking at the CM_PARTIAL_RESORUCE_DESCRIPTOR definition in wdm.h
in the vista beta 2 WDK. IT contains this for message-signaled
interrupts:

struct {
union {
struct {
USHORT DataPayload;
USHORT MessageCount;
ULONG Vector;
ULONG_PTR MessageTargetAddress;
} Raw;

struct {
ULONG Level;
ULONG Vector;
KAFFINITY Affinity;
} Translated;
};
} MessageInterrupt;

One of the reasons large memory BARs are being supported as they are
instaed of increasing the size of the Length field is backwards
compatiblity (or so I’m told). A resource can only have the equivalent

of 3 ULONGs in it. Maybe I’m counting wrong but on a 64-bit system the

Raw struct in that union has the equivalent of 4 ULONGs in it
(ULONG_PTR is 8 bytes, not 4 on a 64-bit system). So how does this
work with backward compatiblity? All drivers built using a previous
DDK that have more than one resource will have some serious problems,
won’t they? Or is backward compatibility no longer considered an
issue?

No, it’s just 4 dwords. The two USHORTs combine to one dword, Vector is
the second, and MessageTargetAddress is the 3rd and 4th.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer