Age | Commit message (Collapse) | Author |
|
|
|
Bhyve returns 0 in MTRRCap register, so we
can use that instead on relying on cpuid only
to see if MTRR's are supported.
That way we can get rid of the sanity check
in memory.c.
|
|
On AMD64, CR0/CR4 are 64-bit registers, with
the upper half reserved. So use uintptr type
to store the register values to get 32 bit on 386
and 64 bit on AMD64.
|
|
|
|
Use the MTRR registers to exclude memory ranges that
do not have the expected cache attributes:
RAM -> writeback
UMB -> uncached
UPA -> uncached
|
|
The new MTRR code handles overlapping ranges
and supports AMD specific TOM2 MSR.
The format in /dev/archctl now only shows
the effective cache ranges only, without
exposing the low level registers.
|
|
The change 3306:c5cf77167bfe made the code reuse MTRR slots
of the default memory type.
But this did not take overlapping ranges into account!
If two or more variable-range MTRRs overlap, the following rules apply:
a. If the memory types are identical, then that memory type is used.
b. If at least one of the memory types is UC, then UC memory type is used.
c. If at least of of the memory types is WT. and the only other memory type
is WB, then th WT memory type is used.
d. If the combination of memory types is not listed above,
then the memory type used in undefined.
It so happend that on a Dell Latitude E7450 that the BIOS defines
the default type as UC. and the first slot defines a 16GB range
of type WB. Then the rest of the ranges mark the PCI space back
as UC, but overlapping the first WB range! This works because
of rule (B) above.
When trying to make the framebuffer write-combining, we would
falsely reuse one of the UC sub-ranges and making the UC memory
into WB as a side effect.
Thanks to Fulton for his patience and providing debug logs and
doing experiments for us to narrow the problem down.
|
|
size msr
|
|
more than 64GB of memory)
|
|
to make it possible to mark the bootscreen framebuffer
as write combining in early initialization, mtrr() is
changed not not to error() but to return an error string.
as bootscreen() is used before multiprocessor initialization,
we have to synchronize the mtrr's for every processor as
it comes online. for this, a new mtrrsync() function is
provided that is called from cpuidentify() if mtrr support
is indicated.
the boot processor runs mtrrsync() which snarfs the
registers. later, mtrrsync() is run again from the
application processors which apply the values from the
boot processor.
checkmtrr() from mp.c was removed as its task is also
done by mtrrsync() now.
|
|
_xinc()/_xdec()
|
|
|
|
|
|
we used to override/reuse mtrr slots over 4GB as the
kernel wasnt able to use that memory. pc64 can.
|
|
|
|
|
|
|