It is recommended to first state what a patch does before providing the background and motivation. See https://docs.kernel.org/process/maintainer-kvm-x86.html#changelog >There's no need to intercept changes to CR4.CET, as it's neither >included in KVM's MMU role bits, nor does KVM specifically care about >the actual value of a (nested) guest's CR4.CET value, beside for >enforcing architectural constraints, i.e. make sure that CR0.WP=1 if >CR4.CET=1. > >Intercepting writes to CR4.CET is particularly bad for grsecurity >kernels with KERNEXEC or, even worse, KERNSEAL enabled. These features >heavily make use of read-only kernel objects and use a cpu-local CR0.WP >toggle to override it, when needed. Under a CET-enabled kernel, this >also requires toggling CR4.CET, hence the motivation to make it >guest-owned. > >Using the old test from [1] gives the following runtime numbers (perf >stat -r 5 ssdd 10 50000): > >* grsec guest on linux-6.16-rc5 + cet patches: > 2.4647 +- 0.0706 seconds time elapsed ( +- 2.86% ) > >* grsec guest on linux-6.16-rc5 + cet patches + CR4.CET guest-owned: > 1.5648 +- 0.0240 seconds time elapsed ( +- 1.53% ) > >Not only makes not intercepting CR4.CET the test run ~35% faster, it's >also more stable, less fluctuation due to less VMEXITs, I believe. > >Therefore, make CR4.CET a guest-owned bit where possible. > >This change is VMX-specific, as SVM has no such fine-grained control >register intercept control. Ah, that's why the shortlog is "KVM: VMX". I was wondering why the shortlog specifically mentions VMX while the patch actually touches x86 common code. > >If KVM's assumptions regarding MMU role handling wrt. a guest's CR4.CET >value ever change, the BUILD_BUG_ON()s related to KVM_MMU_CR4_ROLE_BITS >and KVM_POSSIBLE_CR4_GUEST_BITS will catch that early. > >Link: https://lore.kernel.org/kvm/20230322013731.102955-1-minipli@xxxxxxxxxxxxxx/ [1] >Signed-off-by: Mathias Krause <minipli@xxxxxxxxxxxxxx> The patch looks good. So, Reviewed-by: Chao Gao <chao.gao@xxxxxxxxx>
