RE: No right way to share PCI device memory with user mod e?

NTDEV
1

I have to disagree. There are many good reasons to give user mode
applications direct access to the device memory (not hardware in general,
but device memory) and I would be surprised if NT was designed to explicitly
to prevent that.

If, to take a typical example, there is a 64MB read only data buffer on the
device, should all of that data be copied to user mode using IRPs? Note that
the user mode application can’t possible do anything wrong by directly
accessing the device buffer since the buffer is read only.

Another example is prototyping new hardware. From what I’ve seen designers
usually use DOS or Linux to initially test their hardware, since it is
obviously impractical to write a NT kernel mode driver for that purpose.
Yes, in that case the user mode application can easily crash the system, but
still it has to be done.

Anyway, prior to NT 4.0 the graphics drivers ran in user mode and they did
have access to the hardware, so that is a pretty strong indication that such
things are necessary and doable. Too bad that obviously nobody knows how to
do it… I might have to use some of my precious MSDN support :slight_smile:

-tzvetan

----- Original Message -----
From: “Harmon, Larry CT”
To: “NT Developers Interest List”
Sent: Thursday, October 25, 2001 4:08 AM
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?

> tzvetan,
> There is no good way of sharing memory between a driver and a user mode
application. Thats why you haven’t found any direct answers. NT was
designed to isolate the hardware from user tasks, so sharing memory is
contrary to NT’s design.
> NT’s archicture requires a kernel mode driver to pass data between devices
and applications. It isn’t DOS.
>
> Larry

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

There are two things that I don’t understand in your suggestion:

fDx->RdmaMdl = MmCreateMdl(NULL, // Create and Initialize an
MDL
(PVOID)physicalAddress.LowPart,
RDMA_BUFFER_SIZE);

You are passing a physical address to MmCreateMdl? Its parameter must be be
a virtual address.

fDx->RdmaBuffer = MmMapLockedPages(fDx->RdmaMdl, UserMode);

As I already said, MmMapLockedPages() asserts under the checked build of W2K
if the address is outside of the system RAM. So, have you tried this on the
checked build? How do you prevent the assertion failure??

-tzvetan

----- Original Message -----
From: “Gary Little”
To: “NT Developers Interest List”
Sent: Wednesday, October 24, 2001 4:48 PM
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?

> Here is my solution … this is on a common buffer allocated via DMA
> operations.
>
> fDx->RdmaMdl = MmCreateMdl(NULL, // Create and Initialize an
> MDL
> (PVOID)physicalAddress.LowPart,
> RDMA_BUFFER_SIZE);
> MmBuildMdlForNonPagedPool(fDx->RdmaMdl);
> fDx->RdmaBuffer = MmMapLockedPages(fDx->RdmaMdl, UserMode);
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: Tzvetan Mikov [mailto:xxxxx@jupiter.com]
> Sent: Wednesday, October 24, 2001 4:31 PM
> To: NT Developers Interest List
> Subject: [ntdev] No right way to share PCI device memory with user mode?
>
> Hi,
> I’ve already asked this on comp.os.ms-windows.programmer.nt.kernlel-mode
but
> after a total lack of responses I am trying here in a last desperate
> attempt.
>
> My question should be simple: what is supposed to be right way
> of sharing PCI device memory with an user mode application under W2K? I
know
> this has been asked lots of times. My search in Google found dozens
> (if not hundreds!) of posts about this, but unfortunately not even one
> sensible answer. Well, it is possible that I missed that one answer, in
> which case I apologize and will be grateful for a reference to it.
>
> Let me give you the information I have so far. The MSDN gives two possible
> solutions. Unfortunately both of them seem to have problems: one aserts in
> the checked build, the other is rumoured to be too slow.
>
> Solution A (from Q189327 and Q191840):
> ------------------
> Use MmMapIoSpace, IoAllocateMdl, MmBuildMdlForNonPagedPool,
> MmMapLockedPages(UserMode).
>
> This would have been my preferred solution since it also creates a virtual
> address usable outside of the calling process context (the result of
> MmMapIoSpace) and uses calls that are well understood and documented.
> Unfortunately under the checked build of W2K (SP1), MmMapLockedPages
asserts
> with something like “ASSERT( Page > MmHighestPhysicalPage )” when the
> address is in PCI device memory (as opposed to RAM).
> Well, I know that this assertion is not so bad, it can be ignored (or even
> better - patch the kernel at runtime not to generate it at all), but we
use
> W2K checked build for production testing and such behavior is
unacceptable.
>
> Solution B (from Q189327 and the MAPMEM sample from the NT 4.0 DDK):
> ------------------
> Use ZwOpenSection(“\Device\PhysicalMemory”) and ZwMapViewOfSection. This
> code seems a little more scary at first since ZwOpenSection and
> ZwMapViewOfSection are not that well documented. However after a little
> digging in the Platform SDK all parameters can be deciphered.
> The problem here is the reports from several different people claiming
that
> this solution yields very bad performance when accessing the memory from
> user mode.
>
> I personally haven’t still measured the speed difference between Solution
A
> and B and for me currently Solution B is good enough since for my
particular
> application speed is not such of an issue (yet?). However I am surprised
> that something so important and supposedly simple seems to have no
> well-known solution.
>
> -tzvetan
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@broadstor.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@jupiter.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

