Adding a single `wbinvd' instruction at the right place is a simple
instruction that would actually work *according to the official docs* :-)
> If you were to read/write every byte/word/whatever in
> memory sequentially, it would not work. Only the cache data would be
> modified and you would subsequentally read from the cache. Just try
> it.
That's right. You've noticed that the cache _usually_ gets very
involved in sequential accesses, and _usually_ keeps out of the way in
isolated page-striding accesses. However it is not guaranteed to do so,
may not do so on some motherboards (L2 cache policy), and most
importantly: I believe it does not do so with the latest x86 CPUs.
However, `wbinvd' is specified to work.
> Another thing to consider is that offsets in ix86-land are signed!
> Using [EBX] will address 4GB, but [buffer + EBX] will not. If EBX =
> 0xffffffff, (-1) it points to 1 byte below 'buffer'. This is something
> to remember if you are trying to write 'cute' code. This is also something
> to remember if you are relying on 'C' to compute the address. I strongly
> suggest you find the RAM in assembly, not 'C'.
Where you expecting buffer+0xffffffff to point to some mysterious
address in an alternate universe or something?
This case has nothing to do with signedness, and everything to do with
the address being restricted to 32 bits before going through the segment
and page mappings. 'C' handles this just fine.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/