Question about HAL

NTDEV
1

Hello,

We are struggling with some simple questions about the HAL… We have memory areas which we map into user-mode space and expect the user-mode app to be able to poke/peek the memory areas. Two big questions we have are:

  1. What about HAL functions READ_REGISTER_XXX/WRITE_REGISTER_XXX? They are not accessable up in the user-mode. I have supplied some ioctls in my driver for peek/poke which effectively use the HAL for these but this is not good in the big picture because the app will be banging hundreds of registers and to have to route them all through an ioctl will be expensive. I believe that the HAL functions READ/WRITE_REGISTER_XXX resolve to a simple assignment {And checking ntddk.h seems to indicate that, except for an #ifdef section}. Do we really have to use the HAL functions?

  2. What about caching… When the user-mode program has poked some registers, are those registers really written to the hardware or are they cached? I believe they are written directly to the hardware, but some engineers here are worried that this is not the case. If the PCI memory is cached, how can a user-mode app flush the cache?

Thank you,
Michael Uman
Sr. Software Engineer
Sonic Solutions

2

-----Original Message-----
From: Michael Uman [mailto:xxxxx@sonic.com]
Sent: Wednesday, October 11, 2000 2:00 PM
To: NT Developers Interest List
Subject: [ntdev] Question about HAL

Hello,

We are struggling with some simple questions about the HAL… We have memory
areas which we map into user-mode space and expect the user-mode app to be
able to poke/peek the memory areas. Two big questions we have are:

  1. What about HAL functions READ_REGISTER_XXX/WRITE_REGISTER_XXX? They are
    not accessable up in the user-mode. I have supplied some ioctls in my driver
    for peek/poke which effectively use the HAL for these but this is not good
    in the big picture because the app will be banging hundreds of registers and
    to have to route them all through an ioctl will be expensive. I believe that
    the HAL functions READ/WRITE_REGISTER_XXX resolve to a simple assignment
    {And checking ntddk.h seems to indicate that, except for an #ifdef section}.
    Do we really have to use the HAL functions?
    [Gary Little]

Simple answer: Yes you really have to use HAL, which means you really need a
kernel driver.

Hopefully you will get a reply from, Mark, Jamie, or Walter, or another that
knows a bit more about this than I do. first, HAL functions a simply
function calls into HAL.DLL, and you aren’t going to get access to that from
user space. Well, I guess you could byte the bullet and LINK with HAL.LIB,
for all the good it would do you since any call would be completely out of
context.

From other discussions I have seen both here and in the news groups, the HAL
function calls handle issues of caching that are not handled when the user
accesses memory. I would theorize that even if you called one from user mode
it would fail since user modes does not have the proper IO privilege to
access the instructions required. That is one reason why there is Kernel
mode, and the HAL.

Now if I’m wrong, hopefully, it will irritate Walter, Mark, or Jamie enough
to slap me down and answer your question properly. :slight_smile:

  1. What about caching… When the user-mode program has poked some
    registers, are those registers really written to the hardware or are they
    cached? I believe they are written directly to the hardware, but some
    engineers here are worried that this is not the case. If the PCI memory is
    cached, how can a user-mode app flush the cache?
    [Gary Little]
    Well, there is KeflushAdapterBuffer and related calls in Kernel mode, but
    remember you’re trying to “cheat” the kernel and do this in user mode. I
    think the bottom line here is that you have a work around that is
    functional, but you REALLY need to bite the bullet and do this in the
    kernel. Really, the Kernel ISN’T the beast every one makes it out to be.

Thank you,
Michael Uman
Sr. Software Engineer
Sonic Solutions

3

On the current x86 platform HAL, each of the hal write register operations
finish the transfer by executing a locked operation (an OR of the target
address if I recall correctly.) This flushes the P5 or later ‘write post
buffer’ and thus guarantees that the data is actually written to the target.
Without this flushing, there is no such guarantee, regardless of the
cached/non-cached state of the virtual addresses. The ‘write post buffer’ is
in front of the memory cache system. It has its own rules.

If you insist on mapping device memory to user space, and I personally think
that it is not a good idea, then you also need to emulate the hal write
register operations. Reads do not happen to be a problem today with the
current x86 P-whatever-it-is-these-days architecture. But tomorrow? The
point being that you have lost all hope of platform
independence/portability.

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary Little
Sent: Wednesday, October 11, 2000 5:28 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Question about HAL

-----Original Message-----
From: Michael Uman [mailto:xxxxx@sonic.com]
Sent: Wednesday, October 11, 2000 2:00 PM
To: NT Developers Interest List
Subject: [ntdev] Question about HAL

Hello,

We are struggling with some simple questions about the HAL… We
have memory
areas which we map into user-mode space and expect the user-mode app to be
able to poke/peek the memory areas. Two big questions we have are:

  1. What about HAL functions READ_REGISTER_XXX/WRITE_REGISTER_XXX? They are
    not accessable up in the user-mode. I have supplied some ioctls
    in my driver
    for peek/poke which effectively use the HAL for these but this is not good
    in the big picture because the app will be banging hundreds of
    registers and
    to have to route them all through an ioctl will be expensive. I
    believe that
    the HAL functions READ/WRITE_REGISTER_XXX resolve to a simple assignment
    {And checking ntddk.h seems to indicate that, except for an
    #ifdef section}.
    Do we really have to use the HAL functions?
    [Gary Little]

Simple answer: Yes you really have to use HAL, which means you
really need a
kernel driver.

Hopefully you will get a reply from, Mark, Jamie, or Walter, or
another that
knows a bit more about this than I do. first, HAL functions a simply
function calls into HAL.DLL, and you aren’t going to get access
to that from
user space. Well, I guess you could byte the bullet and LINK with HAL.LIB,
for all the good it would do you since any call would be completely out of
context.

>From other discussions I have seen both here and in the news
groups, the HAL
function calls handle issues of caching that are not handled when the user
accesses memory. I would theorize that even if you called one
from user mode
it would fail since user modes does not have the proper IO privilege to
access the instructions required. That is one reason why there is Kernel
mode, and the HAL.

Now if I’m wrong, hopefully, it will irritate Walter, Mark, or
Jamie enough
to slap me down and answer your question properly. :slight_smile:

  1. What about caching… When the user-mode program has poked some
    registers, are those registers really written to the hardware or are they
    cached? I believe they are written directly to the hardware, but some
    engineers here are worried that this is not the case. If the PCI memory is
    cached, how can a user-mode app flush the cache?
    [Gary Little]
    Well, there is KeflushAdapterBuffer and related calls in Kernel mode, but
    remember you’re trying to “cheat” the kernel and do this in user mode. I
    think the bottom line here is that you have a work around that is
    functional, but you REALLY need to bite the bullet and do this in the
    kernel. Really, the Kernel ISN’T the beast every one makes it out to be.

Thank you,
Michael Uman
Sr. Software Engineer
Sonic Solutions

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

4

all the write/read register functions are implemented in the kernel, not the
hal. as ya’ll know, the hal changes with various x86 configurations. the
kernel does not (except for # of cpus, pae extentions, of course).

some of us who are optimistic might assume it’s a fairly safe risk to assume
that since a machine with N processors will always be able to use the same
kernel as any other x86 machine with N processors, regardless of whether
both machines are vanilla x86’s or if one of them is some kinda funky beast,
chances are that the write_register* implementations aren’t likely to change
any time soon simply by virtue of the binary that they reside in. & only
register writes require a flush after a memory transfer. so even tho u
probably shouldn’t go around the *register* functions, if u “have to”
because of time constraints or performance reasons, u’re probably not
sticking your neck out very far.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Wednesday, October 11, 2000 9:53 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Question about HAL

On the current x86 platform HAL, each of the hal write register operations
finish the transfer by executing a locked operation (an OR of the target
address if I recall correctly.) This flushes the P5 or later ‘write post
buffer’ and thus guarantees that the data is actually written to the target.
Without this flushing, there is no such guarantee, regardless of the
cached/non-cached state of the virtual addresses. The ‘write post buffer’ is
in front of the memory cache system. It has its own rules.

If you insist on mapping device memory to user space, and I personally think
that it is not a good idea, then you also need to emulate the hal write
register operations. Reads do not happen to be a problem today with the
current x86 P-whatever-it-is-these-days architecture. But tomorrow? The
point being that you have lost all hope of platform
independence/portability.

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary Little
Sent: Wednesday, October 11, 2000 5:28 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Question about HAL

-----Original Message-----
From: Michael Uman [mailto:xxxxx@sonic.com]
Sent: Wednesday, October 11, 2000 2:00 PM
To: NT Developers Interest List
Subject: [ntdev] Question about HAL

Hello,

We are struggling with some simple questions about the HAL… We
have memory
areas which we map into user-mode space and expect the user-mode app to be
able to poke/peek the memory areas. Two big questions we have are:

  1. What about HAL functions READ_REGISTER_XXX/WRITE_REGISTER_XXX? They are
    not accessable up in the user-mode. I have supplied some ioctls
    in my driver
    for peek/poke which effectively use the HAL for these but this is not good
    in the big picture because the app will be banging hundreds of
    registers and
    to have to route them all through an ioctl will be expensive. I
    believe that
    the HAL functions READ/WRITE_REGISTER_XXX resolve to a simple assignment
    {And checking ntddk.h seems to indicate that, except for an
    #ifdef section}.
    Do we really have to use the HAL functions?
    [Gary Little]

Simple answer: Yes you really have to use HAL, which means you
really need a
kernel driver.

Hopefully you will get a reply from, Mark, Jamie, or Walter, or
another that
knows a bit more about this than I do. first, HAL functions a simply
function calls into HAL.DLL, and you aren’t going to get access
to that from
user space. Well, I guess you could byte the bullet and LINK with HAL.LIB,
for all the good it would do you since any call would be completely out of
context.

>From other discussions I have seen both here and in the news
groups, the HAL
function calls handle issues of caching that are not handled when the user
accesses memory. I would theorize that even if you called one
from user mode
it would fail since user modes does not have the proper IO privilege to
access the instructions required. That is one reason why there is Kernel
mode, and the HAL.

Now if I’m wrong, hopefully, it will irritate Walter, Mark, or
Jamie enough
to slap me down and answer your question properly. :slight_smile:

  1. What about caching… When the user-mode program has poked some
    registers, are those registers really written to the hardware or are they
    cached? I believe they are written directly to the hardware, but some
    engineers here are worried that this is not the case. If the PCI memory is
    cached, how can a user-mode app flush the cache?
    [Gary Little]
    Well, there is KeflushAdapterBuffer and related calls in Kernel mode, but
    remember you’re trying to “cheat” the kernel and do this in user mode. I
    think the bottom line here is that you have a work around that is
    functional, but you REALLY need to bite the bullet and do this in the
    kernel. Really, the Kernel ISN’T the beast every one makes it out to be.

Thank you,
Michael Uman
Sr. Software Engineer
Sonic Solutions

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

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