I think the statement “Note that the user mode application can’t
possible do anything wrong by directly accessing the device buffer since
the buffer is read only.” Is a bit optimistic about the kind of things
that user mode (or kernel) software can do either through stupidity or
intentional misconduct.

Consider a user program that just spins in a loop fetching pci memory
forever. Ok, sure, bump it into real mode so it doesn’t get priority
degraded due to quantum exhaustion. Yes the system probably won’t crash
but it sure will be slow.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
Sent: Thursday, October 25, 2001 4:22 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I have to disagree. There are many good reasons to give user
mode applications direct access to the device memory (not
hardware in general, but device memory) and I would be
surprised if NT was designed to explicitly to prevent that.

If, to take a typical example, there is a 64MB read only data
buffer on the device, should all of that data be copied to
user mode using IRPs? Note that the user mode application
can’t possible do anything wrong by directly accessing the
device buffer since the buffer is read only.

Another example is prototyping new hardware. From what I’ve
seen designers usually use DOS or Linux to initially test
their hardware, since it is obviously impractical to write a
NT kernel mode driver for that purpose. Yes, in that case the
user mode application can easily crash the system, but still
it has to be done.

Anyway, prior to NT 4.0 the graphics drivers ran in user mode
and they did have access to the hardware, so that is a pretty
strong indication that such things are necessary and doable.
Too bad that obviously nobody knows how to do it… I might
have to use some of my precious MSDN support :slight_smile:

-tzvetan

----- Original Message -----
From: “Harmon, Larry CT”
> To: “NT Developers Interest List”
> Sent: Thursday, October 25, 2001 4:08 AM
> Subject: [ntdev] RE: No right way to share PCI device memory
> with user mod e?
>
>
> > tzvetan,
> > There is no good way of sharing memory between a driver and a user
> > mode
> application. Thats why you haven’t found any direct answers.
> NT was designed to isolate the hardware from user tasks, so
> sharing memory is contrary to NT’s design.
> > NT’s archicture requires a kernel mode driver to pass data between
> > devices
> and applications. It isn’t DOS.
> >
> > Larry
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

I think you’re missing something here. If the user just sits there
accessing VIRTUAL USER memory addresses, they will eventually pass a USER
VIRTUAL address that is past what is mapped to the I/O device. When this
happens, they will either fault with an access violation (not a problem in
user mode, just crash the app) or they will step into memory that is mapped
to something else. Neither will cause the system to crash. If they write
to the USER VIRTUAL addresses mapped to the PCI device, nothing will happen
as the device will probably ignore write requests. Again, not a problem.
It’s just like mapping a shared memory region, except instead of RAM, it is
a PCI device.

If this were being done in Kernel mode, the story is completely different.

Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:11 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user
mod e?

I think the statement “Note that the user mode application can’t
possible do anything wrong by directly accessing the device buffer since
the buffer is read only.” Is a bit optimistic about the kind of things
that user mode (or kernel) software can do either through stupidity or
intentional misconduct.

Consider a user program that just spins in a loop fetching pci memory
forever. Ok, sure, bump it into real mode so it doesn’t get priority
degraded due to quantum exhaustion. Yes the system probably won’t crash
but it sure will be slow.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
Sent: Thursday, October 25, 2001 4:22 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I have to disagree. There are many good reasons to give user
mode applications direct access to the device memory (not
hardware in general, but device memory) and I would be
surprised if NT was designed to explicitly to prevent that.

