rust-osdev
Added MTRRs and other missing registers
Added new registers:
- mtrrcap
- mtrrdeftype
- mtrrfix64k00000
- mtrrfix16k80000
- mtrrfix16ka0000
- mtrrfix4kc0000
- mtrrfix4kc8000
- mtrrfix4kd0000
- mtrrfix4kd8000
- mtrrfix4ke0000
- mtrrfix4ke8000
- mtrrfix4kf8000
- mtrrphysmask0
- mtrrphysmask1
- mtrrphysmask2
- mtrrphysmask3
- mtrrphysmask4
- mtrrphysmask5
- mtrrphysmask6
- mtrrphysmask7
- mtrrphysbase0
- mtrrphysbase1
- mtrrphysbase2
- mtrrphysbase3
- mtrrphysbase4
- mtrrphysbase5
- mtrrphysbase6
- mtrrphysbase7
- cstar
- syscfg
- ldtr
- cr8
Whats missing?
Implementing the #[cfg(not(feature = "inline_asm"))] handles.
A write() function for mtrrfix4ke0000 and the like
Thanks a lot for the PR! I did not have time to review the MTRR code (it's a lot), but I left some comments on the other changes.
I don't know when I'll have time for a more detailed review, but I would be fine with merging this behind a feature gate. In #266 (review) I proposed a cargo feature named
experimentalfor this, to indicate new code that hasn't been tested much yet. What do you think about this approach?
Yeah sounds like a good idea! Right now I'm a bit busy so I will implement the fixups you mentioned in one or two weeks
Out of curiosity, is there a reason that you're using MTTRs instead of the PAT? This seems like a lot of code for something that has already been superseded.
Out of curiosity, is there a reason that you're using MTTRs instead of the PAT? This seems like a lot of code for something that has already been superseded.
Thanks for the throughout review! The problem is that MTTRs are still relevant in x64 and active and can override PAT. Which means it's very important to know how they are configured by default to guard against very hard to pin down bugs. An example: My AMD Bulldozer FX-8600 for example has the default mtrr memory type of uncached. Which means every memory region that is not covered by variable length mtrrs is set to uncached even if the PAT says something different.
The problem is that MTTRs are still relevant in x64 and active and can override PAT. Which means it's very important to know how they are configured by default to guard against very hard to pin down bugs.
Very interesting! How can this cause bugs? AFAICT the MTRRs can only overwrite the PAT in that they can disable caching that would have been allowed by the PAT. Is this not true or am I missing something else?
The problem is that MTTRs are still relevant in x64 and active and can override PAT. Which means it's very important to know how they are configured by default to guard against very hard to pin down bugs.
Very interesting! How can this cause bugs? AFAICT the MTRRs can only overwrite the PAT in that they can disable caching that would have been allowed by the PAT. Is this not true or am I missing something else?
Not only no, here is a table which illustrates what side effects can be caused (it's from the AMD manual vol 2 page 263):
Not only no, here is a table which illustrates what side effects can be caused (it's from the AMD manual vol 2 page 263):
Which one's of these show that the MTRR's can allow caching that isn't allowed by the PAT? The only one I see is the when the PAT is set to UC- and the MTRR is set to WC, but given that that is the sole purpose of UC- I don't think that counts.
I think I found another case where the MTRR's can allow more caching:
A MTRR can change the effective memory type from write-through to write-combine, this matters because write-combine can do out-of-order writes which aren't allowed by write-through.
@Freax13 Ah very nice! I must admit I didn't look too closely into the table because I just assumed that a different effective caching behavior then what the developer thought would be there can lead to bugs, know I know for real ^^
If someone wants to open up a new reworked pull request go ahead :-) I sadly won't be able to work on this for at least a couple of months sadly (maybe @Freax13 ?)