VirtuaAllocCopyEx not mapping as UnCached

Hi,

I am running windows ce 6.0 on an ARM11 target with an armv4 compiler.
I have the following scenario. I have a structure named queue and I am
allocating it on kernel side and trying to map it to user side using
VirtualAllocCopyEx.

On a nutshell this is what I am doing inside Map().

queueAddrUM =
VirtualAllocCopyEx(GetCurrentProcess(),(HANDLE)ui32ProcessID,queueAddrKM,ui32Size, PAGE_READWRITE | PAGE_NOCACHE);

Which means that in queueAddrUM I have the base address for the allocated
queue whose kernel address is queueAddrKM).

Now I try to update a member of the queue by doing:

queueAddrUM->info = some->info and at random times queueAddrUM->info does
not get updated instead it keeps the previous values, i.e the value of
queueAddrKM->info. It's as though the assignment statement did not exist or
it wasn't really mapped(Note: sometimes it works).

Any ideas what might be wrong here?

P.S queueAddrUM is of type queue and VirtualAllocCopyEx is being called from
kernel mode. Please do not be confused by the simplicity of my example, I
just tried to keep the problem simple, the types are correct and function
calls seem to be placed in context.

Thank you very much for the help.

Silver
Mon Jul 07 09:38:10 PDT 2008

The pointer 'queueAddrUM' is uncached. It will be committed to RAM, possible
through a write combiner of some sort, immediately.

However, is 'queueAddrKM' uncached? (no it is cached would be my guess). If
your SOC does not support snooping (some SOCs will snoop DMA activity and
invalidate the cache automatically) then you must invalidate the cache entry
for 'queueAddrKM' before using it.

Consider using memory mapped file to take care of all of that for you.

Geoff
--

kibkid
Mon Jul 07 10:14:01 PDT 2008


Hi Thank you for your reply,

I am very new to Windows CE so pardon my ignorance, but what do you mean
when you say consider using memory mapped files as it refers to my case.

Could you be please provide a simple example? I would very much appreciate
this as this problem is occurring in a driver which I must fix.
Thank you very much.

kibkid
Mon Jul 07 10:18:03 PDT 2008


Also, do you agree that this is a caching problem or do you think it could
be anything else?

Silver
Mon Jul 07 10:44:33 PDT 2008

Sounds like caching - although the optimizer could be doing something if you
have not used 'volatile', I would need to see a lot more code to make that
judgement although caching sound likely if your kernel pointer is cached.

Memory mapped files - do not be afraid to search the web or MSDN for "memory
mapped files on windows ce" or something like that.
Try looking on codeproject.com for an example.

I am not sure what you are trying to accomplish, although sharing a buffer
between kernel mode and user mode seems to be it. There are functions for
this - CeAllocAsynchronousBuffer.

Geoff
--

kibkid
Mon Jul 07 11:25:04 PDT 2008


I understand that you would need to see more code, apologies. However I am
not able to post the code as you might understand.

But you are right I am trying to share a buffer (or a queue) between the
kernel and the user. Like I said I am trying to fix a driver which is failing
due to this issue and using CeAllocAsynchronousBuffer I think would require
me to change a large amount of the driver.

I am trying to get the simplest solution possible. You mentioned that the
optimizer could be a problem if I haven't used volatile. If I haven't used
volatile where, in the declaration of the buffer?

You also mentioned that I could invalidate the cache right after the kernel
address is gotten. Can you please direct me to a function that does this?

Thank you very much I very much appreciate it

Bruce
Mon Jul 07 12:15:48 PDT 2008

volatile tells an optimizing compiler not to optimize out code that from the
surface appears to do nothing.

int *X = some address;

*X = 1;

while( *X != 0 );

will look to the compiler like the while loop is really a while( 1 ), but
since some address could change under the control of a different thread or
hardware, this code should not be optimized out.

Alternatively:

while( *X == 0 )

would not include code becuase it would be removed by the compiler.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"kibkid" <kibkid@discussions.microsoft.com> wrote in message
news:C4FAFEDD-1EED-4A08-A4D4-AD0D8CCFD872@microsoft.com...
>
> I understand that you would need to see more code, apologies. However I am
> not able to post the code as you might understand.
>
> But you are right I am trying to share a buffer (or a queue) between the
> kernel and the user. Like I said I am trying to fix a driver which is
> failing
> due to this issue and using CeAllocAsynchronousBuffer I think would
> require
> me to change a large amount of the driver.
>
> I am trying to get the simplest solution possible. You mentioned that the
> optimizer could be a problem if I haven't used volatile. If I haven't used
> volatile where, in the declaration of the buffer?
>
> You also mentioned that I could invalidate the cache right after the
> kernel
> address is gotten. Can you please direct me to a function that does this?
>
> Thank you very much I very much appreciate it

Silver
Mon Jul 07 13:05:41 PDT 2008


Bruce answered the volatile Question.

You could try searching the PB documentation for the word 'cache'. You will
find OEMCacheRangeFlush. You will need to call this from kernel mode.

If I were you I'd fix the real problem with CeAllocAsynchronousBuffer and
port the driver kicking and screaming into CE6.0. I doubt that it would be
very intrusive to do so.

Geoff
--

kibkid
Mon Jul 07 13:38:01 PDT 2008



Ok, I will try to do that.


One question though for my general understanding, how could the Kernel
address be cached if i am using an armv4 .

I quote from PB:

"
VirtualAllocCopyEx: In CE 6.0, if a kernel mode driver creates an explicit
alias in which two virtual addresses map to the same physical address by
using VirtualAllocCopyEx, the OS marks both the source and destination
addresses as uncached to avoid cache aliasing on ARMv4 and ARMv5 systems. On
ARMv6 and ARMv7 systems, source and destination addresses are marked as
cached. Even though this function can be called only from kernel mode, this
affects both kernel-mode and user-mode drivers. Device Manager copies the
data only for user-mode drivers.
"
Any ideas on that, I am very confused?

Thank you both for your explanations thus far.

Silver
Mon Jul 07 15:25:33 PDT 2008

ARM11 has an ARMv6 core. I get that you are targetting ARMv4I ISA but the
kernel knows about the CPU core ISA too.
http://www.arm.com/products/CPUs/families/ARM11Family.html
Note that my docs do not have that statement in them so I guess you are
using CE6R2 which I do not currently have installed.

The kernel provides the functionality you want with the
CeAllocAsynchronousBuffer, you should use it.

Alternatively, call VirtualAlloc / VirtualCopy yourself.

Geoff
--

kibkid
Tue Jul 08 06:58:04 PDT 2008


Thank you so much for the help. I am really enjoying the work on wince I
just don't have the expertise and I find myself a bit lost at times.

About that statement I quoted I actually got it off the msdn site. I am
reading on CeAllocAsynchronousBuffer.

Once again thank you

Silver
Tue Jul 08 10:41:50 PDT 2008

It may be worth your while to attend a training course, or get a DVD
training course. Hassle your employer to pay for it.

kibkid
Wed Sep 03 12:37:01 PDT 2008


I have finally resolved the whole driver issue, this particular problem was
resolved by simply specifying PAGE_NOCACHE where I allocate the main buffer