If, to take a typical example, there is a 64MB read only data
buffer on the device, should all of that data be copied to
user mode using IRPs? Note that the user mode application
can’t possible do anything wrong by directly accessing the
device buffer since the buffer is read only.

Another example is prototyping new hardware. From what I’ve
seen designers usually use DOS or Linux to initially test
their hardware, since it is obviously impractical to write a
NT kernel mode driver for that purpose. Yes, in that case the
user mode application can easily crash the system, but still
it has to be done.

Anyway, prior to NT 4.0 the graphics drivers ran in user mode
and they did have access to the hardware, so that is a pretty
strong indication that such things are necessary and doable.
Too bad that obviously nobody knows how to do it… I might
have to use some of my precious MSDN support :slight_smile:

-tzvetan

----- Original Message -----
From: “Harmon, Larry CT”
> To: “NT Developers Interest List”
> Sent: Thursday, October 25, 2001 4:08 AM
> Subject: [ntdev] RE: No right way to share PCI device memory
> with user mod e?
>
>
> > tzvetan,
> > There is no good way of sharing memory between a driver and a user
> > mode
> application. Thats why you haven’t found any direct answers.
> NT was designed to isolate the hardware from user tasks, so
> sharing memory is contrary to NT’s design.
> > NT’s archicture requires a kernel mode driver to pass data between
> > devices
> and applications. It isn’t DOS.
> >
> > Larry
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

5

Not what I meant at all. The user program literally spins on a single
byte or word location in the shared memory region. It (the PCI mapped
region) is not cached. Each read operation results in a PCI bus
transaction. The PCI bus’s performance will be seriously degraded by
this continuous useless polling.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
Sent: Thursday, October 25, 2001 9:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I think you’re missing something here. If the user just sits
there accessing VIRTUAL USER memory addresses, they will
eventually pass a USER VIRTUAL address that is past what is
mapped to the I/O device. When this happens, they will
either fault with an access violation (not a problem in user
mode, just crash the app) or they will step into memory that
is mapped to something else. Neither will cause the system
to crash. If they write to the USER VIRTUAL addresses mapped
to the PCI device, nothing will happen as the device will
probably ignore write requests. Again, not a problem. It’s
just like mapping a shared memory region, except instead of
RAM, it is a PCI device.

If this were being done in Kernel mode, the story is
completely different.

Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:11 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I think the statement “Note that the user mode application
can’t possible do anything wrong by directly accessing the
device buffer since the buffer is read only.” Is a bit
optimistic about the kind of things that user mode (or
kernel) software can do either through stupidity or
intentional misconduct.

Consider a user program that just spins in a loop fetching
pci memory forever. Ok, sure, bump it into real mode so it
doesn’t get priority degraded due to quantum exhaustion. Yes
the system probably won’t crash but it sure will be slow.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
> Sent: Thursday, October 25, 2001 4:22 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: No right way to share PCI device
memory with user
> mod e?
>
>
> I have to disagree. There are many good reasons to give user mode
> applications direct access to the device memory (not hardware in
> general, but device memory) and I would be surprised if NT was
> designed to explicitly to prevent that.
>
> If, to take a typical example, there is a 64MB read only
data buffer
> on the device, should all of that data be copied to user mode using
> IRPs? Note that the user mode application can’t possible do
anything
> wrong by directly accessing the device buffer since the
buffer is read
> only.
>
> Another example is prototyping new hardware. From what I’ve seen
> designers usually use DOS or Linux to initially test their
hardware,
> since it is obviously impractical to write a NT kernel mode
driver for
> that purpose. Yes, in that case the user mode application
can easily
> crash the system, but still it has to be done.
>
> Anyway, prior to NT 4.0 the graphics drivers ran in user
mode and they
> did have access to the hardware, so that is a pretty strong
indication
> that such things are necessary and doable. Too bad that obviously
> nobody knows how to do it… I might have to use some of my
precious
> MSDN support :slight_smile:
>
> -tzvetan
>
>
>
> ----- Original Message -----
> From: “Harmon, Larry CT”
> > To: “NT Developers Interest List”
> > Sent: Thursday, October 25, 2001 4:08 AM
> > Subject: [ntdev] RE: No right way to share PCI device
> memory with user
> > mod e?
> >
> >
> > > tzvetan,
> > > There is no good way of sharing memory between a driver
> and a user
> > > mode
> > application. Thats why you haven’t found any direct
> answers. NT was
> > designed to isolate the hardware from user tasks, so
> sharing memory is
> > contrary to NT’s design.
> > > NT’s archicture requires a kernel mode driver to pass
> data between
> > > devices
> > and applications. It isn’t DOS.
> > >
> > > Larry
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pdq.net
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

