Re: Interest in contributing to KVM TODO

[Sean Christopherson <seanjc@google.com>]

On Wed, Jan 22, 2025, Aaron Ang wrote:
> Hi KVM team,
> 
> We are a group of graduate students from the University of California,
> San Diego, interested in contributing to KVM as part of our class
> project. We have identified a task from the TODO that we would like to

Oof, https://www.linux-kvm.org/page/TODO is a "bit" stale.

> tackle: Improve mmu page eviction algorithm (currently FIFO, change to
> approximate LRU). May I know if there are any updates on this task,
> and is there room for us to develop in this space?

AFAIK, no one is working on this particular task, but honestly I wouldn't bother.
There are use cases that still rely on shadow paging[1], but those tend to be
highly specialized and either ensure there are always "enough" MMU pages available,
or in the case of PVM, I suspect there are _significant_ out-of-tree changes to
optimize shadow paging as a whole.

With the TDP MMU, KVM completely ignores the MMU page limit (both KVM's default
and the limit set by KVM_SET_NR_MMU_PAGES.  With TDP, i.e. without shadow paging,
the number of possible MMU pages is a direct function of the amount of memory
exposed to the guest, i.e. there is no danger of KVM accumulating too many page
tables due shadowing a large number of guest CR3s.

With nested TDP, KVM does employ shadow paging, but the behavior of an L1 hypervisor
using TDP is wildly different than an L1 kernel managing "legacy" page tables for
itself and userspace.  If an L1 hypervisor manages to run up against KVM's limit
on the number of MMU pages, then in all likelihood it deserves to die :-)

What areas are y'all looking to explore?  E.g. KVM/virtualization in general,
memory management in particular, something else entirely?  And what timeline are
you operating on, i.e. how big of a problem/project are you looking to tackle?

[1] https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com

> We also plan to introduce other algorithms and compare their performance
> across various workloads. We would be happy to talk to the engineers owning
> the MMU code to see how we can coordinate our efforts. Thank you.