Float types in NT drivers

NTDEV
1

On the first NT driver that I wrote I needed to handle some floating point
types and calculations but at the time could not get past the fact that I
got compiler errors whenever I included any of these types in the code. At
the time I remember running into a vague statement in a book alluding to the
fact that floating point types are not valid in kernel mode drivers. I am
wondering is this true and if so is there any way around it. Or am I wrong
and what could I have been doing wrong. Once again I might be writing a
driver where handling floating point types would be very helpful.

Thanks,
Mike Russell

2

Check out FLOATOBJ in the NT DDK. FLOATOBJ and the associated FLOATOBJ_Xxx
routines give you pretty straightforward floating point arithmetic support
in NT kernel mode.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Michael W. Russell
Sent: Wednesday, September 06, 2000 9:34 AM
To: NT Developers Interest List
Subject: [ntdev] Float types in NT drivers

On the first NT driver that I wrote I needed to handle some floating point
types and calculations but at the time could not get past the fact that I
got compiler errors whenever I included any of these types in the code. At
the time I remember running into a vague statement in a book alluding to the
fact that floating point types are not valid in kernel mode drivers. I am
wondering is this true and if so is there any way around it. Or am I wrong
and what could I have been doing wrong. Once again I might be writing a
driver where handling floating point types would be very helpful.

Thanks,
Mike Russell

You are currently subscribed to ntdev as: xxxxx@vanteon.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

3

My understanding of the rationale behind this was that NT did not save the
FP registers when switching from UM to KM (for performance) and for this
reason using FP/MMX instructions was a big no-no in KM. I suppose it is
possible to save these registers yourself on entry to your driver. On Win2K
I believe that the registers are saved as part of UM to KM transition, so
this is not necessary.

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Michael W. Russell [mailto:xxxxx@quatech.com]
Sent: Wednesday, September 06, 2000 6:34 AM
To: NT Developers Interest List
Subject: [ntdev] Float types in NT drivers

On the first NT driver that I wrote I needed to handle some floating point
types and calculations but at the time could not get past the fact that I
got compiler errors whenever I included any of these types in the code. At
the time I remember running into a vague statement in a book alluding to the
fact that floating point types are not valid in kernel mode drivers. I am
wondering is this true and if so is there any way around it. Or am I wrong
and what could I have been doing wrong. Once again I might be writing a
driver where handling floating point types would be very helpful.

4

NT 4.0 does not support floating point. I believe it is supported in W2K.

-----Original Message-----
From: Michael W. Russell [mailto:xxxxx@quatech.com]
Sent: Wednesday, September 06, 2000 6:34 AM
To: NT Developers Interest List
Subject: [ntdev] Float types in NT drivers

On the first NT driver that I wrote I needed to handle some
floating point
types and calculations but at the time could not get past
the fact that I
got compiler errors whenever I included any of these types
in the code. At
the time I remember running into a vague statement in a book
alluding to the
fact that floating point types are not valid in kernel mode
drivers. I am
wondering is this true and if so is there any way around it.
Or am I wrong
and what could I have been doing wrong. Once again I might
be writing a
driver where handling floating point types would be very
helpful.

Thanks,
Mike Russell

You are currently subscribed to ntdev as:
xxxxx@delphieng.com
To unsubscribe send a blank email to
$subst(‘Email.Unsub’)

5

In win2k, they are supported thru’ the use of KeSaveFloatingPointState and
KeRestoreFloatingPointState . They are documented in the DDK.

----- Original Message -----
From: Gary Little
To: NT Developers Interest List
Sent: Thursday, September 07, 2000 1:45 AM
Subject: [ntdev] RE: Float types in NT drivers