6

This is a good point, but not an universally valid one, nonetheless.

If security is such a concern, the device driver which shares the device
memory could have a secure device object, so only certain users can open it.
The user mode application, which is trusted the same way as the driver
itself, has to be installed by an administrator to run in the context of a
specific user. So, in this case from a security viewpoint there is no
difference between the application and the driver, but the application can
enjoy the endless benefits of user mode … :slight_smile:

Anyway, security may or may not be a requirement for a particular project. I
like to think that the OS should provide the necessary tools to go either
way and leave to the implementer to decide which to use.

-tzvetan

----- Original Message -----
From: “Mark Roddy”
To: “NT Developers Interest List”
Sent: Thursday, October 25, 2001 6:47 PM
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?

> Not what I meant at all. The user program literally spins on a single
> byte or word location in the shared memory region. It (the PCI mapped
> region) is not cached. Each read operation results in a PCI bus
> transaction. The PCI bus’s performance will be seriously degraded by
> this continuous useless polling.
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
> > Sent: Thursday, October 25, 2001 9:32 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: No right way to share PCI device memory
> > with user mod e?
> >
> >
> > I think you’re missing something here. If the user just sits
> > there accessing VIRTUAL USER memory addresses, they will
> > eventually pass a USER VIRTUAL address that is past what is
> > mapped to the I/O device. When this happens, they will
> > either fault with an access violation (not a problem in user
> > mode, just crash the app) or they will step into memory that
> > is mapped to something else. Neither will cause the system
> > to crash. If they write to the USER VIRTUAL addresses mapped
> > to the PCI device, nothing will happen as the device will
> > probably ignore write requests. Again, not a problem. It’s
> > just like mapping a shared memory region, except instead of
> > RAM, it is a PCI device.
> >
> > If this were being done in Kernel mode, the story is
> > completely different.
> >
> > Greg
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
> > Sent: Thursday, October 25, 2001 8:11 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: No right way to share PCI device memory
> > with user mod e?
> >
> >
> > I think the statement “Note that the user mode application
> > can’t possible do anything wrong by directly accessing the
> > device buffer since the buffer is read only.” Is a bit
> > optimistic about the kind of things that user mode (or
> > kernel) software can do either through stupidity or
> > intentional misconduct.
> >
> > Consider a user program that just spins in a loop fetching
> > pci memory forever. Ok, sure, bump it into real mode so it
> > doesn’t get priority degraded due to quantum exhaustion. Yes
> > the system probably won’t crash but it sure will be slow.
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
> > > Sent: Thursday, October 25, 2001 4:22 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: No right way to share PCI device
> > memory with user
> > > mod e?
> > >
> > >
> > > I have to disagree. There are many good reasons to give user mode
> > > applications direct access to the device memory (not hardware in
> > > general, but device memory) and I would be surprised if NT was
> > > designed to explicitly to prevent that.
> > >
> > > If, to take a typical example, there is a 64MB read only
> > data buffer
> > > on the device, should all of that data be copied to user mode using
> > > IRPs? Note that the user mode application can’t possible do
> > anything
> > > wrong by directly accessing the device buffer since the
> > buffer is read
> > > only.
> > >
> > > Another example is prototyping new hardware. From what I’ve seen
> > > designers usually use DOS or Linux to initially test their
> > hardware,
> > > since it is obviously impractical to write a NT kernel mode
> > driver for
> > > that purpose. Yes, in that case the user mode application
> > can easily
> > > crash the system, but still it has to be done.
> > >
> > > Anyway, prior to NT 4.0 the graphics drivers ran in user
> > mode and they
> > > did have access to the hardware, so that is a pretty strong
> > indication
> > > that such things are necessary and doable. Too bad that obviously
> > > nobody knows how to do it… I might have to use some of my
> > precious
> > > MSDN support :slight_smile:
> > >
> > > -tzvetan
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: “Harmon, Larry CT”
> > > To: “NT Developers Interest List”
> > > Sent: Thursday, October 25, 2001 4:08 AM
> > > Subject: [ntdev] RE: No right way to share PCI device
> > memory with user
> > > mod e?
> > >
> > >
> > > > tzvetan,
> > > > There is no good way of sharing memory between a driver
> > and a user
> > > > mode
> > > application. Thats why you haven’t found any direct
> > answers. NT was
> > > designed to isolate the hardware from user tasks, so
> > sharing memory is
> > > contrary to NT’s design.
> > > > NT’s archicture requires a kernel mode driver to pass
> > data between
> > > > devices
> > > and applications. It isn’t DOS.
> > > >
> > > > Larry
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@pdq.net
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@jupiter.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

