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@xxxxxxxxx> >>> >>> 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