> NT 4.0 does not support floating point. I believe it is supported in W2K.
>
> -----Original Message-----
> From: Michael W. Russell [mailto:xxxxx@quatech.com]
> Sent: Wednesday, September 06, 2000 6:34 AM
> To: NT Developers Interest List
> Subject: [ntdev] Float types in NT drivers
>
> On the first NT driver that I wrote I needed to handle some
> floating point
> types and calculations but at the time could not get past
> the fact that I
> got compiler errors whenever I included any of these types
> in the code. At
> the time I remember running into a vague statement in a book
> alluding to the
> fact that floating point types are not valid in kernel mode
> drivers. I am
> wondering is this true and if so is there any way around it.
> Or am I wrong
> and what could I have been doing wrong. Once again I might
> be writing a
> driver where handling floating point types would be very
> helpful.
>
> Thanks,
> Mike Russell
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@delphieng.com
> To unsubscribe send a blank email to
> $subst(‘Email.Unsub’)
>
> —
> You are currently subscribed to ntdev as: xxxxx@cmcltd.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)

6

----- Original Message -----
From: Paul Bunn
To: NT Developers Interest List
Sent: Wednesday, September 06, 2000 8:53 PM
Subject: [ntdev] RE: Float types in NT drivers

> On Win2K
> I believe that the registers are saved as part of UM to KM transition, so
> this is not necessary.
Is this true? But I hope we shld be using the KeSaveFloatingPointState/…
any way isn’t it?

Chaitanya

7

> possible to save these registers yourself on entry to your driver. On
Win2K

I believe that the registers are saved as part of UM to KM transition, so
this is not necessary.

Either the registers are saved or the “FPU state invalid” bit is set in the
CPU’s control register. Accessing FPU with this bit set causes a trap, which
can save the current FPU state and load some saved one.
A useful thing to postpone the FPU state switch during context switches.

Max

8

> the time I remember running into a vague statement in a book alluding to
the

fact that floating point types are not valid in kernel mode drivers. I am

They are valid in w2k.
In NT4 this is very, very hard - nearly impossible. This is due to
implementation of the FPU state switch on context switches on NT4.

Max

9

I don’t think context switches are to blame since this wouldn’t allow any
user mode programs to access the FPU registers (which they obviously can).
I believe that the problem lies with usermode<->kernelmode transitions are
the problem (on NT4).

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Sunday, September 17, 2000 6:36 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Float types in NT drivers

the time I remember running into a vague statement in a book alluding to
the
fact that floating point types are not valid in kernel mode drivers. I am

They are valid in w2k.
In NT4 this is very, very hard - nearly impossible. This is due to
implementation of the FPU state switch on context switches on NT4.

10

> I don’t think context switches are to blame since this wouldn’t allow any

user mode programs to access the FPU registers (which they obviously can).
I believe that the problem lies with usermode<->kernelmode transitions are
the problem (on NT4).

IIRC (I can be wrong):

  • x86 has a CPU status register bit - “FPU context invalid” (don’t remember
    the official Intel’s name just off-head).
  • any opcodes accessing FPU while this bit is set cause a processor trap
    with some predefined vector intended especially for this.
  • this is done to postpone and sometimes bypass the FPU context switch.
    During the context switch, NT sets this status bit and does not do any
    save/restore with the FPU context. When the new thread accesses the FPU (and
    note that not all threads will ever do this) - a trap occurs. The trap
    handler in the kernel saves the old FPU context to the previous thread and
    restores the new one (if any was saved) for the current thread somewhere
    from KTHREAD.
    So, FPU context save/load is postponed till absolutely necessary.
  • now imagine the kmode code accessing the FPU while, say, handling a page
    fault or a hardware interrupt. Surely the FPU context of the user-mode app
    will be junked.
  • saving/restoring FPU state before doing operations in kmode is not enough.
    Imagine - FPU state saved, kmode code touches it, then a context switch
    occurs due to timer interrupt. Surely, this FPU state dirtied by the kmode
    code will be saved further as an FPU state of that thread, and the user-mode
    app’s state will be lost when this thread will be scheduled next.
  • so, raising to DISPATCH_LEVEL and saving the FPU state is possibly the
    only way on NT4 to do FPU work in kmode securely.
  • one more issue - is the “FPU state invalid” trap handler intended to be
    called from kmode? If not (I don’t know exactly) - than even this is not
    secure.

Max