Addition to 07_APIC.md #105
Conversation
02_Architecture/07_APIC.md
Outdated
| * Bits 32:63: reserved. | ||
|
|
||
| Note that the registers are given as a *physical address*, so to access these we will need to map them somewhere in the virtual address space. This is true for the addresses of any I/O APICs we obtain as well. When the system boots, the base address is usually `0xFEE0000` and often this is the value we read from `rdmsr`. | ||
| Note that the registers are given as a *physical address*, so to access these we will need to map them somewhere in the virtual address space. This is true for the addresses of any I/O APICs we obtain as well. When the system boots, the base address is usually `0xFEE0000` and often this is the value we read from `rdmsr`. For correct APIC operation, page with Local APIC registers must be mapped as uncachable. |
There was a problem hiding this comment.
the wording feels a bit clunky, perhaps it could be reflowed as:
For correct operation the local APIC registers should be mapped as 'strong uncachable'.
It may also be worth adding a further sentence to mention how this is setup by the firmware via the MTRRs (at least on the BSP).
Also feel free to add yourself to the list of contributors in 99_Appendices/I_Acknowledgements.md :)
There was a problem hiding this comment.
It may also be worth adding a further sentence to mention how this is setup by the firmware via the MTRRs (at least on the BSP).
The osdev wiki says that changing MTRR can cause problems and PAT should be used. In any case, specifying a method seems unnecessary.
There was a problem hiding this comment.
The osdev wiki says that changing MTRR can cause problems and PAT should be used. In any case, specifying a method seems unnecessary.
Yeah you should use the PAT, what I was saying is that the firmware should set up the MTRRs (which will override the PAT, ensuring you get the correct caching attributes anyway) - although it generally only does this on the BSP. So yes you're not supposed to touch them in theory, but in practice you need to clone the values from the BSP to the APs. Both bios and uefi make no guarantees about the state of the APs after handing over control of the machine. The osdev wiki is convenient but its no authoritative source.
There was a problem hiding this comment.
in any case i'm happy with the PR :)
There was a problem hiding this comment.
@DeanoBurrito, Assuming that PAT is supported, which I believe is true for all modern processors, we can neglect MTRR, in which case to set the memory as UC using PAT it is sufficient to set the PCD and PWT bits to 1 in some paging table entry.
The combination of PAT = 0, PCD = 1, PWT = 1 will select the PAT entry that is responsible for UC.
I think this is a fairly simple method, without having to go into MTRR and change the PAT.
|
@mrjbom i'm happy to merge it, do you want to add yourself in the acknowledgment page here: https://github.com/dreamportdev/Osdev-Notes/blob/master/99_Appendices/I_Acknowledgments.md ? |
3 participants
No description provided.