Accessing addresses which have no RAM

[James Harris]

Does anyone here know what would likely happen to cache lines and buses
if one were to read addresses which had no RAM - with or without caching
enabled for those addresses? Ditto writing such addresses? Would the
reads/writes cause problems? What value would be read? All zeroes? All
ones?

And would such operations be slower than accessing real RAM? I guess not
but I don't know. Accessing non-existent RAM is not something one gets
to do too often!

[Rick C. Hodgin]

Post by James Harris
Does anyone here know what would likely happen to cache lines and buses
if one were to read addresses which had no RAM - with or without caching
enabled for those addresses? Ditto writing such addresses? Would the
reads/writes cause problems? What value would be read? All zeroes? All
ones?
And would such operations be slower than accessing real RAM? I guess not
but I don't know. Accessing non-existent RAM is not something one gets
to do too often!

In developing my OS, I used this mechanism to determine how much
memory the machine it's booting on had. I would write a non-zero
value to every 1 MB above the first 1 MB and when I read back a
zero, I know it was beyond the top of memory. I could then iter-
ate backwards to find the maximum byte that has write access with
persistence.

[Edward Brekelbaum]

In ring 3, you'll seg fault.

In ring 0, you should get all ones (IIRC). The transaction goes down the ISA bus and times out.

My knowledge is pretty dated. It's possible chipsets that have dropped support for ISA will behave differently.

Those addresses should resolve to uncacheable, so there will be a pretty hefty performance penalty in any case.

[James Harris]

Post by Edward Brekelbaum
In ring 3, you'll seg fault.

That's if running under an OS, presumably. But I guess it would be
different if running on a bare machine (the case in point) where valid
memory address ranges have not been set up in GDT/LDT or page tables.

Post by Edward Brekelbaum
In ring 0, you should get all ones (IIRC). The transaction goes down the ISA bus and times out.

For some reason I, too, would most expect a read would get all ones
back, but I am not sure why. Perhaps it's based on the idea of a bus
which is carried off a computer by an edge connector. In such a case
IIRC computers used pull-up resistors on bus lines to provide signal
stability. Any line which was to be read as zero had to be driven low.

Post by Edward Brekelbaum
My knowledge is pretty dated. It's possible chipsets that have dropped support for ISA will behave differently.

Agreed. I may be thinking of how old ISA buses were configured. Perhaps
it's even possible that the MCH (term?) would direct different addresses
to different buses such that some addresses which had no RAM or device
at the end of them would return zeroes and others would return ones.

Post by Edward Brekelbaum
Those addresses should resolve to uncacheable, so there will be a pretty hefty performance penalty in any case.

Again, only if ranges have been defined (in MTRRs, in this case). That
said, perhaps MTRRs are set up by the BIOS rather than leaving them to
the operating system.

[Bart]

Post by James Harris

Post by Edward Brekelbaum
In ring 3, you'll seg fault.

That's if running under an OS, presumably. But I guess it would be
different if running on a bare machine (the case in point) where valid
memory address ranges have not been set up in GDT/LDT or page tables.

Post by Edward Brekelbaum
In ring 0, you should get all ones (IIRC). The transaction goes down
the ISA bus and times out.

For some reason I, too, would most expect a read would get all ones
back, but I am not sure why. Perhaps it's based on the idea of a bus
which is carried off a computer by an edge connector. In such a case
IIRC computers used pull-up resistors on bus lines to provide signal
stability. Any line which was to be read as zero had to be driven low.

In the TTL devices I used to use, if nothing was put onto the bus lines,
they would be tri-stated, and generally floated high.

Although that could not be relied upon.

I remember having video memory for a 128x128 x 4-bit display (8KB total)
accessed as 128x128 x 8-bit (16KB range). The top 4 bits of each access
were considered garbage.

In this example, the address was decoded and I could have chosen to pull
those bits up or down. In yours I think the address is not even decoded.

What results to you actually get?

[James Harris]

On 06/04/2019 14:15, Bart wrote:

...

Post by Bart
What results to you actually get?

I haven't tried it yet. And first tests would be in a hosted
environment, thus not real - so don't hold your breath!

[Rod Pemberton]

On Fri, 5 Apr 2019 19:41:13 +0100

Post by James Harris
Does anyone here know what would likely happen to cache lines and
buses if one were to read addresses which had no RAM - with or
without caching enabled for those addresses? Ditto writing such
addresses? Would the reads/writes cause problems? What value would be
read? All zeroes? All ones?
And would such operations be slower than accessing real RAM? I guess
not but I don't know. Accessing non-existent RAM is not something one
gets to do too often!

No, I don't.

I know an older machine returned all ones for when reading the PS/2
port, which it doesn't have.

The same machine has a BIOS that could create a memory hole at 1MB,
which I believe was for a video card (perhaps AGP?).

