Kernel Mode Drivers in 64bit Systems: Migration and Development

Artigo
01/21/2022

Posted November 16, 2004

Chat Date: November 11, 2004

Please note: Portions of this transcript have been edited for clarity

Introduction

Justin (Moderator):
Welcome to today’s chat about “Kernel Mode Drivers in 64bit Systems: Migration and Development.” We are pleased to welcome our experts for today. I will have them introduce themselves now.

Forrest (Expert):
Greetings! I am Forrest Foltz, Systems Architect, Windows NT Base Development - As an architect for the base team, my primary focus is the porting and support of the Windows NT code base on new platforms, including the IA64 and most recently the AMD64 platform. I also participate in the definition of the future of Microsoft's enterprise operating system offerings.

Nar Ganapathy (Expert):
Hi. I am Nar Ganapathy. I am an Architect in the Windows Device Experience group working on improving our I/O subsystem and driver models.

Justin (Moderator):
We will try to answer as many questions as we can today. Participants should type their questions, click “Submit a question,” and click “Send.” Those posts will go into a private queue, from which our experts will draft answers and repost questions in the upper window with their answers. (To confirm: if you clicked “Submit a question” when you posted, you don’t need to resubmit. We’ll get to them as soon as we can before the end of the chat (noon Pacific).

Nar Ganapathy (Expert):
A reminder: We completed the 64-bit webcast series last week; thirteen sessions of in-depth content on 64-bit issues, including: Kernel Mode Drivers in Windows 64-bit Systems Migration and Development. To view the sessions on-demand: https://www.microsoft.com/seminar/events/series/msdn64bitwin.mspx

Start of Chat

Forrest (Expert):
Q: Forrest, you stated " including the IA64 and most recently the AMD64 platform", are you also implying EM64T and Athlon 64 systems?
A: Yes, sorry, that should read x64 which is our name for both AMD64 and, now, EM64T. Old habits die hard.

Nar Ganapathy (Expert):
Q: Can 64bit drivers run under 32bit environment? Or do we have to compile separate binary for 32 bits and 64 bits?
A: No. A 64 bit driver cannot run under a 32 bit OS environment. A 32 bit OS environment can only run 32 bit binaries. A 64 bit OS can run 64 bit and 32 bit applications but only 64 bit drivers. So you have to compile separate binaries. You can use a single source code base and build two separate binaries from them. The DDK build environment supports this.

Justin (Moderator):
For those just joining us, today’s chat is about “Kernel Mode Drivers in 64bit Systems: Migration and Development.” To post a question, please click “Submit a question,” type your question, and click “Send.” That way, we can track which questions we still need to answer.

Nar Ganapathy (Expert):
Q: How do I go about building my x64 device driver from Whidbey, if that's possible. What DDK do I need?
A: You cannot use the visual studio environment to develop drivers. You have to use the DDK (which does not have an IDE). To build an x64 device driver, install the windows server 2003 SP1 beta DDK and use it. You have to sign up for windows server 2003 SP1 beta program.

Forrest (Expert):
Q: What floating support is available for an X64 Kernel Driver?
A: x64 includes the full sse2 set of xmm instructions and register set (16 128-bit registers). These are available for use in user- and kernel-mode. While legacy x87 floating point state is context swapped between 32- and 64-bit applications running on an x64 system, they must *NOT* be used by a kernel mode component. The MS runtimes use xmm exclusively for floating point operations.

Forrest (Expert):
Q: In an x64 device driver can I have an "_asm" subroutine? Are there different intrinsics (??) for the AMD64 opcodes versus EMT64 opcodes? Do both sets come with the DDK?
A: While the 32-bit x86 compiler supports inline _asm, the x64 and IA64 compilers do not (by design). Asm code for these platforms must reside in a separate .asm source module. Because the x64 instruction set is so similar to the x86 instruction set, there is a temptation to "cut-n-paste" x86 code to x64 and fix it up until it assembles cleanly. The problem here is that the calling standard is quite different on x64, particularly w.r.t. stack use and well-formed prologues and epilogues required for proper exception handling. The x64 calling standard document is included in the SDK and DDK.

Forrest (Expert):
Q: In an x64 device driver can I have an "_asm" subroutine? Are there different intrinsics (??) for the AMD64 opcodes versus EMT64 opcodes? Do both sets come with the DDK?
A: (continued) There are intrinsics for almost everything. The sse2 intrinsics are supported, as well as a variety of intrinsics for everything from retrieving the caller's address, saving eflags on entry to a function, interlocked operations, etc. The intrinsics available on AMD64 amd EM64T are identical, and are included in the SDK and DDK header files.

Nar Ganapathy (Expert):
Q: Couldn't one just use WMI to transfer information to (one's own) driver rather than using IOCTLs for communication?
A: WMI is certainly one way to communicate with a driver. Because its types are explicitly specified in a MOF file one does not have to do the thinking. The self describing MOF can be used to marshal the parameters. There are many drawbacks to WMI that make it unattractive for common user to kernel communication. WMI has high overhead. It does not support high performance buffering options. Discovering a WMI GUID in an application and using them is not trivial. IOCTL is much more easy to use. WMI is not good for transferring large amounts of data. WMI's advantages are that it can provide security per GUID (interface) and it can be remoted across machines automatically.

Forrest (Expert):
On a 64-bit system, all kernel drivers are 64-bit. So any IRP that originated from kernel mode (previousmode == kernel) is treated as a 64-bit ioctl. That is, IoIs32bitProcess( irp ) will return FALSE in such a case.

Forrest (Expert):
Q: How about the standard IOCTLs from kernel driver? How can we tell its from32bit thread or 64bit thread?
A: (here's the question that my previous answer was for)

Justin (Moderator):
Sly, that question is not closely related to today’s' topic. You might try looking elsewhere on TechNet or MSDN for help with that.

Justin (Moderator):
Unless anyone is this chat has additional questions, we will close it in about five minutes.

Justin (Moderator):
Thank you for joining us today on a Microsoft Community Chat to talk about “Kernel Mode Drivers in 64bit Systems: Migration and Development.” If you would like further information on this topic please visit the following URL(s): https://www.microsoft.com/whdc

Forrest (Expert):
Q: So is the x64 calling sequence to .asm routines similar to the IA64 (itanium 2) calling sequence?
A: At a high level, yes. There are "nested" functions, which perform stack manipulation, call other functions, save and use nonvolatile registers. "Leaf" functions are functions that don't do any of those things. Each nested function must include an initial set of instructions (the prologue) that correspond to unwind data, and a well-formed epilogue. The stack unwinder uses this information to perform stack unwinding. The result of all this is that entering and leaving try{} blocks, for example, incurs no runtime overhead, at the cost of more expensive exception handling and unwinding.

Forrest (Expert):
Q: So is the x64 calling sequence to .asm routines similar to the IA64 (itanium 2) calling sequence?
A: (continued) btw there is exactly one calling convention on x64, similar to fastcall: the first four non-floating parameters are passed in rax, rcx, r8, r9 respectively, with the remainder passed on the stack. Keywords such as __cdecl etc. are ignored when compiling for x64.

Top of page

Compartilhar via

Kernel Mode Drivers in 64bit Systems: Migration and Development

Recursos adicionais