On 2023/6/15 03:07, Sean Christopherson wrote:
On Wed, Jun 14, 2023, Luiz Capitulino wrote:
On 2023-06-13 19:21, Sean Christopherson wrote:
On Thu, 01 Jun 2023 17:58:59 -0700, Sean Christopherson wrote:
Add a "never" option to the nx_huge_pages module param to allow userspace
to do a one-way hard disabling of the mitigation, and don't create the
per-VM recovery threads when the mitigation is hard disabled. Letting
userspace pinky swear that userspace doesn't want to enable NX mitigation
(without reloading KVM) allows certain use cases to avoid the latency
problems associated with spawning a kthread for each VM.
[...]
Applied to kvm-x86 mmu. I kept the default as "auto" for now, as that can go on
top and I don't want to introduce that change this late in the cycle. If no one
beats me to the punch (hint, hint ;-) ), I'll post a patch to make "never" the
default for unaffected hosts so that we can discuss/consider that change for 6.6.
Thanks Sean, I agree with the plan. I could give a try on the patch if you'd like.
Yes please, thanks!
As a KVM/x86 *feature*, playing with splitting and reconstructing large
pages have other potential user scenarios, e.g. for performance test
comparisons in a easier approach, not just for itlb_multihit mitigation.
On unaffected machines (ICX and later), nx_huge_pages is already "N",
and turning it into "never" doesn't help materially in the mitigation
implementation, but loses flexibility.
IMO, the real issue here is that the kernel thread "kvm-nx-lpage-
recovery" is created unconditionally. We also need to be aware of the
existence of this commit 084cc29f8bbb ("KVM: x86/MMU: Allow NX huge
pages to be disabled on a per-vm basis").
One of the technical proposals is to defer kvm_vm_create_worker_thread()
to kvm_mmu_create() or kvm_init_mmu(), based on
kvm->arch.disable_nx_huge_pages, even until guest paging mode is enabled
on the first vcpu.
Is this step worth taking ?