It also allowed you to copy ROM in RAM for speed. So, writing to the
BIOS address range is probably not a good idea. Maybe, the BIOS region
is protected from writes? I'm really not sure what happens here.

I doubt I have any machines old enough that would have a memory gap
between 640K and 1MB, i.e., assuming memory is probably back-filled
with RAM if no card is installed in the region, or a gap between 512K
and 640K.

Most likely your best best is to pull memory modules or chips to reduce
installed memory in a real machine below the peak address.


Rod Pemberton

[James Harris]

Post by Rod Pemberton
On Fri, 5 Apr 2019 19:41:13 +0100

Post by James Harris
Does anyone here know what would likely happen to cache lines and
buses if one were to read addresses which had no RAM - with or
without caching enabled for those addresses? Ditto writing such
addresses? Would the reads/writes cause problems? What value would be
read? All zeroes? All ones?
And would such operations be slower than accessing real RAM? I guess
not but I don't know. Accessing non-existent RAM is not something one
gets to do too often!

No, I don't.

I've had another thought on that since Robert Wessel pointed out in a
different thread the presence of MTRRs. AIUI on a CPU with MTRRs the
BIOS is likely to have programmed them before it boots an OS.

I would guess, based on that, that addresses which do not have RAM
behind them would be mapped as uncacheable. That won't affect the value
which would be read from such unconnected addresses but it would mean
that reading or writing a load of them would be unlikely to overfill and
thus flush the caches.

Post by Rod Pemberton
I know an older machine returned all ones for when reading the PS/2
port, which it doesn't have.

Me too. A good example is the Abit machine which you and I documented
before at

http://aodfaq.wikidot.com/mc-scpa

Incidentally, looking at those pages again it occurs to me that since
some port accesses may be trapped by SMM code, the results they return
will depend on code - possibly buggy code - rather than hardware. I
think we may have seen that in KBC tests we ran on some machines.

Another, related thought. We might be able to tell whether accesses to a
certain port trapped to SMM or not by timing them. Normally, all such
accesses are so fast we would never be able to tell whether they were
implemented by code or hardware unless we checked a high-resolution
timer like the TSC.

Post by Rod Pemberton
The same machine has a BIOS that could create a memory hole at 1MB,
which I believe was for a video card (perhaps AGP?).
It also allowed you to copy ROM in RAM for speed. So, writing to the
BIOS address range is probably not a good idea. Maybe, the BIOS region
is protected from writes? I'm really not sure what happens here.
I doubt I have any machines old enough that would have a memory gap
between 640K and 1MB, i.e., assuming memory is probably back-filled
with RAM if no card is installed in the region, or a gap between 512K
and 640K.
Most likely your best best is to pull memory modules or chips to reduce
installed memory in a real machine below the peak address.

True, though that would provide data for only one machine. It would also
give data for only the limited addresses used in a test. It is possible,
for example, that there would be different zeroes-or-ones results from

* Addresses the MCH knows are not mapped to anything
* Addresses which are mapped to a 'local' bus
* Addresses which are mapped to graphics cards
* Addresses which end up on an ISA bus

[Rod Pemberton]

On Mon, 8 Apr 2019 13:10:01 +0100

Post by James Harris
I've had another thought on that since Robert Wessel pointed out in a
different thread the presence of MTRRs. AIUI on a CPU with MTRRs the
BIOS is likely to have programmed them before it boots an OS.

I'm not familiar with the MTRRs.

Post by James Harris
I would guess, based on that, that addresses which do not have RAM
behind them would be mapped as uncacheable.

FYI, "addresses which do not have RAM behind them" could mean something
other than nothing present, e.g., ROM, memory-mapped device, or I/O
port. Although, you mentioned "unconnected" (snipped).

What is the purpose of mapping nothing present address regions as
uncacheable? ...

Is there any reason to not cache garbage data? Anything not cached,
including garbage data, will slow down the processor, correct?

I.e., I would expect an uncacheable memory region to be a region which
is likely to have data that could be changed by something external to
the processor, e.g., a port or memory-mapped device. For C, this would
be an object marked with the "volatile" keyword to ensure reads and
writes aren't optimized away.

Post by James Harris
Incidentally, looking at those pages again it occurs to me that since
some port accesses may be trapped by SMM code, the results they
return will depend on code - possibly buggy code - rather than
hardware. I think we may have seen that in KBC tests we ran on some
machines.
Another, related thought. We might be able to tell whether accesses
to a certain port trapped to SMM or not by timing them. Normally, all
such accesses are so fast we would never be able to tell whether they
were implemented by code or hardware unless we checked a
high-resolution timer like the TSC.

I'll discuss SMM, but SMM is something I wish to not get involved with.
SMM could implement unknowable interactions or changes to hardware or
software. I have no control over SMM anyway, if something is wrong or
takes too long. SMM seems like a backdoor attack vector ... Etc.


