Messages in this thread | | | From | Andrew Cooper <> | Subject | Re: [PATCH v2 08/39] x86/mm: Remove _PAGE_DIRTY from kernel RO pages | Date | Wed, 5 Oct 2022 12:34:07 +0000 |
| |
On 05/10/2022 12:16, Peter Zijlstra wrote: > On Wed, Oct 05, 2022 at 01:31:28AM +0000, Andrew Cooper wrote: >> On 29/09/2022 23:29, Rick Edgecombe wrote: >>> From: Yu-cheng Yu <yu-cheng.yu@intel.com> >>> >>> Processors sometimes directly create Write=0,Dirty=1 PTEs. >> Do they? (Rhetorical) >> >> Yes, this is a relevant anecdote for why CET isn't available on pre-TGL >> parts, but it one of the more wrong things to have as the first sentence >> of this commit message. >> >> The point you want to express is that under the CET-SS spec, R/O+Dirty >> has a new meaning as type=shstk, so stop using this bit combination for >> existing mappings. >> >> I'm not even sure it's relevant to note that CET capable processors can >> set D on a R/O mapping, because that depends on !CR0.WP which in turn >> prohibits CR4.CET being enabled. > Whilst I agree that the Changelog is 'suboptimal' -- I do think it might > be good to mention how we ended up at the current state where we > explicitly set this non-sensical W=0,D=1 state.
Sure, but that's got nothing to do with hardware errata.
Having hardware set A/D bits is expensive. Being a locked operation, it's roughly a smp_mb() behind the scenes.
Therefore, when A/D tracking doesn't matter, traditional wisdom says set both of them when creating the PTE.
It's only now that R/O+Dirty has a meaning (other than being a slightly weird but safe bit combination), and we've got to be more careful about using it.
~Andrew
| |