7

Sorry for the misunderstanding. Several of the posts referred to the
user-mode application crashing the system, which cannot happen because of
the reasons I stated. I will grant you that system performance can be
easily degraded by doing just what you suggested. Then again, system
performance can be degraded by a user-mode application doing any number of
things. The first one that comes to mind is elevating priority to an
extremely high level and then executing a compute-bound busy loop.

Greg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:48 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user
mod e?

Not what I meant at all. The user program literally spins on a single
byte or word location in the shared memory region. It (the PCI mapped
region) is not cached. Each read operation results in a PCI bus
transaction. The PCI bus’s performance will be seriously degraded by
this continuous useless polling.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
Sent: Thursday, October 25, 2001 9:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I think you’re missing something here. If the user just sits
there accessing VIRTUAL USER memory addresses, they will
eventually pass a USER VIRTUAL address that is past what is
mapped to the I/O device. When this happens, they will
either fault with an access violation (not a problem in user
mode, just crash the app) or they will step into memory that
is mapped to something else. Neither will cause the system
to crash. If they write to the USER VIRTUAL addresses mapped
to the PCI device, nothing will happen as the device will
probably ignore write requests. Again, not a problem. It’s
just like mapping a shared memory region, except instead of
RAM, it is a PCI device.

If this were being done in Kernel mode, the story is
completely different.

Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:11 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I think the statement “Note that the user mode application
can’t possible do anything wrong by directly accessing the
device buffer since the buffer is read only.” Is a bit
optimistic about the kind of things that user mode (or
kernel) software can do either through stupidity or
intentional misconduct.

Consider a user program that just spins in a loop fetching
pci memory forever. Ok, sure, bump it into real mode so it
doesn’t get priority degraded due to quantum exhaustion. Yes
the system probably won’t crash but it sure will be slow.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
> Sent: Thursday, October 25, 2001 4:22 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: No right way to share PCI device
memory with user
> mod e?
>
>
> I have to disagree. There are many good reasons to give user mode
> applications direct access to the device memory (not hardware in
> general, but device memory) and I would be surprised if NT was
> designed to explicitly to prevent that.
>
> If, to take a typical example, there is a 64MB read only
data buffer
> on the device, should all of that data be copied to user mode using
> IRPs? Note that the user mode application can’t possible do
anything
> wrong by directly accessing the device buffer since the
buffer is read
> only.
>
> Another example is prototyping new hardware. From what I’ve seen
> designers usually use DOS or Linux to initially test their
hardware,
> since it is obviously impractical to write a NT kernel mode
driver for
> that purpose. Yes, in that case the user mode application
can easily
> crash the system, but still it has to be done.
>
> Anyway, prior to NT 4.0 the graphics drivers ran in user
mode and they
> did have access to the hardware, so that is a pretty strong
indication
> that such things are necessary and doable. Too bad that obviously
> nobody knows how to do it… I might have to use some of my
precious
> MSDN support :slight_smile:
>
> -tzvetan
>
>
>
> ----- Original Message -----
> From: “Harmon, Larry CT”
> > To: “NT Developers Interest List”
> > Sent: Thursday, October 25, 2001 4:08 AM
> > Subject: [ntdev] RE: No right way to share PCI device
> memory with user
> > mod e?
> >
> >
> > > tzvetan,
> > > There is no good way of sharing memory between a driver
> and a user
> > > mode
> > application. Thats why you haven’t found any direct
> answers. NT was
> > designed to isolate the hardware from user tasks, so
> sharing memory is
> > contrary to NT’s design.
> > > NT’s archicture requires a kernel mode driver to pass
> data between
> > > devices
> > and applications. It isn’t DOS.
> > >
> > > Larry
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pdq.net
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