Rod Pemberton

[James Harris]

Post by Rod Pemberton
On Mon, 8 Apr 2019 13:10:01 +0100

Post by James Harris
I've had another thought on that since Robert Wessel pointed out in a
different thread the presence of MTRRs. AIUI on a CPU with MTRRs the
BIOS is likely to have programmed them before it boots an OS.

I'm not familiar with the MTRRs.

A good reference is the Pentium Pro OS Writer's Guide as the PPro was
one of the earliest (and, therefore simplest and most portable)
implementations. See Chapter 11 of

https://www.fermimn.edu.it/inform/materiali/evarchi/intel/242692_1.pdf

Post by Rod Pemberton

Post by James Harris
I would guess, based on that, that addresses which do not have RAM
behind them would be mapped as uncacheable.

FYI, "addresses which do not have RAM behind them" could mean something
other than nothing present, e.g., ROM, memory-mapped device, or I/O
port. Although, you mentioned "unconnected" (snipped).

See 11.3.

Uncacheable (UC)—System memory locations are not cached. All reads and
writes appear on the system bus and are executed in program order,
without reordering. No speculative memory accesses, page table walks, or
prefetches of speculated branch targets are made. This type of
cache-control is useful for memory-mapped I/O devices.

Write protected (WP)—Reads come from cache lines when possible, and read
misses cause cache fills. Writes are propagated to the system bus and
cause corresponding cache lines on all processors on the bus to be
invalidated.

Post by Rod Pemberton
What is the purpose of mapping nothing present address regions as
uncacheable? ...

Why map them as cacheable?

Post by Rod Pemberton
Is there any reason to not cache garbage data? Anything not cached,
including garbage data, will slow down the processor, correct?

It will likely never be read (or written). Accesses to it would normally
be errors.

Post by Rod Pemberton
I.e., I would expect an uncacheable memory region to be a region which
is likely to have data that could be changed by something external to
the processor, e.g., a port or memory-mapped device. For C, this would
be an object marked with the "volatile" keyword to ensure reads and
writes aren't optimized away.

Post by James Harris
Incidentally, looking at those pages again it occurs to me that since
some port accesses may be trapped by SMM code, the results they
return will depend on code - possibly buggy code - rather than
hardware. I think we may have seen that in KBC tests we ran on some
machines.
Another, related thought. We might be able to tell whether accesses
to a certain port trapped to SMM or not by timing them. Normally, all
such accesses are so fast we would never be able to tell whether they
were implemented by code or hardware unless we checked a
high-resolution timer like the TSC.

I'll discuss SMM, but SMM is something I wish to not get involved with.
SMM could implement unknowable interactions or changes to hardware or
software. I have no control over SMM anyway, if something is wrong or
takes too long. SMM seems like a backdoor attack vector ... Etc.

SMM is a pain for us. It's there. We cannot disable it.

[Rod Pemberton]

On Thu, 11 Apr 2019 09:39:04 +0100

Post by James Harris

Post by Rod Pemberton
On Mon, 8 Apr 2019 13:10:01 +0100
What is the purpose of mapping nothing present address regions as
uncacheable? ...

Why map them as cacheable?

(in questions directly below)

Post by James Harris

Post by Rod Pemberton
Is there any reason to not cache garbage data? Anything not cached,
including garbage data, will slow down the processor, correct?

It will likely never be read (or written). Accesses to it would
normally be errors.

You started this thread asking how to "access addresses which have no
RAM". If you're accessing many such addresses sequentially, and you
don't know whether the region is or isn't garbage, why would you want
to access them slowly because they're not cached? You could.


Rod Pemberton
P.S. days behind on c.l.m. replies ...

[James Harris]

Post by Rod Pemberton
On Thu, 11 Apr 2019 09:39:04 +0100

Post by James Harris

Post by Rod Pemberton
On Mon, 8 Apr 2019 13:10:01 +0100
What is the purpose of mapping nothing present address regions as
uncacheable? ...

Why map them as cacheable?

(in questions directly below)

Post by James Harris

Post by Rod Pemberton
Is there any reason to not cache garbage data? Anything not cached,
including garbage data, will slow down the processor, correct?

It will likely never be read (or written). Accesses to it would
normally be errors.

You started this thread asking how to "access addresses which have no
RAM". If you're accessing many such addresses sequentially, and you
don't know whether the region is or isn't garbage, why would you want
to access them slowly because they're not cached? You could.

Not exactly. In the original post I asked

JH> Does anyone here know what would likely happen to cache
JH> lines and buses if one were to read addresses which had
JH> no RAM - with or without caching enabled for those
JH> addresses?

I take your point, though, that it should not matter whether addresses
which are never accessed are cacheable or not.