8

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:48 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user
mod e?

Not what I meant at all. The user program literally spins on a single
byte or word location in the shared memory region. It (the PCI mapped
region) is not cached. Each read operation results in a PCI bus
transaction. The PCI bus’s performance will be seriously degraded by
this continuous useless polling.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
Sent: Thursday, October 25, 2001 9:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I think you’re missing something here. If the user just sits
there accessing VIRTUAL USER memory addresses, they will
eventually pass a USER VIRTUAL address that is past what is
mapped to the I/O device. When this happens, they will
either fault with an access violation (not a problem in user
mode, just crash the app) or they will step into memory that
is mapped to something else. Neither will cause the system
to crash. If they write to the USER VIRTUAL addresses mapped
to the PCI device, nothing will happen as the device will
probably ignore write requests. Again, not a problem. It’s
just like mapping a shared memory region, except instead of
RAM, it is a PCI device.

If this were being done in Kernel mode, the story is
completely different.

Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, October 25, 2001 8:11 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory
with user mod e?

I think the statement “Note that the user mode application
can’t possible do anything wrong by directly accessing the
device buffer since the buffer is read only.” Is a bit
optimistic about the kind of things that user mode (or
kernel) software can do either through stupidity or
intentional misconduct.

Consider a user program that just spins in a loop fetching
pci memory forever. Ok, sure, bump it into real mode so it
doesn’t get priority degraded due to quantum exhaustion. Yes
the system probably won’t crash but it sure will be slow.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
> Sent: Thursday, October 25, 2001 4:22 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: No right way to share PCI device
memory with user
> mod e?
>
>
> I have to disagree. There are many good reasons to give user mode
> applications direct access to the device memory (not hardware in
> general, but device memory) and I would be surprised if NT was
> designed to explicitly to prevent that.
>
> If, to take a typical example, there is a 64MB read only
data buffer
> on the device, should all of that data be copied to user mode using
> IRPs? Note that the user mode application can’t possible do
anything
> wrong by directly accessing the device buffer since the
buffer is read
> only.
>
> Another example is prototyping new hardware. From what I’ve seen
> designers usually use DOS or Linux to initially test their
hardware,
> since it is obviously impractical to write a NT kernel mode
driver for
> that purpose. Yes, in that case the user mode application
can easily
> crash the system, but still it has to be done.
>
> Anyway, prior to NT 4.0 the graphics drivers ran in user
mode and they
> did have access to the hardware, so that is a pretty strong
indication
> that such things are necessary and doable. Too bad that obviously
> nobody knows how to do it… I might have to use some of my
precious
> MSDN support :slight_smile:
>
> -tzvetan
>
>
>
> ----- Original Message -----
> From: “Harmon, Larry CT”
> > To: “NT Developers Interest List”
> > Sent: Thursday, October 25, 2001 4:08 AM
> > Subject: [ntdev] RE: No right way to share PCI device
> memory with user
> > mod e?
> >
> >
> > > tzvetan,
> > > There is no good way of sharing memory between a driver
> and a user
> > > mode
> > application. Thats why you haven’t found any direct
> answers. NT was
> > designed to isolate the hardware from user tasks, so
> sharing memory is
> > contrary to NT’s design.
> > > NT’s archicture requires a kernel mode driver to pass
> data between
> > > devices
> > and applications. It isn’t DOS.
> > >
> > > Larry
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pdq.net
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>

—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

9

I agree to a point. Unfortunately, C2 security rating prohibits such
options.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Tzvetan Mikov
Sent: Thursday, October 25, 2001 10:04 PM
To: NT Developers Interest List
Subject: [ntdev] RE: No right way to share PCI device memory with user
mod e?

This is a good point, but not an universally valid one, nonetheless.

If security is such a concern, the device driver which shares the device
memory could have a secure device object, so only certain users can open it.
The user mode application, which is trusted the same way as the driver
itself, has to be installed by an administrator to run in the context of a
specific user. So, in this case from a security viewpoint there is no
difference between the application and the driver, but the application can
enjoy the endless benefits of user mode … :slight_smile:

Anyway, security may or may not be a requirement for a particular project. I
like to think that the OS should provide the necessary tools to go either
way and leave to the implementer to decide which to use.

-tzvetan

----- Original Message -----
From: “Mark Roddy”
To: “NT Developers Interest List”
Sent: Thursday, October 25, 2001 6:47 PM
Subject: [ntdev] RE: No right way to share PCI device memory with user mod
e?

> Not what I meant at all. The user program literally spins on a single
> byte or word location in the shared memory region. It (the PCI mapped
> region) is not cached. Each read operation results in a PCI bus
> transaction. The PCI bus’s performance will be seriously degraded by
> this continuous useless polling.
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G. Dyess
> > Sent: Thursday, October 25, 2001 9:32 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: No right way to share PCI device memory
> > with user mod e?
> >
> >
> > I think you’re missing something here. If the user just sits
> > there accessing VIRTUAL USER memory addresses, they will
> > eventually pass a USER VIRTUAL address that is past what is
> > mapped to the I/O device. When this happens, they will
> > either fault with an access violation (not a problem in user
> > mode, just crash the app) or they will step into memory that
> > is mapped to something else. Neither will cause the system
> > to crash. If they write to the USER VIRTUAL addresses mapped
> > to the PCI device, nothing will happen as the device will
> > probably ignore write requests. Again, not a problem. It’s
> > just like mapping a shared memory region, except instead of
> > RAM, it is a PCI device.
> >
> > If this were being done in Kernel mode, the story is
> > completely different.
> >
> > Greg
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
> > Sent: Thursday, October 25, 2001 8:11 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: No right way to share PCI device memory
> > with user mod e?
> >
> >
> > I think the statement “Note that the user mode application
> > can’t possible do anything wrong by directly accessing the
> > device buffer since the buffer is read only.” Is a bit
> > optimistic about the kind of things that user mode (or
> > kernel) software can do either through stupidity or
> > intentional misconduct.
> >
> > Consider a user program that just spins in a loop fetching
> > pci memory forever. Ok, sure, bump it into real mode so it
> > doesn’t get priority degraded due to quantum exhaustion. Yes
> > the system probably won’t crash but it sure will be slow.
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Tzvetan Mikov
> > > Sent: Thursday, October 25, 2001 4:22 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: No right way to share PCI device
> > memory with user
> > > mod e?
> > >
> > >
> > > I have to disagree. There are many good reasons to give user mode
> > > applications direct access to the device memory (not hardware in
> > > general, but device memory) and I would be surprised if NT was
> > > designed to explicitly to prevent that.
> > >
> > > If, to take a typical example, there is a 64MB read only
> > data buffer
> > > on the device, should all of that data be copied to user mode using
> > > IRPs? Note that the user mode application can’t possible do
> > anything
> > > wrong by directly accessing the device buffer since the
> > buffer is read
> > > only.
> > >
> > > Another example is prototyping new hardware. From what I’ve seen
> > > designers usually use DOS or Linux to initially test their
> > hardware,
> > > since it is obviously impractical to write a NT kernel mode
> > driver for
> > > that purpose. Yes, in that case the user mode application
> > can easily
> > > crash the system, but still it has to be done.
> > >
> > > Anyway, prior to NT 4.0 the graphics drivers ran in user
> > mode and they
> > > did have access to the hardware, so that is a pretty strong
> > indication
> > > that such things are necessary and doable. Too bad that obviously
> > > nobody knows how to do it… I might have to use some of my
> > precious
> > > MSDN support :slight_smile:
> > >
> > > -tzvetan
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: “Harmon, Larry CT”
> > > To: “NT Developers Interest List”
> > > Sent: Thursday, October 25, 2001 4:08 AM
> > > Subject: [ntdev] RE: No right way to share PCI device
> > memory with user
> > > mod e?
> > >
> > >
> > > > tzvetan,
> > > > There is no good way of sharing memory between a driver
> > and a user
> > > > mode
> > > application. Thats why you haven’t found any direct
> > answers. NT was
> > > designed to isolate the hardware from user tasks, so
> > sharing memory is
> > > contrary to NT’s design.
> > > > NT’s archicture requires a kernel mode driver to pass
> > data between
> > > > devices
> > > and applications. It isn’t DOS.
> > > >
> > > > Larry
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@pdq.net
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@jupiter.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com